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 63E98201146 for ; Fri, 23 Sep 2011 03:10:31 -0700 (PDT) Received: by iagv1 with SMTP id v1so6776542iag.16 for ; Fri, 23 Sep 2011 03:10:30 -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=zq9Rbg7D6HJz9w8XomLO4uk/goDqM+LSXTZ3nQtZba4=; b=dY45hJ98vOwn/bQ/18vpBEUh6gg0mL4a9FZ/QKiLwICpMySUlFm3C7qr2APapycvov MedpAFe7CTnyQgI1olx2lKs7VjreCnZEWjivwnmv0EK6jYjj19Tmohfzn0imBORNOuTI 8oO+mgDN+PszvFoUbu5NaACHuIKbtl8lXwmrQ= MIME-Version: 1.0 Received: by 10.42.144.198 with SMTP id c6mr3994178icv.38.1316772630693; Fri, 23 Sep 2011 03:10:30 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Fri, 23 Sep 2011 03:10:30 -0700 (PDT) In-Reply-To: <20110922021137.GB21302@thyrsus.com> References: <20110921230205.2275820C2E5@snark.thyrsus.com> <20110922021137.GB21302@thyrsus.com> Date: Fri, 23 Sep 2011 03:10:30 -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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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 10:10:31 -0000 On Wed, Sep 21, 2011 at 7:11 PM, Eric Raymond wrote: > If we need rawstats in a form for real-time monitoring, why not modify > NTP to optionally multicast them and avoid all this going to disk? I have been collecting rawstats statistics for some time now on ntp server currently dedicated to prototyping this stuff. 5 ntp servers comes to about 45K/day - and /tmp is a ramdisk on the router, which has about 32MB to spare most of the time. So a plan - not the best one - was to upload the latest rawstats file every day and delete 2 day old entries in cron. > I > have good relations with the NTP guys, and they wouldn't be likely to > resist a feature request with a network-health-monitoring use case > even if we didn't. Let's *use* that zorch for something, rather than > fielding a fragile pile of hacks. I would like very much like to not field a fragile pile of hacks but the ntp people I've talked to reflexively (and rightly) seem focused on means to get good time, come hell or high water, rather than collecting and analyzing the outlier data as to why bad data is arriving. That said, adding a data message of some sort to propagate rawstats-like data to a given server configured to receive it would be nice. 2) Also on my list is to get ntp doing the right thing in the case of dnssec enabled startup without valid time. There is a Multiple means to do this have been described here: http://www.bufferbloat.net/issues/113 http://www.bufferbloat.net/issues/205 I guess this somewhat separate convo should move to the ntp list. I'd taken a look at the ntp codebase and it was convoluted enough to make me wish someone familiar with the ntp codebase would tackle the dnssec problem - when ntp is started with -g, to get the initial time with dnssec validation disabled, then revalidate the dns entries after the clock is slewed. Regrettably I think the best long term solution to the dnssec problem that there should be a flag to getaddrinfo in the libc as described here: http://www.bufferbloat.net/issues/224 in use to tell it not to validate dns, as it's only a single bit, darn it!!, but that implies a whole standardization process, and hacking the libcs etc, etc.... It just seems too heavyweight to add a dependency on libval for ntp for a single bit... to bring this back to getting time via gps somewhat, it takes a long time to get a lock from a gps signal to set the clock, too... I've had chicago's "does anybody really know what time it is" stuck in my head for weeks now. > > > -- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eric= S. Raymond > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com