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

[Andrew Rodland]

Hi Nick,

I've got a project along those lines that I've been hacking on for the past
three years or so, and always meaning to do a thorough writeup on. I'm more
of a software than hardware guy, so the heart of it is a Taijiuino Due (a
weird Chinese clone of the Arduino Due, so an 84MHz ATSAM3X8E, with the
difference from the official board being that it brings out the SAM's
Ethernet pins to a header that you can perch a PHY module on). It then
talks to a GPS (Resolution-SMT) and Rb (SA.22c, digitally controlled),
multiplied up 25/8 times by a TAPR Clock-Block to get 32ns granularity
(more or less). Apart from some of the low-level MAC code which is from
Atmel it's all my code for GPS decoding, timekeeping, NTP, etc, and has
some basic support for health monitoring and holdover.

As a NTP server it's pretty good when it's behaving -- I've got a
particularly-stable Linux machine on the same Ethernet segment polling it
at 16s interval and chrony reports a 500ns - 1us stdev for it, so you can
take that as a jitter figure. It outperforms the old Spectracom NetClock
9183 (w/OCXO option) I've got, in any case.

I'd be interested in comparing notes, and also interested in any
possibility of designing a PCB to replace the rat's nest of wires I've got
going on -- as I mentioned, I'm not "really" a hardware guy and EDA isn't a
skill I've picked up at this point. I've always wanted to derive the
micro's clock from the Rb (and PLL it up on the chip) rather than having to
live with the restrictions of an externally-clocked timer... but making
that happen is beyond my abilities :)


On Wed, Oct 25, 2017 at 8:53 PM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

> I’ve just completed a project (off topic) with the ATSAMS70 chip and
> learned a lot in a relatively short time, and I really like the result.
>
> I am considering a new project based on its cousin, the ATSAME70. The E70
> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the
> S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice),
> and Atmel Start (the software development framework I’ve been using)
> purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a
> starting point at least).
>
> Where I am going with this is I am considering designing a precision
> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got
> piles of up to a GPIO and USART and the Ethernet port would provide
> NTP/PTP. The idea behind making it an embedded system would be to try and
> make it as accurate as it reasonably can be with the hope that (at least on
> the local segment) it would wind up being more accurate than a Pi Zero
> doing the same thing. At the very least, you’d expect such a thing to be a
> whole lot less hassle to set up, given decent firmware.
>
> This may be a fool’s errand, certainly, but looking at it from here, I
> would think that such a design might offer accuracy in the microsecond
> range, but that’s just a tremendously uninformed guess at this point (and
> what does that accuracy mean to a peer that might itself be incapable of
> better than 2 orders of magnitude coarser?).
>
> Anybody have any ideas or suggestions along these lines?
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Mike Cook]

> Le 29 oct. 2017 à 11:29, Leo Bodnar  a écrit :
> 
> 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.
> 

Try again.Sorry if some of you got a SPAM header.. My client has issues.

I bought one of these  three  years ago. It is very reliable and the perf is 
very good. I attach a couple of shots from this morning. 


Unfortunately it does not propagate leap seconds.

> Leo
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Denny Page]

Back to back with 100Mb is good, particularly for latency tests, but you’ll 
need a switch for general testing. FWIW, an otherwise idle switch generally has 
very consistent latency, and if both ports are at 100Mb, it is symmetric. Also, 
with any kind of managed switch you can easily monitor traffic via a tap or 
span (mirror) port.

Alternatively you could use an hub (yes, a hub!). I have one that I keep for 
very special occasions. :)

Denny


> On Oct 29, 2017, at 09:12, Nick Sayer via time-nuts  
> wrote:
> 
> 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).

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Nick Sayer via time-nuts]

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  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  wrote:
>> 
> 
>> From: Nick Sayer 
>> 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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Scott McGrath]

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  wrote:
> 

> From: Nick Sayer 
> 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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Leo Bodnar]

> From: Nick Sayer 
> 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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Philip Gladstone]

I built a couple of NTP time servers around this board: 
https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware 
which supports IEEE1588. It also acts as a PTP source on the LAN. It is 
part of the IPv6 ntp pool and is currently serving about 1000 requests 
per minute. It uses a custom PCB to connect to a small display an the 
GPS board (it has support for a number of different GPS boards).


It just needs putting into a case to complete the project. Of course, 
the last 10% takes 90% of the time!


