Preliminary results of using GPS to look for clock skew

[Dave Taht]

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
>> correction.
>

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:
>
>       CLOCK_REALTIME
>              System-wide real-time clock.  Setting this clock requires appro‐
>              priate privileges.
>
>       CLOCK_MONOTONIC
>              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.
>
>       CLOCK_PROCESS_CPUTIME_ID
>              High-resolution per-process timer from the CPU.
>
>       CLOCK_THREAD_CPUTIME_ID
>              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
> true.

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.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com