Hal Murray via devel writes: >> But maybe I don't understand what you're after. > > I'm interested in learning whatever we can about the timing in the kernel PPS > area.
Sorry, that's still too vague for me to try to help. But for the Linux kernel it all starts and ends here, I think: https://elixir.free-electrons.com/linux/v4.14.14/source/kernel/time/timekeeping.c > There is another approach that might be interesting. Use a loopback on some > modem control signals or gpio pins. Then a test program can grab the time, > flap the pin, and grab the time, then read the PPS time. Yes, you've mentioned that before. The general problem I see is that even from within the kernel you'll not figure out where any time that seems to be missing is spent. So you're left with the same old problem that you have to assume how the roundtrip time gets slit into outward and inward propagation delays. You'll really want a timestamp for when that event goes through the loopback (that's correlatable to your internal clock), but that's not so easy to come by. Things get more interesting when you can use hardware timestamping, so you can cut out the jitter from the kernel. > Things may get complicated by locks in the kernel. If they get too ugly, we > could use two machines and ping-pong back and forth. It would take a bit of > work to merge the data and correct for the time offset between the two > systems. That would work better with identical systems. But that offset would be _the_ problem. I think you'd actually need a third system as an observer to fully close all the loopholes. Things get easier if that observer system is way better than the two others, but unless you throw real money at it that's not going to happen. OTOH, some of it already has been done: http://www4.comp.polyu.edu.hk/~csrchang/Time%20to%20Measure%20the%20Pi.pdf If you know someone who wants to rid himself of a bunch of reference OCXO and Rb not via Ebay, let me know. :-) > I'm interested in both GPIO and modem signals on PCs with real serial > ports. At the moment I'm seeing the PC only as a client system for most folks. If you want anything better than a few milliseconds deviation in your network, you are going to need at least three, better five, NTP servers in each LAN segment and that's a lot easier to do with something like the rasPi. I've ordered a bunch of RS232 converters and USB UART today along wth another rasPi 3B and Tinkerboard, so I should be able to tell how much better things get exactly when you use line disciplining on a virtual or real serial port on these and also a PC soon. Let's hope the FTDI chips are not fake on those USB UART so I get a full virtual serial with all modem control lines. The RS232 level converters will need modification to have the PPS signal appear on the DCD pin and hopefully I've picked one that just needs a jumper wire between pin 1 and pin 8 and doesn't have pin 1 grounded. Otherwise I may have to grab that patch that modifies the serial to use CTS instead of DCD for the line dicipline or isolate the pin before putting the jumpwire in. > I have PCs with multiple serial ports. It may be easier for me to work with > them rather than learn how to drive the GPIO pins on a Raspberry Pi. If you're talking kernel-mode measurements, the rasPi are much easier to work with for me, since I don't really plan to create a custom kernel for my main box or do things to it that might produce a crash. I may be able to dual-boot one of my older x86 boxen once in a while and use that for experimentation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
