[ntp:questions] Which version of Linux works best?

unruh unruh at wormhole.physics.ubc.ca
Fri Mar 12 20:26:24 UTC 2010


On 2010-03-12, Uwe Klein <uwe_klein_habertwedt at t-online.de> wrote:
> unruh wrote:
>> On 2010-03-12, David Woolley <david at ex.djwhome.demon.invalid> wrote:
>> 
>>>unruh wrote:
>>>
>>>>On 2010-03-11, Hal Murray <hal-usenet at ip-64-139-1-69.sjc.megapath.net> wrote:
>>>>
>>>>>>>Modern Linux kernels don't support PPS in the sense of RFC-whateveritis.
>>>>>>>
>>>>>>>There is support for an ioctl that says "wake me up when a modem signal changes".
>>>>>>>gpsd uses that to provide PPS support.  I don't have any data.
>>>>>>
>>>>>>I believe but am not sure, that that uses an interrupt.
>>>>>
>>>>>I think so.  But the point is that with the PPS support, the
>>>>>kernel grabs a timestamp in the interrupt routine.  The ioctl
>>>>
>>>>So? The interrupt still takes the same time to be activated. On a GHZ
>>>>system, there is enough time in 1usec to run 1000 commands, and it is
>>>>hard to imagine that many being used to return the ioctl. I have worried
>>>
>>>That's 1000 machine cycles, not 1000 instructions.  On modern systems, 
>> 
>> 
>> And since most modern processors are pipelined and parallelized it may
>> mean more than 1000 instructions. 
>> 
>> 
>>>I'm not sure that 1000 cycles isn't a typical time for a system call on 
>>>modern, high level language progammed, bloatware.  (I seem to remember 
>>>hand coding an ISR in assembler to a budget of 100 instructions (for 
>>>68000) and it not being that easy.)
>> 
>> 
>> No idea, which is why I would love to see tests to see how long it takes
>> the serial port to respond. I know the parallel port takes something
>> like 1 -2 usec between 
>> Timestamp
>> raise parallel port out line
>> get and process interrupt and deliver to kernel interrupt processing
>> module
>> Timestamp
>>  (The out line is connected to the parallel port interrupt control line)
>> 
> Afair there used to be response data ( delay, jitter) available for
> RT-Linux but I can't find it at the moment.
> ( and it is different for an ISA connected Interface and a PCI connected one.)
>
> you have the aliasing jitter between incoming serial signal and the sampling
> clock to reckon with. ( bittime divided by (over)sampling rate 4,8,32,64?
> in the receiver, only have the data for the Z8530 / Z8035 type parts. )

I cerainly would not rely on the data in/out for the interrupt as it
might well have clock aliasing. But is there not a specific pin on the
serial port which is an immediate interrupt pin like the interrupt pin
on the parallel port?


>
> uwe
>




More information about the questions mailing list