From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 16B32200627 for ; Thu, 22 Sep 2011 02:08:59 -0700 (PDT) Received: by iagv1 with SMTP id v1so4713711iag.16 for ; Thu, 22 Sep 2011 02:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yuRBBREdcCYApFrWoLlWnlnveuRzIeHyHmEsZzHIspg=; b=a/hj4PYBVQgqwqLVPx11e6tHgDcU/pNURUccsJtBkZg/XkyFgjDSLE3RUvw+2OLlNr u/PZ3bFxrKaMFSVyMve5TGYDsmOsEQnvx9GjzhUJwOl9PfIUJ4z6NAcfc7h6CiQqHP+S 1oZUtAJKM/dXoUYfxgoJVlc/KJszxlK6jjXfc= MIME-Version: 1.0 Received: by 10.42.156.3 with SMTP id x3mr1746886icw.212.1316682538397; Thu, 22 Sep 2011 02:08:58 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Thu, 22 Sep 2011 02:08:58 -0700 (PDT) In-Reply-To: <20110922021137.GB21302@thyrsus.com> References: <20110921230205.2275820C2E5@snark.thyrsus.com> <20110922021137.GB21302@thyrsus.com> Date: Thu, 22 Sep 2011 02:08:58 -0700 Message-ID: Subject: Re: Preliminary results of using GPS to look for clock skew From: Dave Taht To: esr@thyrsus.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eric Raymond , bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 09:08:59 -0000 On Wed, Sep 21, 2011 at 7:11 PM, Eric Raymond wrote: > Dave Taht : >> 1) Run the router WITHOUT ntp enabled at all >> =C2=A0 =C2=A0(and/or testing against CLOCK_REALTIME) >> =C2=A0 =C2=A0It 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. =C2=A0It says: > > =C2=A0 =C2=A0 =C2=A0 CLOCK_REALTIME > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0System-wide real-time clo= ck. =C2=A0Setting this clock requires appro=E2=80=90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0priate privileges. > > =C2=A0 =C2=A0 =C2=A0 CLOCK_MONOTONIC > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Clock =C2=A0that =C2=A0ca= nnot =C2=A0be =C2=A0set and represents monotonic time since > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some unspecified starting= point. > > =C2=A0 =C2=A0 =C2=A0 CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-speci= fic) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Similar to CLOCK_MONOTONI= C, but provides access to a =C2=A0raw =C2=A0hard=E2=80=90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ware-based time that is n= ot subject to NTP adjustments. > > =C2=A0 =C2=A0 =C2=A0 CLOCK_PROCESS_CPUTIME_ID > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0High-resolution per-proce= ss timer from the CPU. > > =C2=A0 =C2=A0 =C2=A0 CLOCK_THREAD_CPUTIME_ID > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thread-specific CPU-time = clock. > > Er, so what exactly is the relationship between the CLOCK_REALTIME clock > and the time(2) clock? =C2=A0Are they the same? =C2=A0If they're differen= t, 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. =C2=A0And 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. =C2=A0The 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. =C2=A0But 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/27= 1 while not related, surprises are the last thing we need as regards to time. --=20 Dave T=C3=A4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com