Re: [time-nuts] Designing an embedded precision GPS time
From: Attila Kinali attila@kinali.ch
Can you tell a little bit how your device looks like on the inside?
GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop with prioritised interrupts. Network stack is hand-made.
I don't use saw-tooth correction in this device because +-11ns is not worth correcting for NTP application for such a budget device.
If you can build a test NTP client system that can detect sawtooth 10ns offset from the NTP server I'd like to know how you did it.
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)
Sorry, it was a typo - I meant Chinese zone (.cn)
Spikes usually happen around full or half-hour and last only few seconds but you often (about once a day) get true 100% fully saturated wire speed with packets coming in (and out) back to back.
The theory behind these spikes is interesting - most probably they are results of SNTP clients running from cron jobs. So, ironically, the more accurate time they receive from you, the more concentrated their behaviour becomes.
Leo
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
From: Attila Kinali attila@kinali.ch
Can you tell a little bit how your device looks like on the inside?
GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop with prioritised interrupts. Network stack is hand-made.
I don't use saw-tooth correction in this device because +-11ns is not worth correcting for NTP application for such a budget device.
If you can build a test NTP client system that can detect sawtooth 10ns offset from the NTP server I'd like to know how you did it.
True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To put this into perspective have a look at the two attached plots.
These are the PPM values that ntp reports for a standard server (HP DL380G7).
The first plot shows the long term variation of all the data I currently have.
The three jumps coincide with days when we restarted ntpd. As you can see,
the long term variation of the crystal frequency is well below 0.5ppm. The
second plot zooms in into one of the day with large variations. The worst
of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
instantaneous, then this would result in a hold over performance of ~0.9ms
in 24h. Yes, this is not a fair comparison. The sever is in a room where
temperature is pretty much constant (sorry, I don't have any data on that,
but assume less than 5°C variation within a day). And it's not true hold
over performance, but a guestimation from the ntp provided loop data. But
even if we add a factor of 10, this simple, unstabilized, unsophisticated
PC comes pretty close to the performance your device claims. And that's not
even a PC with a good crystal (I have measurements of others, that showed
variation of less than 2ppb over months in rooms without air conditioning).
Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
put everything in a metal box and just use normal ntpd, i'd expect to
have a hold over performance of better than 100ms/24h (assuming 1ppm
stability of the crystal), probably in the order of 10ms/24h and it would
have no problems handling a humongous number of clients, thanks to the
fast CPU (1.4GHz) and the Gbit/s ethernet interface.
So, why does a simple PC with ntp do such a good job? The secret
lies in the measurement: Very much simplified, ntp measures the
frequency in 1000s intervals. Measurement uncertainty is reported to be
better than 100us per reference server. Ie the uncertainty is in
better than 1e-7 (compare with the estimated 5e-8 from above).
Add to that averaging over multiple reference severs (4 in this case)
and a sophisticated clock parameter estimation and the uncertainty
goes down quite a bit.
To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
HI
TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C
is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO.
Dividing the total deviation of either one by the temperature range to come
up with a “delta frequency per degree” number would be a mistake. You
would get a number that is much better than the real part exhibits.
Working all this back into a holdover spec in an unknown temperature
environment is not at all easy.
Bob
On Oct 31, 2017, at 4:03 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
From: Attila Kinali attila@kinali.ch
Can you tell a little bit how your device looks like on the inside?
GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop with prioritised interrupts. Network stack is hand-made.
I don't use saw-tooth correction in this device because +-11ns is not worth correcting for NTP application for such a budget device.
If you can build a test NTP client system that can detect sawtooth 10ns offset from the NTP server I'd like to know how you did it.
True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To put this into perspective have a look at the two attached plots.
These are the PPM values that ntp reports for a standard server (HP DL380G7).
The first plot shows the long term variation of all the data I currently have.
The three jumps coincide with days when we restarted ntpd. As you can see,
the long term variation of the crystal frequency is well below 0.5ppm. The
second plot zooms in into one of the day with large variations. The worst
of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
instantaneous, then this would result in a hold over performance of ~0.9ms
in 24h. Yes, this is not a fair comparison. The sever is in a room where
temperature is pretty much constant (sorry, I don't have any data on that,
but assume less than 5°C variation within a day). And it's not true hold
over performance, but a guestimation from the ntp provided loop data. But
even if we add a factor of 10, this simple, unstabilized, unsophisticated
PC comes pretty close to the performance your device claims. And that's not
even a PC with a good crystal (I have measurements of others, that showed
variation of less than 2ppb over months in rooms without air conditioning).
Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
put everything in a metal box and just use normal ntpd, i'd expect to
have a hold over performance of better than 100ms/24h (assuming 1ppm
stability of the crystal), probably in the order of 10ms/24h and it would
have no problems handling a humongous number of clients, thanks to the
fast CPU (1.4GHz) and the Gbit/s ethernet interface.
So, why does a simple PC with ntp do such a good job? The secret
lies in the measurement: Very much simplified, ntp measures the
frequency in 1000s intervals. Measurement uncertainty is reported to be
better than 100us per reference server. Ie the uncertainty is in
better than 1e-7 (compare with the estimated 5e-8 from above).
Add to that averaging over multiple reference severs (4 in this case)
and a sophisticated clock parameter estimation and the uncertainty
goes down quite a bit.
To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
<hakuoro.png><hakuoro-zoom.png>_______________________________________________
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.
If one is building a GPS disciplined NTP Stratum 1 server from a Pi or
Beaglebone, the "better" quality RTCs seem to be
DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C,
±3.5ppm from -40°C to +85°C
or
NXP:
PCF2127AT: ±3 ppm from -15 °C to +60 °C
PCF2127T: ±3 ppm from -30 °C to +80 °C
PCF2129AT: ±3 ppm from -15 °C to +60 °C
PCF2129T: ±3 ppm from -30 °C to +80 °C
How does one translate that into an expected 24 hour holdover?
And, are there better choices for a low cost RTC?
Thanks,
Michael
On 31/10/2017 4:47 PM, Bob kb8tq wrote:
HI
TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C
is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO.
Dividing the total deviation of either one by the temperature range to come
up with a “delta frequency per degree” number would be a mistake. You
would get a number that is much better than the real part exhibits.
Working all this back into a holdover spec in an unknown temperature
environment is not at all easy.
Bob
On Oct 31, 2017, at 4:03 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
HI
On Oct 31, 2017, at 8:19 PM, MLewis mlewis000@rogers.com wrote:
If one is building a GPS disciplined NTP Stratum 1 server from a Pi or Beaglebone, the "better" quality RTCs seem to be
DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C, ±3.5ppm from -40°C to +85°C
or
NXP:
PCF2127AT: ±3 ppm from -15 °C to +60 °C
PCF2127T: ±3 ppm from -30 °C to +80 °C
PCF2129AT: ±3 ppm from -15 °C to +60 °C
PCF2129T: ±3 ppm from -30 °C to +80 °C
How does one translate that into an expected 24 hour holdover?
The simple answer is that you really don’t have enough information.
The useless answer (which is easy to come up with) is that you would be off by a bit under 0.3 seconds per day if you clock is 3 ppm off.
Since that’s just the TC error, there would have to be a zeroing process. If you “zero out” the error at -3 ppm and then temperature
moves you to +3 ppm, you could be off by a bit under 0.6 seconds in a day. Yes you could carry this out to many more digits, it’s really
an accurate guess beyond the first digit.
Bob
And, are there better choices for a low cost RTC?
Thanks,
Michael
On 31/10/2017 4:47 PM, Bob kb8tq wrote:
HI
TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to +85C
is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO.
Dividing the total deviation of either one by the temperature range to come
up with a “delta frequency per degree” number would be a mistake. You
would get a number that is much better than the real part exhibits.
Working all this back into a holdover spec in an unknown temperature
environment is not at all easy.
Bob
On Oct 31, 2017, at 4:03 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
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.
At the moment, my plan is to not support hold-over at all. If GPS doesn’t have a fix and I’m not getting PPS pulses, I intend to either jump immediately to stratum 16 or just not respond.
On Oct 31, 2017, at 1:03 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
From: Attila Kinali attila@kinali.ch
Can you tell a little bit how your device looks like on the inside?
GPS is a Ublox. MCU is Cortex-M7 and does not run any OS - just main loop with prioritised interrupts. Network stack is hand-made.
I don't use saw-tooth correction in this device because +-11ns is not worth correcting for NTP application for such a budget device.
If you can build a test NTP client system that can detect sawtooth 10ns offset from the NTP server I'd like to know how you did it.
True. An NTP server does not need to measure time better than 100ns or so.
10ns is probably more than good enough. But then, this raises the question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To put this into perspective have a look at the two attached plots.
These are the PPM values that ntp reports for a standard server (HP DL380G7).
The first plot shows the long term variation of all the data I currently have.
The three jumps coincide with days when we restarted ntpd. As you can see,
the long term variation of the crystal frequency is well below 0.5ppm. The
second plot zooms in into one of the day with large variations. The worst
of these being about 10ppb. Lets assume for simplicity, the 10ppb step happens
instantaneous, then this would result in a hold over performance of ~0.9ms
in 24h. Yes, this is not a fair comparison. The sever is in a room where
temperature is pretty much constant (sorry, I don't have any data on that,
but assume less than 5°C variation within a day). And it's not true hold
over performance, but a guestimation from the ntp provided loop data. But
even if we add a factor of 10, this simple, unstabilized, unsophisticated
PC comes pretty close to the performance your device claims. And that's not
even a PC with a good crystal (I have measurements of others, that showed
variation of less than 2ppb over months in rooms without air conditioning).
Or to put it differently: If i'd get a Minnow Turbot, add a GPS receiver,
put everything in a metal box and just use normal ntpd, i'd expect to
have a hold over performance of better than 100ms/24h (assuming 1ppm
stability of the crystal), probably in the order of 10ms/24h and it would
have no problems handling a humongous number of clients, thanks to the
fast CPU (1.4GHz) and the Gbit/s ethernet interface.
So, why does a simple PC with ntp do such a good job? The secret
lies in the measurement: Very much simplified, ntp measures the
frequency in 1000s intervals. Measurement uncertainty is reported to be
better than 100us per reference server. Ie the uncertainty is in
better than 1e-7 (compare with the estimated 5e-8 from above).
Add to that averaging over multiple reference severs (4 in this case)
and a sophisticated clock parameter estimation and the uncertainty
goes down quite a bit.
To summarize: If you want to improve your ntp devices hold over performance
you have to improve the frequency measurement and use a better clock modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
<hakuoro.png><hakuoro-zoom.png>_______________________________________________
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.
On Tue, October 31, 2017 7:19 pm, MLewis wrote:
...the "better" quality RTCs seem to be DS3231 based
How does one translate that into an expected 24 hour holdover?
For the RTC, or for an NTP server? If the NTP server is running it will
not make a difference, modern operating systems do not use the RTC for the
system clock, only to get close to the correct time at startup.
--
Chris Caudle
I don't know of any "non-historic" NTP implementation that even attempts to
drift correct the RTC clock.
Now, the RTC clock is useful to set the time at boot before ntpd gets
started.
Tim N3QE
On Tue, Oct 31, 2017 at 8:19 PM, MLewis mlewis000@rogers.com wrote:
If one is building a GPS disciplined NTP Stratum 1 server from a Pi or
Beaglebone, the "better" quality RTCs seem to be
DS3231 based (DallasSemi/Maxim), Accuracy ±2ppm from 0°C to +40°C, ±3.5ppm
from -40°C to +85°C
or
NXP:
PCF2127AT: ±3 ppm from -15 °C to +60 °C
PCF2127T: ±3 ppm from -30 °C to +80 °C
PCF2129AT: ±3 ppm from -15 °C to +60 °C
PCF2129T: ±3 ppm from -30 °C to +80 °C
How does one translate that into an expected 24 hour holdover?
And, are there better choices for a low cost RTC?
Thanks,
Michael
On 31/10/2017 4:47 PM, Bob kb8tq wrote:
HI
TCXO is a very loosely defined term. A part that does +/- 5 ppm -40 to
+85C
is a TCXO. A part that does +/- 5x10^-9 over 0 to 50C may also be a TCXO.
Dividing the total deviation of either one by the temperature range to
come
up with a “delta frequency per degree” number would be a mistake. You
would get a number that is much better than the real part exhibits.
Working all this back into a holdover spec in an unknown temperature
environment is not at all easy.
Bob
On Oct 31, 2017, at 4:03 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Leo,
On Sat, 28 Oct 2017 11:14:08 +0100
Leo Bodnar leo@leobodnar.com wrote:
True. An NTP server does not need to measure time better than 100ns or
so.
10ns is probably more than good enough. But then, this raises the
question
what your performance metric is that you optimize for?
If it is hold-over, then this will be limited by the TCXO and how well
you can measure its frequency, which in turn depends on how well you
can measure the PPS pulse. You say that your device is typically within
4-5ms in 24h of hold-over. That translates to frequency uncertainty
of approximately 5e-8. That's not that good.
To summarize: If you want to improve your ntp devices hold over
performance
you have to improve the frequency measurement and use a better clock
modeling.
Ie, use a timing GPS receiver and its sawtooth correction, and model the
clocks frequency change over time.
Attila Kinali
--
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
I'm intending to add a "precision" (well, precision to the Pi world) RTC
to my Pi 3 to use for a holdover source when it hasn't got PPS from the
GPS module.
On 31/10/2017 10:04 PM, Chris Caudle wrote:
On Tue, October 31, 2017 7:19 pm, MLewis wrote:
...the "better" quality RTCs seem to be DS3231 based
How does one translate that into an expected 24 hour holdover?
For the RTC, or for an NTP server? If the NTP server is running it will
not make a difference, modern operating systems do not use the RTC for the
system clock, only to get close to the correct time at startup.
Hi
Under what conditions would you expect to loose GPS? I seem to be able to
do just fine sitting in an armchair here in the family room. That’s hardly a
fancy setup.
Bob
On Oct 31, 2017, at 10:27 PM, MLewis mlewis000@rogers.com wrote:
I'm intending to add a "precision" (well, precision to the Pi world) RTC to my Pi 3 to use for a holdover source when it hasn't got PPS from the GPS module.
On 31/10/2017 10:04 PM, Chris Caudle wrote:
On Tue, October 31, 2017 7:19 pm, MLewis wrote:
...the "better" quality RTCs seem to be DS3231 based
How does one translate that into an expected 24 hour holdover?
For the RTC, or for an NTP server? If the NTP server is running it will
not make a difference, modern operating systems do not use the RTC for the
system clock, only to get close to the correct time at startup.
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.