On Mon, 02 Apr 2007 13:02:40 +0200, Spoon wrote: > Richard B. gilbert wrote: > >> Spoon wrote: >> >>> I've read this page: >>> http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP >>> which explains how to let NTP determine the frequency offset (skew). >>> >>> I have a strange request: >>> >>> Is it possible to run NTP in a mode where it does not try to correct >>> the time offset, but only correct the frequency offset (skew)? >>> >>> In other words, assume my clock says it is some time last year, and >>> gains 1 second every day (11.6 ppm). I don't want NTP to either slew >>> or step my clock to the correct time, but I still would want it to fix >>> this 1 s per day (11.6 ppm) frequency offset. >>> >>> Has this ever been considered? >> >> I doubt it very much! >> >>> Is there a variable I could tinker with? :-) >> >> I don't know of any. >> >> What problem are you trying to solve? >> >> Most people want the correct time rather than simply a clock keeping the >> wrong time but one that ticks at one second per second. > > I'll try to explain my situation in detail. > > Consider two systems, A and B. > > A sends ~1000 UDP packets per second to B. > > A timestamps each packet. > > These packets travel over an IP network, and suffer delay and jitter. > > B is supposed to re-send the packets it receives at the rate they > were originally sent by A. > > B buffers N packets. Then it sends the first packet in the queue, > computes the departure time of the next packet using the timestamps > provided by A, and sleeps until that departure time. > > If the clocks on A and B do not tick at the same rate, the buffer used > by B will either overflow or underflow. > If the problem is to not have overflow or underflow then why not steer on how full the buffer are. The master(A) send packets out at its rate. B answers trying to have N in the buffer. Could you change the protocol and allow to flag that a packet is going to be dropped or send a dummmy answer? Sending packet at a smooth rate of 1000Hz requires a fairly accurate scheduling.
(In telecom they have the same problem. Their solution involves systems of frequency syncronized clocks) /hjj _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
