From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay108.isp.belgacom.be (mailrelay108.isp.belgacom.be [195.238.20.135]) by huchra.bufferbloat.net (Postfix) with ESMTP id 73B5D21F51C for ; Wed, 8 Jul 2015 09:34:47 -0700 (PDT) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=E12Nk8Bf0hMlwhhcPGlCWJx/tbvGdtmOO6CYG/XBrkw= c=1 sm=2 a=eJI8hMdOFTEbEUTmYdEA:9 a=pILNOxqGKmIA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/BADMUJ1V/y4m9FFcgxK0NopNCYUSglQCgVk5FAEBAQEBAQGBCoQkAQEEVgYcEQsLDQkWDwkDAgECAREWHhMIAQGIFAEZAbkxjikKGYELhHoBAQgCIItLhQ0WhBUBBJQji36IQJAiJoN9PIJ8AQEB 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; 08 Jul 2015 18:34:37 +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 t68GTm3G029534 for ; Wed, 8 Jul 2015 18:29:48 +0200 Message-ID: <559D4FFC.9090207@gmail.com> Date: Wed, 08 Jul 2015 18:29:48 +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: bloat@lists.bufferbloat.net References: <20150708102317.A8994406057@ip-64-139-1-69.sjc.megapath.net> <559D4BCA.5040907@gmail.com> In-Reply-To: <559D4BCA.5040907@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Wed, 08 Jul 2015 16:35:17 -0000 On 08/07/15 18:11, Jan Ceuleers wrote: > On 08/07/15 17:55, Dave Taht wrote: >> That is a very interesting graph! Does ntp adjust system time backward >> based on getting nearly all it's samples with well over a 1/2 second >> of induced delay? > > If there is a consistent asymmetrical delay then yes. Let me qualify that "yes". Normally ntpd will ensure that the system time as observed by the kernel and applications always increases monotonically. The exception is where the system time differs too much from what ntpd considers to be the correct time and where ntpd is given permission to step the time (e.g. using the -g command-line switch). In this case ntpd can step backwards. What I meant in my previous message is that ntpd's idea of true time is arrived at based on the assumption that the network delay is the same in both directions to its servers. So if there is a systematically different delay in one direction relative to the other then this assumption falls down and ntpd's assessment of true time will be skewed. The huff-n-puff filter helps in cases where the asymmetry in the delay is not systematic, e.g. where the upstream channel does not suffer from bufferbloat. Jan