From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (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 EA0C3200614 for ; Sun, 17 Jul 2011 08:12:13 -0700 (PDT) Received: by wwf27 with SMTP id 27so2304303wwf.28 for ; Sun, 17 Jul 2011 08:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=LNfZF6IMWWfDGzMOGEYRuLMk3k2veZG4bScKpHB03lo=; b=VVxhyhFPIU/JYM7dyThS+BBDKbflQJ7m0/7TY6muu1+9cWjSfRQ4CrqgGsmDJu5Qlt LStq8tCuUmnwFZJ9up7CyGN/cgiuu1lw1mP9xEaeAAkumPJOqwKTt0zQi0k9CU4KrndJ VSRVLqjrhIgmFpH8OXS9Ez/ufyFoURWLDFeYs= Received: by 10.227.12.20 with SMTP id v20mr4871975wbv.42.1310917863055; Sun, 17 Jul 2011 08:51:03 -0700 (PDT) MIME-Version: 1.0 Sender: davehart@gmail.com Received: by 10.227.41.200 with HTTP; Sun, 17 Jul 2011 08:50:43 -0700 (PDT) In-Reply-To: References: <4E2226B3.3070907@hp.com> From: Dave Hart Date: Sun, 17 Jul 2011 15:50:43 +0000 X-Google-Sender-Auth: pWKq0QPnKsSrU06E_y1EYdDzzA4 Message-ID: Subject: Fwd: smoketest #6 of cerowrt is go for testing To: Dave Taht Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bismark-bootcamp@projectbismark.net, bloat-devel , Evan Hunt , bismark-devel@projectbismark.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: Sun, 17 Jul 2011 15:12:14 -0000 On Sun, Jul 17, 2011 at 12:34 UTC, Dave Taht wrote: > On Sat, Jul 16, 2011 at 10:35 PM, Dave Hart > wrote: >> >> On Sun, Jul 17, 2011 at 00:02 UTC, Rick Jones wrote= : >> > If you configure ntpd with bare IP addresses rather than names, will t= he >> > getaddrinfo() return without attempting any DNS in the first place? >> >> Yes, basically. =C2=A0ntpd might not even call getaddrinfo() in that cas= e >> (it may use inet_pton() or similar to convert the IP address to binary >> representation). =C2=A0At any rate, using only numeric IPv4 or IPv6 >> addresses will avoid any DNS lookups. > > While there is one group that is finally providing ntp time via anycast - > which is a good solution to a large extent! - there is only the one (smal= l) > group doing so, rather than the needed '3'. > > http://news.ntppool.org/2011/03/expanding-the-anycast-dns-serv.html You misread the announcement: What is anycast is the DNS service for pool.ntp.org provided by (among others) a.ntpns.org, which is the anycast IP now served from 3 sites. Anycast is being used to spread the load of the custom DNS server software used for *.pool.ntp.org. NTP time service is not being anycast by the pool operators. I do know of one operator who provides NTP time service over anycasted IP addresses, but it is not a good solution in general. For simple clients it makes no difference, but for full NTP, a single IP address is assumed to represent a single oscillator reached via a single network path. ntpd keeps an eight-deep history for each configured server of the delay, root dispersion, and apparent offset. NTP's clock filter algorithm chooses the lowest-delay sample from this history, which helps remove the majority of error caused by network delay variation -- the lowest delay sample represents the best guess at the actual path round-trip time. Using an anycast IP address as a ntpd time source violates the assumption and results in samples from more than one oscillator reached via more than one path being compared as if they represented a single clock and path. > And I'm reluctant, given the sordid history of hard coding ntp IP address= es, > > http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse > > to hard code *any* until far more anycast servers are online. If you are using well-behaved NTP clients and reasonable configurations, each server can handle many thousands of clients, each of which is polling every 1024 seconds once settled in. For bootstrapping, where you need to set the time in order to enable DNSSEC in order to enable normal operation using pool.ntp.org, you can reasonably get by with a handful of hardcoded NTP server IPs, assuming you are doing a one-shot NTP query during startup then switching to DNS and pool.ntp.org for ongoing clock sync. > To take a step backwards on this, there are extensive notes on the circul= ar > dependencies between time and dnssec logged here. > > http://www.bufferbloat.net/issues/205 > > I'd implemented a hack to try to address these circular depenencies last > week in the named-latest package repo, while also coping with > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2011-2464 > > I think I addressed the latter issue, but *good*. :) The 'fix' for the > ntp/dnssec/bind/network dependencies seems to have some problems, however= , > notably really slow startup in general. > > > To step further back on this: > > I had implemented ntp (with 7 contacted servers in the conf file!) in the IMO 7 is not an extreme number of NTP servers to associate with. I help operate a pool NTP server which has 15 associations configured using maxpoll 8 (256s). A handful of those are for monitoring purposes, but the majority are there to provide a wide variety of stable oscillators, in hopes of keeping better time by giving NTP the information it needs to ignore transient outliers. That still amounts to an average of about 4 queries to lower-stratum "upstream" sources per minute, which is trivial compared to the 20,000 client NTP queries it serves each minute (currently averaging 363 pkts/sec). > first place due to the "cosmic background bufferbloat detector" idea > extensively discussed on the comp.protocols.ntp newsgroup, and because I > wanted to be able to compare large sample data sets against known-to-be > accurate time, with a large deployment of client routers that had a > configuration I could trust to be accurate, talking to a yet-to-be-deploy= ed > string of ntp servers (via hopefully a helpful operator) that could work = on > this with us. Even better would be comparing against a local NTP server set up with a GPS + PPS (pulse-per-second). Using off-the-shelf components, the hardware cost in the US is between $30 and $100. $30 gets you a Sure GPS that has PPS but requires good eyes and a steady soldering hand to bring it from the PCB to the RS-232 connection. For less than $70 you can get a Garmin GPS 18x LVC, which requires less accurate soldering to provide 5VDC power (often via USB) and a DB-9 connector for its bare-lead 232 connection. For $100 you can get a ready-to-use 18x LVC with DB-9 serial and USB power cables provided by a third party. Cheers, Dave Hart