Philip


On 28/10/2017 15:58, Nick Sayer via time-nuts wrote:

That looks and sounds very, very much like what I want to do.

Thank you very much for your testing suggestions. When it comes time, I had 
indeed planned on adding it to the NTP pool if for no other reason than to 
contribute to the cause (but also for testing).

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).

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.

Those interested can follow the hackaday project. This whole thing is going to 
be open hardware and GPLed firmware (again, assuming I succeed).

https://hackaday.io/project/27873-embedded-gps-ntp-server


On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:

Hi Nick,

Last year I have designed an NTP server with sub-microsecond turnaround 
accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
speed) that costs just £250 from stock.
Its holdover performance on signal loss is in the order of 4-5ms/day.
https://store.uputronics.com/index.php?route=product/product=60_70_id=92

If you can come up with a cheaper and higher performance alternative I am very 
interested in licensing your design.

When you come to testing I can highly recommend placing your prototypes in 
public NTP pool and asking the admins to add it to .ch zone - you are 
guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
Just a few devices collectively served 1.1 trillion packets in less than a year 
http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat 
incident.)

Jitter and holdover need to be tested on a controlled LAN segment - I can 
highly recommend contacting Denny Page on this list and sending him a unit to 
test.
He built sophisticated and highly tuned testing system that tracks timing 
jitter and offset down to dozens of nanoseconds accuracy.
Denny is vendor-neutral and provided honest and fair feedback while I was 
developing my unit.

Hope this helps!

Thanks
Leo

On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:


Date: Wed, 25 Oct 2017 17:53:46 -0700
From: Nick Sayer 

I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a 
lot in a relatively short time, and I really like the result.

I am considering a new project based on its cousin, the ATSAME70. The E70 has 
an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
(USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
Start (the software development framework I’ve been using) purports to have a 
ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).

Where I am going with this is I am considering designing a precision embedded 
NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to 
a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind 
making it an embedded system would be to try and make it as accurate as it 
reasonably can be with the hope that (at least on the local segment) it would 
wind up being more accurate than a Pi Zero doing the same thing. At the very 
least, you’d expect such a thing to be a whole lot less hassle to set up, given 
decent firmware.

This may be a fool’s errand, certainly, but looking at it from here, I would 
think that such a design might offer accuracy in the microsecond range, but 
that’s just a tremendously uninformed guess at this point (and what does that 
accuracy mean to a peer that might itself be incapable of better than 2 orders 
of magnitude coarser?).

Anybody have any ideas or suggestions along these lines?



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Nick Sayer via time-nuts]

That looks and sounds very, very much like what I want to do.

Thank you very much for your testing suggestions. When it comes time, I had 
indeed planned on adding it to the NTP pool if for no other reason than to 
contribute to the cause (but also for testing).

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).

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.

Those interested can follow the hackaday project. This whole thing is going to 
be open hardware and GPLed firmware (again, assuming I succeed). 

https://hackaday.io/project/27873-embedded-gps-ntp-server

