``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards
The desktop PCs can each be configured with as many reference clocks
as you like. That is independent of how many stratum 1 NTP servers a
company needs to operate. Maybe you are running some stratum 2
servers on your routers and using more from the Internet. All these
choices are independent of each other.
If you are serving Windows PCs then, I think those are all running
SNTP and then use just one NTP server
For most companies there really is no need to even have a GPS
receiver. Being within 10 milliseconds is just fine so pool servers
will do.
I would argue that you need at least three servers (and more like five). When given only two
servers NTP simply dithers back and forth between them. It does not have
a way to figure out which of two clocks is wrong. It will detect a missing clock, but
not one that is simply off time by a bit.
--
Chris Albertson
Redondo Beach, California
Your processing machine is going to be running NTP with a reference
clock being your local status 1 NTP server
I think the processing machine would see a lighter load if it's NTP
was using GPS as the reference rather thennother NTP server. In
other words the processing box, the one with the 4Hz work load could
be an isolated strum 1 NTP server with no other connected computers.
Servicing the GPS interface is nearly trivial, much simply then going
over the network to another server. An ntpd that is running as
strum one that has no other ntpd connected to it has VERY little to do
BTW I first learned about NTP formerly this same reason. I was
writing firmware for an astronomical CCD camera and we wanted to know
EXACTLY when exposures started and stopped.
On Wed, Feb 15, 2017 at 7:09 PM, MLewis mlewis000@rogers.com wrote:
On 15/02/2017 1:17 PM, Chris Albertson wrote:
Why set up a dedicated NTP server if you only have two computers that will
use it? ... You could save some money and just run NTP on the two computers.
... NTP is almost zero load on the CPU and the best thing is the NTP
accuracy is not effected by CPU load...
My application cycles between a low background load to a full CPU load on
hex cores four times a second on the quarter-second. Each quarter-second
load, for each of 22 datasets, first takes a data snapshot, then does some
processing, which for any or all of the datasets may trigger more
processing, and when all dataset processing treads are complete, this is
followed by some house-keeping tasks. Therefore the duration of those full
loads varies, and one of the four quarter-second loads has more to do and is
significantly longer than the other three. To get the quarter-second loads
done as fast as possible, the bios is set to run the CPU in turbo
continuously, otherwise power saving 'features' start dialing back core
speed and shutting down cores, resulting in the longer quarter-second task
not getting done within 250 ms in time for the next quarter-second's start.
The rate of accumulating lag on system time varies from 2 ms a minute to 16
ms a minute, depending on the load. The result is that the quarter-second
data snapshots don't start on the actual quarter-second, off more and more
as lag accumulates, until they're off their target time by more than a
second, then seconds, etc..
With NTP polling six pool sources while my application is cycling between
load levels four times a second, the observed quarter-second start drifts
within roughly 300 ms, sometimes 600 ms.
That wasn't exactly a surprise. The base application I'm working from used
Apache's NTPUDPClient to maintain an offset from system time from a single
NTP source. After expanding the design to use multiple NTP sources, I found
that the reported offsets from pools were stable when my CPU load was
stable, but when it was cycling in/out of the heavy loads, the reported
offsets became more variable between sources and the number and offset of
reported offsets that were outliers became ridiculous. As much fun as it was
to design custom cascading outlier filters, this led me to abandon the
underlying base application's offset to system time and use NTP to maintain
system time.
To be able to move forward with my original application:
By going to a separate box running NTP and a GPS reference, I will have a
reference time that is entirely independent from whatever is going on with
my working box. With microsecond accuracy and precision, it will be more
than sufficient for my needs. With a dedicated ethernet connection between
the working box and the NTP box, NTP on the working box should be able to
have system time within 1 ms of that reference. If it's observed that isn't
happening, then I'll remove NTP from the working box and I already have code
than can monitor the system time against the NTP box and reset it every time
it lags more than 1 ms. Brute and crude, but it will work for keeping my
application within 1ms.
Or, so I think...
I've been surprised and changed direction enough times since I headed down
this time rabbit-hole.
Michael
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.
--
Chris Albertson
Redondo Beach, California
Le 16 févr. 2017 à 04:09, MLewis mlewis000@rogers.com a écrit :
On 15/02/2017 1:17 PM, Chris Albertson wrote:
Why set up a dedicated NTP server if you only have two computers that will use it? ... You could save some money and just run NTP on the two computers. ... NTP is almost zero load on the CPU and the best thing is the NTP accuracy is not effected by CPU load…
This is not strictly true in all scenarios as the NTP thread has to be able to get to a cpu to be able to do its thing. Higher priority, or CPU intensive threads can starve it.
Here is the result of a little test on a 700MHz clocked 4 core uP running linux with usual utilities NTP, cron whatever, but no apps . No priority or core dedication implemented.
The uP is running NTP with two GPS sync’d servers at stratum 1 on the LAN plus 5 stratum 2 pool servers. poll time 64 secs for all.
- Check the clock offset of the DUT as reported by ntpdate -d with the DUT idle.
mike@muon /usr/home/mike $ ntpdate -d rasp3b1 2> /dev/null | grep adjust
16 Feb 11:17:46 ntpdate[11566]: adjust time server 192.168.1.157 offset -0.000086 sec
16 Feb 11:19:32 ntpdate[11569]: adjust time server 192.168.1.157 offset -0.000085 sec
16 Feb 11:21:18 ntpdate[11587]: adjust time server 192.168.1.157 offset -0.000082 sec
16 Feb 11:23:05 ntpdate[11590]: adjust time server 192.168.1.157 offset -0.000054 sec
16 Feb 11:24:51 ntpdate[11593]: adjust time server 192.168.1.157 offset -0.000028 sec
16 Feb 11:26:37 ntpdate[11611]: adjust time server 192.168.1.157 offset 0.000008 sec
16 Feb 11:28:24 ntpdate[11614]: adjust time server 192.168.1.157 offset 0.000026 sec
16 Feb 11:30:10 ntpdate[11632]: adjust time server 192.168.1.157 offset 0.000059 sec - Start up 4 cpu soaker threads - in this case calculating pi to 10000 places.
11:31:00 4 cpu soakers started on rasp3b1 - Continue checking clock offsets.
16 Feb 11:33:42 ntpdate[11638]: adjust time server 192.168.1.157 offset -0.000089 sec
16 Feb 11:35:29 ntpdate[11656]: adjust time server 192.168.1.157 offset -0.000235 sec
16 Feb 11:37:15 ntpdate[11659]: adjust time server 192.168.1.157 offset -0.000393 sec
16 Feb 11:39:01 ntpdate[11662]: adjust time server 192.168.1.157 offset -0.000512 sec
16 Feb 11:40:48 ntpdate[11680]: adjust time server 192.168.1.157 offset -0.000547 sec
16 Feb 11:42:34 ntpdate[11683]: adjust time server 192.168.1.157 offset -0.000492 sec
16 Feb 11:44:20 ntpdate[11686]: adjust time server 192.168.1.157 offset -0.000438 sec
16 Feb 11:46:07 ntpdate[11704]: adjust time server 192.168.1.157 offset -0.000397 sec
16 Feb 11:47:53 ntpdate[11709]: adjust time server 192.168.1.157 offset -0.000393 sec
16 Feb 11:49:39 ntpdate[11712]: adjust time server 192.168.1.157 offset -0.000357 sec
16 Feb 11:51:26 ntpdate[11730]: adjust time server 192.168.1.157 offset -0.000206 sec
As you can see the reported clock offset increases to a max 0,5ms due to the load on the DUT. That is within the OPs limit so he should be ok but for others that may be too much of a hit.
- wait till the processes stop
They all ended normally at Thu 16 Feb 12:04:36 UTC 2017 - While continuing to check the offsets as reported by ntpdate
16 Feb 12:00:17 ntpdate[11775]: adjust time server 192.168.1.157 offset 0.000153 sec
16 Feb 12:02:03 ntpdate[11778]: adjust time server 192.168.1.157 offset 0.000188 sec
16 Feb 12:03:50 ntpdate[11781]: adjust time server 192.168.1.157 offset 0.000203 sec
16 Feb 12:05:36 ntpdate[11799]: adjust time server 192.168.1.157 offset 0.000126 sec
16 Feb 12:07:22 ntpdate[11802]: adjust time server 192.168.1.157 offset 0.000092 sec
16 Feb 12:09:09 ntpdate[11805]: adjust time server 192.168.1.157 offset 0.000096 sec
16 Feb 12:10:55 ntpdate[11823]: adjust time server 192.168.1.157 offset 0.000051 sec
16 Feb 12:12:41 ntpdate[11826]: adjust time server 192.168.1.157 offset 0.000008 sec
16 Feb 12:14:28 ntpdate[11829]: adjust time server 192.168.1.157 offset 0.000002 sec
16 Feb 12:16:14 ntpdate[11847]: adjust time server 192.168.1.157 offset -0.000016 sec
16 Feb 12:18:00 ntpdate[11852]: adjust time server 192.168.1.157 offset 0.000007 sec
16 Feb 12:19:46 ntpdate[11855]: adjust time server 192.168.1.157 offset 0.000009 sec
16 Feb 12:21:33 ntpdate[11873]: adjust time server 192.168.1.157 offset 0.000012 sec
back to normal status.
The test is not supposed to be an all inclusive and YMMV.
There are probably methods, such a configuring detected cores for NTP , increasing its priority, and maybe increasing the poll interval that can mitigate the effect.
I’ll try that to see what I get.
To be able to move forward with my original application:
By going to a separate box running NTP and a GPS reference, I will have a reference time that is entirely independent from whatever is going on with my working box. With microsecond accuracy and precision, it will be more than sufficient for my needs. With a dedicated ethernet connection between the working box and the NTP box, NTP on the working box should be able to have system time within 1 ms of that reference. If it's observed that isn't happening, then I'll remove NTP from the working box and I already have code than can monitor the system time against the NTP box and reset it every time it lags more than 1 ms. Brute and crude, but it will work for keeping my application within 1ms.
Toi should be ok if you see a similar profile.
Just to note that on my DUT prior to the 100% load the clock drift as reported by NTP was -6,5ppm . Without NTP or other disciplining a 1ms offset would have been reached in 108 secs.
Or, so I think...
I've been surprised and changed direction enough times since I headed down this time rabbit-hole.
Michael
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
Hi
On Feb 16, 2017, at 1:30 AM, Ruslan Nabioullin rnabioullin@gmail.com wrote:
On 02/15/2017 01:17 PM, Chris Albertson wrote:
Why set up a dedicated NTP server if you only have two computers
that will use it? Your server will be accurate to a few
microseconds but your two computers will only by good to a few
milliseconds because ethernet is not nearly as good as PPS.
Well Ethernet can be extremely accurate if PTP is used (a whitepaper specifies <= 100 ns accuracy if the LAN is optimized for it).
PTP single shot over ethernet is not at the < 100 ns level, even with proper cards. In real world settings, the traffic level for sub
100 ns PTP can be pretty high. Some situations appear to require > 100K transactions per second. I’ve never seen anything quite that
extreme myself.
Bob
Well, the assumption here is that one would render this service available to the public, registering the server(s) with the NTP website and/or the NTP Pool Project; n.b. this is still possible for connections lacking a static IP address, by means of an IPv6 tunnel, available at no cost from at least one vendor. Otherwise yes, by some perspectives it can be considered quite pointless and wasteful to operate dedicated servers, standards, receivers, etc. with no means of time transfer to customers.
NTP is almost zero load on the CPU and the best thing is the NTP
accuracy is not effected by CPU load SO you can run other service
without degrading the NTP server.
Well n.b. TVB's hardware PPS timestamping post. Also WWV and CHU decoding by NTP's modules can be problematic, as well as the obvious case of the server being overloaded. Finally note that based on others' experimentation, the motherboard's XO temperature is nontrivially-highly correlated with CPU load, so for better motherboard XO-based holdover performance, once must create an ersatz oven utilizing the CPU(s), by running them at full utilization (obviously with proper scheduling priority), so typically volunteer distributed computing project(s) such as BOINC (SETI@home, etc.), Folding@Home, etc. Of course then power consumption becomes problematic.
-Ruslan
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.
Hi
Whatever you do on the server, the same impacts will be felt on the client side. You may be
able to do this or that on a server to allocate resources. On a client workstation, resource
allocation is likely to be a bit more difficult. You may not even have control over which
OS is being used. ( = other factors may dictate it’s Windows 10, or OS-X or …). When a
big video processing blob comes along, the workstation likely ignores NTP for a while.
Bob
On Feb 16, 2017, at 7:05 AM, Mike Cook michael.cook@sfr.fr wrote:
Le 16 févr. 2017 à 04:09, MLewis mlewis000@rogers.com a écrit :
On 15/02/2017 1:17 PM, Chris Albertson wrote:
Why set up a dedicated NTP server if you only have two computers that will use it? ... You could save some money and just run NTP on the two computers. ... NTP is almost zero load on the CPU and the best thing is the NTP accuracy is not effected by CPU load…
This is not strictly true in all scenarios as the NTP thread has to be able to get to a cpu to be able to do its thing. Higher priority, or CPU intensive threads can starve it.
Here is the result of a little test on a 700MHz clocked 4 core uP running linux with usual utilities NTP, cron whatever, but no apps . No priority or core dedication implemented.
The uP is running NTP with two GPS sync’d servers at stratum 1 on the LAN plus 5 stratum 2 pool servers. poll time 64 secs for all.
- Check the clock offset of the DUT as reported by ntpdate -d with the DUT idle.
mike@muon /usr/home/mike $ ntpdate -d rasp3b1 2> /dev/null | grep adjust
16 Feb 11:17:46 ntpdate[11566]: adjust time server 192.168.1.157 offset -0.000086 sec
16 Feb 11:19:32 ntpdate[11569]: adjust time server 192.168.1.157 offset -0.000085 sec
16 Feb 11:21:18 ntpdate[11587]: adjust time server 192.168.1.157 offset -0.000082 sec
16 Feb 11:23:05 ntpdate[11590]: adjust time server 192.168.1.157 offset -0.000054 sec
16 Feb 11:24:51 ntpdate[11593]: adjust time server 192.168.1.157 offset -0.000028 sec
16 Feb 11:26:37 ntpdate[11611]: adjust time server 192.168.1.157 offset 0.000008 sec
16 Feb 11:28:24 ntpdate[11614]: adjust time server 192.168.1.157 offset 0.000026 sec
16 Feb 11:30:10 ntpdate[11632]: adjust time server 192.168.1.157 offset 0.000059 sec - Start up 4 cpu soaker threads - in this case calculating pi to 10000 places.
11:31:00 4 cpu soakers started on rasp3b1 - Continue checking clock offsets.
16 Feb 11:33:42 ntpdate[11638]: adjust time server 192.168.1.157 offset -0.000089 sec
16 Feb 11:35:29 ntpdate[11656]: adjust time server 192.168.1.157 offset -0.000235 sec
16 Feb 11:37:15 ntpdate[11659]: adjust time server 192.168.1.157 offset -0.000393 sec
16 Feb 11:39:01 ntpdate[11662]: adjust time server 192.168.1.157 offset -0.000512 sec
16 Feb 11:40:48 ntpdate[11680]: adjust time server 192.168.1.157 offset -0.000547 sec
16 Feb 11:42:34 ntpdate[11683]: adjust time server 192.168.1.157 offset -0.000492 sec
16 Feb 11:44:20 ntpdate[11686]: adjust time server 192.168.1.157 offset -0.000438 sec
16 Feb 11:46:07 ntpdate[11704]: adjust time server 192.168.1.157 offset -0.000397 sec
16 Feb 11:47:53 ntpdate[11709]: adjust time server 192.168.1.157 offset -0.000393 sec
16 Feb 11:49:39 ntpdate[11712]: adjust time server 192.168.1.157 offset -0.000357 sec
16 Feb 11:51:26 ntpdate[11730]: adjust time server 192.168.1.157 offset -0.000206 sec
As you can see the reported clock offset increases to a max 0,5ms due to the load on the DUT. That is within the OPs limit so he should be ok but for others that may be too much of a hit.
- wait till the processes stop
They all ended normally at Thu 16 Feb 12:04:36 UTC 2017 - While continuing to check the offsets as reported by ntpdate
16 Feb 12:00:17 ntpdate[11775]: adjust time server 192.168.1.157 offset 0.000153 sec
16 Feb 12:02:03 ntpdate[11778]: adjust time server 192.168.1.157 offset 0.000188 sec
16 Feb 12:03:50 ntpdate[11781]: adjust time server 192.168.1.157 offset 0.000203 sec
16 Feb 12:05:36 ntpdate[11799]: adjust time server 192.168.1.157 offset 0.000126 sec
16 Feb 12:07:22 ntpdate[11802]: adjust time server 192.168.1.157 offset 0.000092 sec
16 Feb 12:09:09 ntpdate[11805]: adjust time server 192.168.1.157 offset 0.000096 sec
16 Feb 12:10:55 ntpdate[11823]: adjust time server 192.168.1.157 offset 0.000051 sec
16 Feb 12:12:41 ntpdate[11826]: adjust time server 192.168.1.157 offset 0.000008 sec
16 Feb 12:14:28 ntpdate[11829]: adjust time server 192.168.1.157 offset 0.000002 sec
16 Feb 12:16:14 ntpdate[11847]: adjust time server 192.168.1.157 offset -0.000016 sec
16 Feb 12:18:00 ntpdate[11852]: adjust time server 192.168.1.157 offset 0.000007 sec
16 Feb 12:19:46 ntpdate[11855]: adjust time server 192.168.1.157 offset 0.000009 sec
16 Feb 12:21:33 ntpdate[11873]: adjust time server 192.168.1.157 offset 0.000012 sec
back to normal status.
The test is not supposed to be an all inclusive and YMMV.
There are probably methods, such a configuring detected cores for NTP , increasing its priority, and maybe increasing the poll interval that can mitigate the effect.
I’ll try that to see what I get.
To be able to move forward with my original application:
By going to a separate box running NTP and a GPS reference, I will have a reference time that is entirely independent from whatever is going on with my working box. With microsecond accuracy and precision, it will be more than sufficient for my needs. With a dedicated ethernet connection between the working box and the NTP box, NTP on the working box should be able to have system time within 1 ms of that reference. If it's observed that isn't happening, then I'll remove NTP from the working box and I already have code than can monitor the system time against the NTP box and reset it every time it lags more than 1 ms. Brute and crude, but it will work for keeping my application within 1ms.
Toi should be ok if you see a similar profile.
Just to note that on my DUT prior to the 100% load the clock drift as reported by NTP was -6,5ppm . Without NTP or other disciplining a 1ms offset would have been reached in 108 secs.
Or, so I think...
I've been surprised and changed direction enough times since I headed down this time rabbit-hole.
Michael
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.
If your Ethernet chipset (mac or phy) has timestamping capabilities, you can use Chrony which has hardware timestamp support. This greatly improves accuracy, and generally eliminates the CPU loading issue.
Denny
Ntp has support to pick up hardware packet timestamps from the Linux
kernel. I wrote the patch; it was merged years ago.
-ch
73 de AI6KG
On Thu, Feb 16, 2017 at 9:59 AM, Denny Page denny@cococafe.com wrote:
If your Ethernet chipset (mac or phy) has timestamping capabilities, you
can use Chrony which has hardware timestamp support. This greatly improves
accuracy, and generally eliminates the CPU loading issue.
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.
Yo Chris!
On Wed, 15 Feb 2017 23:48:39 -0800
Chris Albertson albertson.chris@gmail.com wrote:
An ntpd that is running as
strum one that has no other ntpd connected to it has VERY little to do
That would be a marginal configuration. I have yet to see a GPS that
did not lose sat lock, or lep second, or UTC offset now and then. Best
practice is to have at least 3 other network chimers configured.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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
Le 16 févr. 2017 à 13:05, Mike Cook michael.cook@sfr.fr a écrit :
Le 16 févr. 2017 à 04:09, MLewis mlewis000@rogers.com a écrit :
On 15/02/2017 1:17 PM, Chris Albertson wrote:
Why set up a dedicated NTP server if you only have two computers that will use it? ... You could save some money and just run NTP on the two computers. ... NTP is almost zero load on the CPU and the best thing is the NTP accuracy is not effected by CPU load…
This is not strictly true in all scenarios as the NTP thread has to be able to get to a cpu to be able to do its thing. Higher priority, or CPU intensive threads can starve it.
< snipped>
The test is not supposed to be an all inclusive and YMMV.
There are probably methods, such a configuring detected cores for NTP , increasing its priority, and maybe increasing the poll interval that can mitigate the effect.
detected should have been dedicated of course - damned spell checker
I’ll try that to see what I get.
As I thought the issue can be worked around by tweaking scheduling and cpu affinity.
When I fixed ntpd on cpu 0 and put it in the fifo real time scheduling class there was no change in reported clock offsets when running the same test load.
"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw
Yes, that is the normal "best practice case". But the OPand myself
some years go
both have a difference use case. In this case no other machine
needs to know the time.
I only care about one computer.
The reason I used NTp back then and he is using it now is to calibrate
the rate of a real-time process running on that one computer. In
this special case it makes sense to connect GPS PPS to the computer
and use no other source of time.
On Thu, Feb 16, 2017 at 10:58 AM, Gary E. Miller gem@rellim.com wrote:
Yo Chris!
On Wed, 15 Feb 2017 23:48:39 -0800
Chris Albertson albertson.chris@gmail.com wrote:
An ntpd that is running as
strum one that has no other ntpd connected to it has VERY little to do
That would be a marginal configuration. I have yet to see a GPS that
did not lose sat lock, or lep second, or UTC offset now and then. Best
practice is to have at least 3 other network chimers configured.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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
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.
--
Chris Albertson
Redondo Beach, California