From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CD7AA21FB14 for ; Wed, 8 Jul 2015 12:09:17 -0700 (PDT) Received: by wiwl6 with SMTP id l6so353856061wiw.0 for ; Wed, 08 Jul 2015 12:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=zz5+QWswnBXE5GPyDl21TdUnbTexI38nJc2UpQt9/dQ=; b=qS1Au7hWPYBU1XDbDim9rilqFR+X68MstLZgCwGnfnB/GplbONm0MLWPGtUY2wCx4a aQ4oGgOJNZMB663QVD0M2FH5X9HC5wdI/NSrvmGppKFN2l/GibEUlRZ1plzS3HbNZKZD m05fVNNp+5dfV6TEpRygRu48kGjmL52Oo2q8Qfp2QJhmDAnLeurR48xkoewvFkofps6D cKxu/or+yPI4bWj3dt5w1g4CMStXqqHXHgUA22+LMjdpEPHQ6jIHFp/+NSeGy/IiIo1r PTKAKRRHu9/EE5IjeQaXAJZn6ilBl0lhWZVFyy4LiHkP2XRDSN5Q159JF2/jU9M+3VHC 96Og== X-Received: by 10.194.48.8 with SMTP id h8mr17006589wjn.82.1436382555419; Wed, 08 Jul 2015 12:09:15 -0700 (PDT) Received: from volcano.localdomain (host-89-243-101-54.as13285.net. [89.243.101.54]) by smtp.googlemail.com with ESMTPSA id lq9sm4866720wjb.35.2015.07.08.12.09.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 12:09:14 -0700 (PDT) To: Jan Ceuleers , bloat@lists.bufferbloat.net References: <20150708102317.A8994406057@ip-64-139-1-69.sjc.megapath.net> <559D4BCA.5040907@gmail.com> <559D4FFC.9090207@gmail.com> From: Alan Jenkins Message-ID: <559D7559.80206@gmail.com> Date: Wed, 8 Jul 2015 20:09:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559D4FFC.9090207@gmail.com> Content-Type: multipart/alternative; boundary="------------000209090505040901090003" 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 19:09:46 -0000 This is a multi-part message in MIME format. --------------000209090505040901090003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 08/07/15 17:29, Jan Ceuleers wrote: > 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. . Ouch, I see Dave's point, I had hoped it was unfounded. You don't mean -g, that applies to startup (the "panic threshold" offset of 1000 seconds). Note startup also waits 900 seconds before allowing a step, explicitly in case of transient bufferbloat. You mean "ntpd is given permission to step the time, by *not* passing -x". Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. (ow ow ow) [The -x] option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete. I also looked at phk's blog for the ntimed project again. Apparently everyone filters ntp samples, which suggests massive delays would need to affect more than one sample/poll interval. But I don't know how many more than one, or what patterns it would filter in general. (Would it miss bufferbloat less than some X but greater than the 128ms threshold?). Apparently the filters are the hard part - makes sense but sounds like hard work to analyze. http://phk.freebsd.dk/time/20141024.html > 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. I see that's a tinker option which is not enabled by default, requires manual tuning, is documented as experimental and being designed for dialup :-P. IOW in a way it's less about bloat awareness and more the general problem with NTP (like other projects) being under-resourced global infrastructure... PHK's post definitely suggests he's aware of asymmetry in delay events and exploiting it in the Ntimed filters. OTOH the graphs there don't seem to represent much bufferbloat. Maybe he could benefit from seeing Hal's awesome graph (and for context, the equally awesome graphs at http://www.dslreports.com/speedtest/results/bufferbloat). Alan --------------000209090505040901090003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 08/07/15 17:29, Jan Ceuleers wrote:
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.

<googles>.  Ouch, I see Dave's point, I had hoped it was unfounded.

You don't mean -g, that applies to startup (the "panic threshold" offset of 1000 seconds).  Note startup also waits 900 seconds before allowing a step, explicitly in case of transient bufferbloat.

You mean "ntpd is given permission to step the time, by *not* passing -x".
Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold.
(ow ow ow)
[The -x] option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.


I also looked at phk's blog for the ntimed project again.  Apparently everyone filters ntp samples, which suggests massive delays would need to affect more than one sample/poll interval.  But I don't know how many more than one, or what patterns it would filter in general.  (Would it miss bufferbloat less than some X but greater than the 128ms threshold?).  Apparently the filters are the hard part - makes sense but sounds like hard work to analyze.

http://phk.freebsd.dk/time/20141024.html

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.

I see that's a tinker option which is not enabled by default, requires manual tuning, is documented as experimental and being designed for dialup :-P.  IOW in a way it's less about bloat awareness and more the general problem with NTP (like other projects) being under-resourced global infrastructure...

PHK's post definitely suggests he's aware of asymmetry in delay events and exploiting it in the Ntimed filters.  OTOH the graphs there don't seem to represent much bufferbloat.  Maybe he could benefit from seeing Hal's awesome graph (and for context, the equally awesome graphs at http://www.dslreports.com/speedtest/results/bufferbloat).

Alan
--------------000209090505040901090003--