> On Oct 27, 2017, at 12:27 PM, Leo Bodnar  wrote:
> 
> Hi Nick,
> 
> Last year I have designed an NTP server with sub-microsecond turnaround 
> accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
> speed) that costs just £250 from stock.
> Its holdover performance on signal loss is in the order of 4-5ms/day.
> https://store.uputronics.com/index.php?route=product/product=60_70_id=92
> 
> If you can come up with a cheaper and higher performance alternative I am 
> very interested in licensing your design.
> 
> When you come to testing I can highly recommend placing your prototypes in 
> public NTP pool and asking the admins to add it to .ch zone - you are 
> guaranteed to get full 110kpps traffic spikes that will help to flush out 
> bugs.
> Just a few devices collectively served 1.1 trillion packets in less than a 
> year http://leobodnar.com/LeoNTP/ (and have been through the infamous 
> snapchat incident.)
> 
> Jitter and holdover need to be tested on a controlled LAN segment - I can 
> highly recommend contacting Denny Page on this list and sending him a unit to 
> test.  
> He built sophisticated and highly tuned testing system that tracks timing 
> jitter and offset down to dozens of nanoseconds accuracy.  
> Denny is vendor-neutral and provided honest and fair feedback while I was 
> developing my unit.
> 
> Hope this helps!
> 
> Thanks
> Leo
> 
> On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:
> 
>> Date: Wed, 25 Oct 2017 17:53:46 -0700
>> From: Nick Sayer 
>> 
>> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
>> a lot in a relatively short time, and I really like the result.
>> 
>> I am considering a new project based on its cousin, the ATSAME70. The E70 
>> has an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 
>> has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and 
>> Atmel Start (the software development framework I’ve been using) purports to 
>> have a ready-to-use IP stack (alas, no IPv6, but it’s a starting point at 
>> least).
>> 
>> Where I am going with this is I am considering designing a precision 
>> embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got 
>> piles of up to a GPIO and USART and the Ethernet port would provide NTP/PTP. 
>> The idea behind making it an embedded system would be to try and make it as 
>> accurate as it reasonably can be with the hope that (at least on the local 
>> segment) it would wind up being more accurate than a Pi Zero doing the same 
>> thing. At the very least, you’d expect such a thing to be a whole lot less 
>> hassle to set up, given decent firmware.
>> 
>> This may be a fool’s errand, certainly, but looking at it from here, I would 
>> think that such a design might offer accuracy in the microsecond range, but 
>> that’s just a tremendously uninformed guess at this point (and what does 
>> that accuracy mean to a peer that might itself be incapable of better than 2 
>> orders of magnitude coarser?).
>> 
>> Anybody have any ideas or suggestions along these lines?
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Denny Page]

> On Oct 26, 2017, at 19:29, Chris Caudle  wrote:
> 
> On Thu, October 26, 2017 7:38 pm, Denny Page wrote:
>> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going
>> to want hardware timestamping support on the ethernet phy.
> 
> Or the MAC.  The processor used on BeagleBone Black has timestamping in
> the MAC.  Not quite as accurate as stamping in the phy, but should be a
> relatively consistent fixed offset.


Yes, but it might not be as consistent as you would like. The Intel i210 is a 
pretty good reference. It does mac timestamping and has a built-in phy. At 
100Mb, Intel advertises a timestamp latency range of 984-1024ns for outbound 
packets, and 2148-2228ns for inbound packets. The ranges are a result of mac 
clock issues, unassociated with phy communication.

External measurement shows that the mean values are actually outside the ranges 
given, 1044ns for outbound, and 2133ns for inbound. [I suspect, but don’t know 
for sure, that the offset is a result of a fixed 20ns delay between the phy and 
mac.] Anyway, on a loopback between two i210 instances, you will see an average 
total timestamp latency of 3177ns, with a standard deviation of around 100ns. 
Pretty good, but not that great.

What chip does the BeagleBone Black use? Do they publish specs on the ethernet 
timestamp latency?

Thanks,
Denny

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Attila Kinali]

Hoi Leo,

On Fri, 27 Oct 2017 20:27:53 +0100
Leo Bodnar  wrote:

> Last year I have designed an NTP server with sub-microsecond turnaround 
> accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
> speed) that costs just £250 from stock.
> Its holdover performance on signal loss is in the order of 4-5ms/day.
> https://store.uputronics.com/index.php?route=product/product=60_70_id=92

Can you tell a little bit how your device looks like on the inside?
What do you use as microprocessor? What as GPS receiver? From the
hold-over spec, I would guess you are using a TCXO, which one is it?
What do you use to get the timing of the PPS pulse? Do you apply
saw-tooth correction?

> If you can come up with a cheaper and higher performance alternative I am
> very interested in licensing your design.

Getting better performance is not that difficult. Getting it cheaper is.
An OCXO (new, not from ebay) and a timing GPS receiver would already cost
something around 100-150€. That's one third to half of the cost of your
complete device already. Using an OCXO from ebay and you can do it quite
easily.
 
> When you come to testing I can highly recommend placing your prototypes in 
> public NTP pool and asking the admins to add it to .ch zone - you are 
> guaranteed to get full 110kpps traffic spikes that will help to flush out 
> bugs.

Why specifically the .ch zone? IIRC you are located in the uk.

I am running an NTP server in the .ch pool and have not yet noticed
any large spikes. (ok, my monitoring is rather crude and if the spike
is very short lived, i wouldnt notice it)

Attila Kinali

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Leo Bodnar]

Hi Nick,

