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

Uwe Klein uwe_klein_habertwedt at t-online.de
Fri Mar 12 18:43:42 UTC 2010

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. )


More information about the questions mailing list