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 <mlewis...@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 -- firstname.lastname@example.org > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- email@example.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.