Last year I have designed an NTP server with sub-microsecond turnaround 
accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire 
speed) that costs just £250 from stock.
Its holdover performance on signal loss is in the order of 4-5ms/day.
https://store.uputronics.com/index.php?route=product/product=60_70_id=92

If you can come up with a cheaper and higher performance alternative I am very 
interested in licensing your design.

When you come to testing I can highly recommend placing your prototypes in 
public NTP pool and asking the admins to add it to .ch zone - you are 
guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
Just a few devices collectively served 1.1 trillion packets in less than a year 
http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat 
incident.)

Jitter and holdover need to be tested on a controlled LAN segment - I can 
highly recommend contacting Denny Page on this list and sending him a unit to 
test.  
He built sophisticated and highly tuned testing system that tracks timing 
jitter and offset down to dozens of nanoseconds accuracy.  
Denny is vendor-neutral and provided honest and fair feedback while I was 
developing my unit.

Hope this helps!

Thanks
Leo

On 26 Oct 2017, at 17:00, time-nuts-requ...@febo.com wrote:

> Date: Wed, 25 Oct 2017 17:53:46 -0700
> From: Nick Sayer 
> 
> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
> a lot in a relatively short time, and I really like the result.
> 
> I am considering a new project based on its cousin, the ATSAME70. The E70 has 
> an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
> (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
> Start (the software development framework I’ve been using) purports to have a 
> ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).
> 
> Where I am going with this is I am considering designing a precision embedded 
> NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up 
> to a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea 
> behind making it an embedded system would be to try and make it as accurate 
> as it reasonably can be with the hope that (at least on the local segment) it 
> would wind up being more accurate than a Pi Zero doing the same thing. At the 
> very least, you’d expect such a thing to be a whole lot less hassle to set 
> up, given decent firmware.
> 
> This may be a fool’s errand, certainly, but looking at it from here, I would 
> think that such a design might offer accuracy in the microsecond range, but 
> that’s just a tremendously uninformed guess at this point (and what does that 
> accuracy mean to a peer that might itself be incapable of better than 2 
> orders of magnitude coarser?).
> 
> Anybody have any ideas or suggestions along these lines?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Chris Caudle]

On Thu, October 26, 2017 7:38 pm, Denny Page wrote:
> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going
> to want hardware timestamping support on the ethernet phy.

Or the MAC.  The processor used on BeagleBone Black has timestamping in
the MAC.  Not quite as accurate as stamping in the phy, but should be a
relatively consistent fixed offset.

-- 
Chris Caudle


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Chris Caudle]

On Thu, October 26, 2017 5:58 pm, Bob kb8tq wrote:
> Why go to the green?

Cheaper.

> Just go with one of these Pocket Beagles I have
> sitting here wondering what to do with them.

Pocket Beagles do not have Ethernet.  How are you going to make a network
time server from a board with no network?

> get two Pi Zeros for the pice of the Pocket Beagle. Lash an interface
> onto any of them (just like the Green) and get going.

I suppose you could connect a network interface of some kind using the
USB, but I have never seen a USB network adapter with hardware
timestamping.  Possibly they exist, but I do not believe that a driver
currently exists which could read the hardware timer on a USB interface,
you would need to create the driver (probably after you created the
hardware).

-- 
Chris Caudle


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Bob kb8tq]

Hi

I suspect that once you find a group of chips that do have 1588 embedded in 
them that
digging into all the nasty details will take a bit. Time stamping to a 1 ms 
resolution might
not be a very helpful thing ….. There are ex-Freescale / now NXP devices that 
do have
pretty good 1588 in them. I’m sure they are not the only ones to go down that 
route.

Bob


> On Oct 26, 2017, at 8:38 PM, Denny Page  wrote:
> 
> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going to 
> want hardware timestamping support on the ethernet phy. I would view this as 
> one of the principal concerns in choosing a system.
> 
> I’m not sufficiently familiar with Beagles… do any of them support hardware 
> timestamping?
> 
> Denny
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Denny Page]

If you are going to do PTP with ptp4l, or NTP with Chrony, you are going to 
want hardware timestamping support on the ethernet phy. I would view this as 
one of the principal concerns in choosing a system.

I’m not sufficiently familiar with Beagles… do any of them support hardware 
timestamping?

Denny


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Bob kb8tq]

Hi

