George R. Kasica <[email protected]> writes: >On Wed, 31 Dec 2008 17:57:25 GMT, Unruh <[email protected]> >wrote:
>>George R. Kasica <[email protected]> writes: >> >>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor" >>><[email protected]> wrote: >> >>>>Unruh wrote: >>>>> "David J Taylor" >>>>[] >>>>>> With just the reference clock type 20, I get the accuracy needed. >>>>>> The PPS line from the GBS-18 LVC is wired to the DCD line of the >>>>>> serial port. In my ignorance, I don't see why you even need the SHM >>>>>> driver, but as I said before, I'm no expert! I don't see why my >>>>>> system picks up the PPS from just the type 20 driver, and yours does >>>>>> not. >>>>> >>>>> >>>>> Because you have the PPS kernel patch installed or it was >>>>> automatically >>>>> instaled in BSD? The OP does not and does not want to. >>>> >>>>Thanks. Yes, I had to recompile the FreeBSD kernel to include this patch. >>>>I must have thought at the time that it was mandatory, or was advised to >>>>do this. >> >>>I'd be happy to put it in here, but doing so with the Fedora Core 9 >>>RPM based code is not something I'm familiar with. I'm used to working >>>with straight source code for kernels ie make make install type steps >>>(don't take those literally please I know the steps) or just leaving >>>the RPMs alone. I just am not sure how or if the PPS patches I've seen >>>will apply to the kernel version here on the FC9 box or how it will >>>affect the system-obviously breaking it is not an option - well, it >>>always is but not a good one since it archives a ton of weather data >>>:). >> >>I think it will gain you nothing over the shm option, except you will be >>sitting there worrying and watching your computer compiling a kernel. >> >>However, has anyone done tests on the serial port interrupt to see how much >>latency there is in that? Ie, If I use, say, shmpps and I trigger the serial >>control line at time t, what is the time t+dt that shmpps reports as the >>time of the trigger? And what is the fluctuation in dt? On the parallel >>port interrupt service routine I have done that and the result was about >>0-2usec. (in fact I suspect most of the noise in at least the short term >>fluctuation of ntpd is from that source). But shmpps and gpsd have a whole >>layer of serial port driver interposed between the interrupt and the >>report. Does that made a difference? >I likely have nowhere near the level of hardware/software knowledge or >likely test gear to accomplish this. TEst gear not needed. You just need to put out and time a signal onto the parallel port and feed it into the serial port, timing the reception of the signal. But that does require a lot of hacking. I was able to do it on the parallel port because the program had already been written in Alessandro Rubini and Jonathan Corbet's boot Linux Device Drivers I just made minor adaptation ( or major ones when I used it as the basis for my parallel port gps device driver) However, I was wondering if anyone had done the same thing for the standard serial port ioctl _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
