[time-nuts] Designing an embedded precision GPS time server

[Nick Sayer]

I think my test rig is likely to be a pair of units connected with a crossover cable, with test firmware on one to act as a fake client, and using spare GPIOs on test points to measure latency and the like with a scope. I don’t have the wherewithal to try and gauge the timing of switches, and of course the function of switches makes monitoring unicast traffic by third parties “impossible” (yes, you can play games with the switch table, but that’s more trouble than it’s worth).




> On Oct 29, 2017, at 5:27 AM, Scott McGrath <scmcgrath at gmail.com> wrote:
> 
> With 1588 switch architecture counts as well because you have two major classes of switch,  blocking and non blocking plus buffering etc.
> 
> Most 'enterprise' switches once the flow is set up directly forward frames from the ingress port to the egress port each of which also tends to have a fairly deep buffer so RTT Is non deterministic on a normal network
> 
> Most SOHO  switches use shared ring buffers so their performance is even worse
> 
> 
> 
>> On Oct 29, 2017, at 6:29 AM, Leo Bodnar <leo at leobodnar.com> wrote:
>> 
> 
>> From: Nick Sayer <nsayer at kfu.com>
>> I believe I’m going to start with one of my GPS module breakouts and an E70 XPlained development board. From a hardware perspective, I expect that to be reasonably close to what the final hardware will be (the one thing I would guess would change would be perhaps swapping out the PHY chip for one that’s capable of doing PHY level timestamping, if that’s necessary and possible).
> 
> Hi Nick,
> 
> Note that PTP/IEEE1588 compliant hardware and NTP use different points in the packet as reference timestamps. Timestamping transmitted packets in hardware is useless for NTP.  I suspect you know that already.
> 
>> But my plan at the moment is to first try to get something that even answers the phone, see how terrible it is, and then see what has to be done to make it truly worthy.
> 
> You will find it trivial to get basic functionality working and reasonably challenging to get it to work reliably under heavy load and edge cases.  "Heavy load" is not an abstract scenario since even on a lightly loaded network there is a probability of several clients requesting time simultaneously and network switch stacking NTP packets back to back.
> 
> If you are making an open source thing you might want to use Laureline NTP http://partiallystapled.com/pages/laureline-gps-ntp-server.html as a starting point or as a performance yardstick.  I have never seen one so can't comment on how well it works but if done properly it should be reasonably solid and agile.  I think the guy who designed it also sells them commercially but from what I can see the design is also available for others to use.
> 
> Leo
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.