Related Topics: GSoC2013StartupAnalysisRahul, GSoC2013StartupAnalysisRahulDesign
iburst
, ntpd
can sync up in about 11 seconds' time.
Other conditions can cause this process to take closer to 5 minutes' time.
We want to try and "do better".
The thought is that we can do a least-squares fit and determine the offset and the drift. The key questions include for various network transports, what sort of intervals produce what sort of results?
For wired LANs we want to see what sort of results we get for, say, 20 - 120 second intervals.
It may be that if we can get us into the ballpark where we're within 128ms offset (that number might need to be smaller) and a drift estimate that is within XX ppm, that might be enough to keep everybody happy for now.
This might mean that if we're talking about a measurement interval of 14-60 seconds, we can send 8 packets over that interval. Each new minute can get a fresh recalculation.
So if we have 76 seconds of measurement time, and with the awareness that there might be a fencepost problem, we could get 15-16 measurements there, 8 in the first minute and then another 7-8 in the remaining 14-16 seconds' time.
It looks like we want to calculate y=(m-1)x+b
, where
m
is the frequency correction and
b
is the offset correction.
The reason for (m-1)
is because we can expect m
to be a floating-point value and the slope should be within parts-per-million of 1, and we'll lose a lot of precision waiting to get to the "interesting bits".
So we get the "1" out of the way and are left with only the interesting bits.
The intercept will be a value that handles the offset correction.
The closer the intercept is to "now" the less correction will need to be applied to the calculated offset.
Once we know these, we want to stop all corrections and let the machine free-run while we run our tests.
At the end of that test, we should expect that by multiplying the drift value by the number of seconds between stopping corrections and the intercept time that we'll have the same offset and drift values that the startup analysis process determines.
Likewise, another test might be to run the test on a sync'd machine with its frequency correction running, and when we run our tests we should see 0 offset and 0 drift corrections needed.
For wired networks, we think want to see what sort of results we get when we go from, say, 20 to 120 seconds, increasing by 10 seconds on each test. Once we get an idea of where the "interesting" parts of the curve are we can look more closely.
Harlan has heard that for wireless networks, this will probably take several minutes.
psp-*
machines, see the ofcalc/
subdirectories in: ~katare/ntp-dev-ofcalc/
~chen/ntp-dev-ofcalc/
"Next" to these directories is a copy of Dragonfly's NTP, in the dntpd/
subdirectory.
Much can be learned from the study of this code...
Philip Prindeville has extended this work.