Why go to the green? Just go with one of these Pocket Beagle’s I have sitting
here wondering what to do with them. They were just a bit under $20 when I 
picked them up. I doubt the price will climb over time …… Indeed you could
get two Pi Zero W’s for the pice of the Pocket Beagle. Lash an interface onto 
any of them (just like the Green) and get going. 

Is any of that cheaper once you get 1588 Ethernet going than a board (or chip) 
with
integrated Ethernet? My guess is no. 

Bob


> On Oct 26, 2017, at 5:26 PM, Iain Young  wrote:
> 
> On 26/10/17 22:11, Chris Caudle wrote:
> 
>> The processor you mentioned has a Cortex-M7 at 300MHz.   has a
>> Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
>> coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
>> retail for $50 which gets you the faster higher class processor, 512MB of
>> DRAM and 4GB of flash.  It runs linux right out of the box so you
>> basically  power it on and have NTP running.
> 
> The BB Green is even better value for money, and why would we need HDMI
> for timing apps ? (It also simplifies doing my Poor man's TIC!)
> 
>> On my list of projects to work on is a cape for BeagleBone Black that
>> takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
>> the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
>> my estimation that seemed like the best return on effort.
> 
> Wheen you get around to it, *Please* consider:
> 
>   1) multiplying that 10MHz up to 24 MHz as an option
>   2) RS422 option instead of RS232 (for the Lucent/HP GPS/Rb boxes)
>   3) PPS routed to TIMER4/5/6/7 rather than any old GPIO
>   4) Cover _all_ UARTS, even if serial headers are needed, rather than
> 9-pin D connectors
>   5) Some method of dropping a 5V PPS down to 3.3V (2N comes to
> mind, as does a /2 voltage divider [2.5V is sufficient to trigger the
> GPIO pins], I have done both - and yes measured the delay through the
> 2N!)
> 
> (Sorry Chris, I was looking at the serial cape options earlier today
> to try an santise my lash-ups, and was most disappointed!)
> 
> 
> Iain
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Iain Young]

On 26/10/17 22:11, Chris Caudle wrote:


The processor you mentioned has a Cortex-M7 at 300MHz.   has a
Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
retail for $50 which gets you the faster higher class processor, 512MB of
DRAM and 4GB of flash.  It runs linux right out of the box so you
basically  power it on and have NTP running.


The BB Green is even better value for money, and why would we need HDMI
for timing apps ? (It also simplifies doing my Poor man's TIC!)


On my list of projects to work on is a cape for BeagleBone Black that
takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
my estimation that seemed like the best return on effort.


Wheen you get around to it, *Please* consider:

   1) multiplying that 10MHz up to 24 MHz as an option
   2) RS422 option instead of RS232 (for the Lucent/HP GPS/Rb boxes)
   3) PPS routed to TIMER4/5/6/7 rather than any old GPIO
   4) Cover _all_ UARTS, even if serial headers are needed, rather than
9-pin D connectors
   5) Some method of dropping a 5V PPS down to 3.3V (2N comes to
mind, as does a /2 voltage divider [2.5V is sufficient to trigger the
GPIO pins], I have done both - and yes measured the delay through the
2N!)

(Sorry Chris, I was looking at the serial cape options earlier today
to try an santise my lash-ups, and was most disappointed!)


Iain
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Chris Caudle]

On Wed, October 25, 2017 7:53 pm, Nick Sayer via time-nuts wrote:
> I am considering a new project based on its cousin, the ATSAME70.

What is a reasonable cost target for that at the volumes you could
produce?  Coming up with something that is a better value than BeagleBone
Black at any kind of hobby project volume seems difficult.

The processor you mentioned has a Cortex-M7 at 300MHz.   has a
Cortex-A8 running at 1GHz plus a Cortex-M processor available as a
coprocessor. Peripheral set is pretty comparable, and you can buy BBB at
retail for $50 which gets you the faster higher class processor, 512MB of
DRAM and 4GB of flash.  It runs linux right out of the box so you
basically  power it on and have NTP running.

> Anybody have any ideas or suggestions along these lines?

On my list of projects to work on is a cape for BeagleBone Black that
takes 10MHz and 1PPS inputs along with a couple of RS232 converters for
the UARTs so you can connect a GPSDO to a BBB to make a time server.  In
my estimation that seemed like the best return on effort.

-- 
Chris Caudle


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Bob kb8tq]

Hi

So, get it up and running on the 1588 hardware built into one of these “all in 
one” 
MCU’s should be possible. Note the absence of words like easy or 
straightforward :)

Bob


> On Oct 26, 2017, at 12:45 PM, Chris Caudle  wrote:
> 
> On Thu, October 26, 2017 9:40 am, Bob kb8tq wrote:
>> Since time stamping hardware does exist for 1588, why not simply put the
>> effort into folding that into NTP?
> 
> According to the Chrony project web page chronyd already includes support
> for that.
> See "NTP timestamping" section:
> https://chrony.tuxfamily.org/comparison.html
> 
> -- 
> Chris Caudle
> 
> 
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Chris Caudle]

On Thu, October 26, 2017 9:40 am, Bob kb8tq wrote:
> Since time stamping hardware does exist for 1588, why not simply put the
> effort into folding that into NTP?

According to the Chrony project web page chronyd already includes support
for that.
See "NTP timestamping" section:
https://chrony.tuxfamily.org/comparison.html

-- 
Chris Caudle


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Bob kb8tq]

Hi

Since time stamping hardware does exist for 1588, why not simply put the effort 
into
folding that into NTP? Then you have a “generic” solution that addresses a lot 
of the
ambiguity a wide range of cases. It shows up in many of the low end micro’s so 
it’s 
not just a “big box only” solution. It’s not a 100% solution (NTP is not 1588) 
but it 
gets rid of a lot of noise. 

Bob


> On Oct 25, 2017, at 8:53 PM, Nick Sayer via time-nuts  
> wrote:
> 
> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned 
> a lot in a relatively short time, and I really like the result.
> 
> I am considering a new project based on its cousin, the ATSAME70. The E70 has 
> an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
> (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
> Start (the software development framework I’ve been using) purports to have a 
> ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).
> 
> Where I am going with this is I am considering designing a precision embedded 
> NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up 
> to a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea 
> behind making it an embedded system would be to try and make it as accurate 
> as it reasonably can be with the hope that (at least on the local segment) it 
> would wind up being more accurate than a Pi Zero doing the same thing. At the 
> very least, you’d expect such a thing to be a whole lot less hassle to set 
> up, given decent firmware.
> 
> This may be a fool’s errand, certainly, but looking at it from here, I would 
> think that such a design might offer accuracy in the microsecond range, but 
> that’s just a tremendously uninformed guess at this point (and what does that 
> accuracy mean to a peer that might itself be incapable of better than 2 
> orders of magnitude coarser?).
> 
> Anybody have any ideas or suggestions along these lines?
> ___
> time-nuts mailing list -- time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Gary E. Miller]

Yo Nick!

On Wed, 25 Oct 2017 17:53:46 -0700
Nick Sayer via time-nuts  wrote:

> This may be a fool’s errand, certainly, but looking at it from here,
> I would think that such a design might offer accuracy in the
> microsecond range,

I'm looking at 6 Raspberry Pi's right now, each with a different GPS
model.  Running NTPec and kernel PPS.  Adjacent jitter is from 10 to 35
micro seconds over 100 Base-T.

Local PPS jitter, is from 250 ns to up to 3,000 ns.

The biggest issue is the 186 ns granularity in the kernel system
clock.  Then interrupt latency and the usual Linux stuff.

> Anybody have any ideas or suggestions along these lines?

This may be not time-nutty enough for here.  Feel free to contact
me off list.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpp8WRtok0ml.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Nick Sayer via time-nuts]

I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a 
lot in a relatively short time, and I really like the result.

I am considering a new project based on its cousin, the ATSAME70. The E70 has 
an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has 
(USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel 
Start (the software development framework I’ve been using) purports to have a 
ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).

Where I am going with this is I am considering designing a precision embedded 
NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to 
a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind 
making it an embedded system would be to try and make it as accurate as it 
reasonably can be with the hope that (at least on the local segment) it would 
wind up being more accurate than a Pi Zero doing the same thing. At the very 
least, you’d expect such a thing to be a whole lot less hassle to set up, given 
decent firmware.

This may be a fool’s errand, certainly, but looking at it from here, I would 
think that such a design might offer accuracy in the microsecond range, but 
that’s just a tremendously uninformed guess at this point (and what does that 
accuracy mean to a peer that might itself be incapable of better than 2 orders 
of magnitude coarser?).

Anybody have any ideas or suggestions along these lines?
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.