Additional pps-gpio

[Achim Gratz]

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