From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay119.isp.belgacom.be (mailrelay119.isp.belgacom.be [195.238.20.146]) by huchra.bufferbloat.net (Postfix) with ESMTP id 84E9C21FDD4 for ; Thu, 9 Jul 2015 03:09:44 -0700 (PDT) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=wisUSL2q+2X910teRg2xg/30tBFW7lBMAi45pEFXNHU= c=1 sm=2 a=nQa5jYd3wheh35zNEUAA:9 a=QEXdDO2ut3YA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BeCgBpR55V/y4m9FFbgxKEVK0silqFE4JUAoFaOxIBAQEBAQEBgQqEJAEBBCMzBhwBEAsLDQICBRYLAgIJAwIBAgERFh4GDQEHAQGIFAEZAbdtgWuOGgoZgQuEfAEBAQEBBQEBAQEBARyBIYoqhDtLB4JogUMBBJQsjACIQZAkJoIMHIFVPIJ8AQEB Received: from 46.38-244-81.adsl-dyn.isp.belgacom.be (HELO zotac.xperim.be) ([81.244.38.46]) by relay.skynet.be with ESMTP; 09 Jul 2015 12:09:41 +0200 Received: from [192.168.1.172] (mordor.xperim.be [192.168.1.172]) by zotac.xperim.be (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t69A8vft019879; Thu, 9 Jul 2015 12:08:57 +0200 Message-ID: <559E4839.6060308@gmail.com> Date: Thu, 09 Jul 2015 12:08:57 +0200 From: Jan Ceuleers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Taht References: <20150708102317.A8994406057@ip-64-139-1-69.sjc.megapath.net> <559D4BCA.5040907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] Graph of bloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 10:10:14 -0000 On 08/07/15 18:32, Dave Taht wrote: > Judging from that graphic... I don't think huff and puff was designed > for the bufferbloated era! so the question remains, in hal's tests, > did ntp adjust the clock backwards? Dave, No, ntpd did not adjust the time backwards. What's going on in that graph is that it shows the different approach that Google has taken to leap second insertion relative to ntpd's implementation (which aligns with the standard). Ntpd inserts a leap second by having the last UTC minute of the last day of (in this case) June 30th last for 61 seconds rather than 60. The extra second is number 60, after seconds 0 through 59. This is plotted on the x axis. The time reported by the Google server is compared to this on the y axis. 10 hours prior to UTC midnight they slow down the clock by 1/72000, such that at the end of those 72000 seconds (20 hours) one more "real" second will have passed than is reflected in the time reported by the clock. So obviously this means that during the 10 hours prior to UTC midnight an offset is gradually built up between the Google servers and the rest of the world, reaching half a second just prior to midnight. After the leap second insertion on the standard server the sign of the offset is inverted and the offset between the two begins to decline. 10 hours after UTC midnight the Google servers return the rate of their clocks to the normal "1 second per second" rate. Anyway: Hal shared this because of the artifacts below the main graph and he posits (quite reasonably) that this was due to bufferbloat. Jan