On 2010-03-12, Uwe Klein <uwe_klein_habertw...@t-online.de> wrote: > unruh wrote: >> On 2010-03-12, David Woolley <da...@ex.djwhome.demon.invalid> wrote: >> >>>unruh wrote: >>> >>>>On 2010-03-11, Hal Murray <hal-use...@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 > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions