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.
