From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by huchra.bufferbloat.net (Postfix) with ESMTP id 06E3120069D for ; Wed, 28 Sep 2011 14:17:01 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 23) id 135E920C30D; Wed, 28 Sep 2011 17:17:00 -0400 (EDT) From: Eric Raymond To: bloat-devel@lists.bufferbloat.net Subject: Design plan for clockwatcher Message-Id: <20110928211700.135E920C30D@snark.thyrsus.com> Date: Wed, 28 Sep 2011 17:17:00 -0400 (EDT) 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: Wed, 28 Sep 2011 21:17:01 -0000 Listmembers will probably be aware that I, wearing my hat as the lead of the GPSD project, took on the job of providing local time service for the bufferbloat project's network-latency profiling tools. That project is now pretty well wrapped up by a successful cross-development port of GPSD to CeroWRT. Live-testing on a WNDR3700 proves that we can have high-quality time with a $40 GPS mouse plugged into the box's USB port. I confidently expect future cross-dev builds on other routers to pose no difficulties. I am therefore moving on to the next challenge. I present a design sketch for a specialized GPSD client called "clockwatcher". It will be a daemon indended to run in tandem with gpsd, gathering data on time drift at the host and shipping them to a collection server. In effect, it will be the distributed component of Dave Taht's Cosmic Background Bufferbloat Detector. The data reduction at the collection server can be somebody else's problem. One job of clockwatcher will be to watch for events that change the deltas between three time sources: (1) GPS time, (2) NTP-corrected system time, and (3) uncorrected monotonic time from the host's crystal oscillator. Every change in deltas between these is a potentially interesting event. Some such events should be filtered because they're below noise level, in particular because (a) NTP time is expected to drift by +-10ms, and (b) the latency in GPS time delivery jitters by about the same amount. Another job of clockwatcher will be to watch NTP rawstats arriving at the host and forward them to the collection server along with time drift notifications. Reporting will be only slightly complicated by the fact that GPS time is not always available. My intention is to also log "GPS up" and "GPS down" events. Finally, it should also log NTP up and down status. That's the high-level view. Now for some details: Each event will be shipped as a self-describing JSON object with a type tag and a host source address. The daemon will have a config file that can set the collection server address and the minimum deltas that will trigger shipping a notification. On each startup, clockwatcher will ship a notification of its minimum deltas. Best guess is this will be about a 1.5KLOC project. Thoughts? Comments? Critiques? -- Eric S. Raymond The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, "A Treatise Concerning Civil Government"