gnu not unix wrote:
The 2.6.3 kernel with the "ppskit lite" worked pretty well here.
I don't have one running at the moment, but I recall it was routinely
in the 10's of microseconds offset. A proud member of the herd (grin).
I got nowhere near that, even when the GPS was the only process running
(single user mode). Maybe there's a tuning option somewhere I missed.
The fanout box is the Big Win here. I've got to replace the differential
driver on the roof, though--its gotten badly corroded after a couple
years exposure to the elements.
Not sure how that helps though.. you end up with multiple tier 1
servers on site I guess but they're all synced to exactly the same
source! Surely that's what NTP is there for...
Now if you had a couple of different GPS, a Radio source, etc. (and if
you can get the budget an atomic clock :P) you could compare them
usefully for accuracy.
The network here is 100mb switched ethernet. This speed results in
100 microsecond delays. A 10 megabit half duplex isa card will show
Hmm... 192 here (crosses a gigabit switch but neither box is gigabit..
OTOH the switch is relatively busy):
*dax.local.nodom .PPS. 1 u 124 128 377 0.192 0.092
0.340
It'd be interesting to see the latency across a pure gigabit connection
ie. how much is OS/Interrupt and how much is transmission.
up with 1 millisecond delay when added to this setup. It is interesting
to see that the freebsd 4.7 unit (smidge) seems to have 100 extra microseconds
of udp stack latency, compared to the other two linux 2.4.20/ppskit
udp stacks. This may be due to the freebsd kernel having some kind
of kernel packet filtering code compiled in, although all the rules
are simply wide open. None of the linux boxen have firewall code.
Could be.. I put it down to the different processor speed on the boxes.
Tony
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
