Preliminary results of using GPS to look for clock skew
dave.taht at gmail.com
Thu Sep 22 05:08:58 EDT 2011
On Wed, Sep 21, 2011 at 7:11 PM, Eric Raymond <esr at thyrsus.com> wrote:
> Dave Taht <dave.taht at gmail.com>:
>> 1) Run the router WITHOUT ntp enabled at all
>> (and/or testing against CLOCK_REALTIME)
>> It would be good to know how much the base clock drift is, without
My bad. I meant to say CLOCK_MONOTONIC
> One of the things I don't know, and need to understand, is what the
> relationships are among the different realtime clocks. The clock_gettime(3)
> manual page is not hugely helpful. It says:
> System-wide real-time clock. Setting this clock requires appro‐
> priate privileges.
> Clock that cannot be set and represents monotonic time since
> some unspecified starting point.
> CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
> Similar to CLOCK_MONOTONIC, but provides access to a raw hard‐
> ware-based time that is not subject to NTP adjustments.
> High-resolution per-process timer from the CPU.
> Thread-specific CPU-time clock.
> Er, so what exactly is the relationship between the CLOCK_REALTIME clock
> and the time(2) clock? Are they the same? If they're different, how
> are they different?
> It says the CLOCK_MONOTONIC clock isn't settable, but the CLOCK_MONOTONIC_RAW
> text implies that the former may get NTP adjustments. And it doesn.t specify
> whether the per-process timers are NTP-corrected...I'd guess not, but who's
> to know from the above.
> Can anyone point me to better documentation on these facilities?
>> 2) ReRun all tests under load (example: netperf -l 3600 -H the_router)
> I'll do this, for completeness, but I predict it's not going to make
> any measurable difference. The indications so far are that neither of
> the means of time delivery I have available to check are compute-bound
> or disk-I/O bound at any point in their delivery chains.
> So I think they're just going to shrug off any load short of
> machine-thrashing-its-guts-out. But part of the point of what I'm
> doing is that soon we'll have the test tools to know for *sure* that's
One thing that surprised me of late is http://www.bufferbloat.net/issues/271
while not related, surprises are the last thing we need as regards to time.
US Tel: 1-239-829-5608
More information about the Bloat-devel