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 71FF2201146 for ; Fri, 23 Sep 2011 02:38:03 -0700 (PDT) Received: by iagv1 with SMTP id v1so6734704iag.16 for ; Fri, 23 Sep 2011 02:38:02 -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=Rd8DBYdYmyhlHzb/Ursj61ciVVkKdeo1AXfU09TwInM=; b=OcMPNkI/4YDeDE+6zhNh7Qh0Ho+cS/dt7tDdOXqlh/L9F1qpJFwNR5+j55nc12aco8 ENuXWKyeduY9kvim1meO6Gw0AB9JWYVDvgxQ9ugTNPoxYUyRk+3u1y2t8WS+nAm6ZFhM LRoQ8U0nDOUFD8uQAMLCo1aA5uSYItbsHtZZA= MIME-Version: 1.0 Received: by 10.42.148.136 with SMTP id r8mr3957907icv.125.1316770682427; Fri, 23 Sep 2011 02:38:02 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Fri, 23 Sep 2011 02:38:02 -0700 (PDT) In-Reply-To: <4E7C4CDE.4060308@gmail.com> References: <20110921230205.2275820C2E5@snark.thyrsus.com> <20110922021137.GB21302@thyrsus.com> <4E7C4CDE.4060308@gmail.com> Date: Fri, 23 Sep 2011 02:38:02 -0700 Message-ID: Subject: Re: Preliminary results of using GPS to look for clock skew From: Dave Taht To: Jan Ceuleers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Eric S. 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: Fri, 23 Sep 2011 09:38:03 -0000 On Fri, Sep 23, 2011 at 2:09 AM, Jan Ceuleers wrot= e: > On 09/22/2011 04:24 AM, Jonathan Morton wrote: >> >> When the *network* is loaded, the latency to the NTP server changes. Tha= t >> is likely to confuse ntpd - it certainly did when I lived on an analogue >> modem. > > Look at the huff'n'puff filter for how ntpd addresses this concern. > > http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html In the case of the cosmic background bufferbloat detector idea, I'm interested in collecting the data that ntp is currently *filtering away* as a means to measure various delays across a wide base of machines, thus collecting rawstats on the client seems like the best approach. The point is not to derive accurate time from multiple, possibly badly varying, data sources, but to see how badly varying the data sources are! It would be best to be doing so passively, however, at the server, and I've been toying with the idea of creating a new ntp message type to do so. With clients often behind nat there is no good way to supply what a ntp host thinks is the current time to a data collecting server elsewhere. The huff n puff filter is a great idea, however I note it relies on ntp running for a long time, and many (most?) clients restart ntp on every interface change (example, a dhcp refresh, or wakeup from suspend) Secondly, adding the refclock with noselect keyword seems like a useful means of comparison. Thirdly - as much as I would like to get a PPS signal, that seems impossible with the hardware we are currently playing with. That said, delays/variations of 10ms are not a real problem as the bufferbloat signal can often be measured in close order of seconds. > > Jan > _______________________________________________ > Bloat-devel mailing list > Bloat-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat-devel > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com