From: "Bill Ver Steeg (versteb)" <versteb@cisco.com>
To: "Eggert, Lars" <lars@netapp.com>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>,
"Klatsky, Carl" <Carl_Klatsky@cable.comcast.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems
Date: Fri, 15 May 2015 13:09:58 +0000 [thread overview]
Message-ID: <AE7F97DB5FEE054088D82E836BD15BE9319E70EC@xmb-aln-x05.cisco.com> (raw)
In-Reply-To: <B8D6F7D2-5D63-4B9E-98FD-CB7F33C05811@netapp.com>
Lars-
You make some good points. It boils down to the fact that there are several things that you can measure, and they mean different things.
Bvs
-----Original Message-----
From: Eggert, Lars [mailto:lars@netapp.com]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Steeg (versteb)
Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbloat.net; bloat
Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems
Hi,
On 2015-5-15, at 13:27, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
> But the TCP timestamps are impacted by packet loss. You will sometimes get an accurate RTT reading, and you will sometimes get multiples of the RTT due to packet loss and retransmissions.
right. But those will be transient, and so you can identify them against the baseline.
> You really need to use a packet oriented protocol (ICMP/UDP) to get a true measure of RTT at the application layer.
I disagree. You can use them to establish a lower bound on the delay an application over TCP will see, but not get an accurate estimate of that (because socket buffers are not included in the measurement.) And you rely on the network to not prioritize ICMP/UDP but otherwise leave it in the same queues.
> If you can instrument TCP in the kernel to make instantaneous RTT available to the application, that might work. I am not sure how you would roll that out in a timely manner, though.
That's already part of the TCP info struct, I think. At least in Linux.
Lars
> I think I actually wrote some code to do this on BSD many years ago, and it gave pretty good results. I was building a terminal server (remember those?) and needed to have ~50ms +- 20ms echo times.
>
>
> Bvs
>
> From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Eggert, Lars
> Sent: Friday, May 15, 2015 4:18 AM
> To: Aaron Wood
> Cc: cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbloat.net; bloat
> Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems
>
> On 2015-5-15, at 06:44, Aaron Wood <woody77@gmail.com> wrote:
> ICMP prioritization over TCP?
>
> Probably.
>
> Ping in parallel to TCP is a hacky way to measure latencies; not only because of prioritization, but also because you don't measure TCP send/receive buffer latencies (and they can be large, auto-tuning is not so great.)
>
> You really need to embed timestamps in the TCP bytestream and echo them back. See the recent netperf patch I sent.
>
> Lars
next prev parent reply other threads:[~2015-05-15 13:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 19:13 [Cerowrt-devel] " Dave Taht
2015-05-15 2:48 ` Greg White
2015-05-15 4:44 ` Aaron Wood
2015-05-15 8:18 ` [Cerowrt-devel] [Bloat] " Eggert, Lars
2015-05-15 8:55 ` Sebastian Moeller
2015-05-15 11:10 ` [Cerowrt-devel] [Cake] " Alan Jenkins
2015-05-15 11:27 ` [Cerowrt-devel] " Bill Ver Steeg (versteb)
2015-05-15 12:19 ` Jonathan Morton
2015-05-15 12:44 ` Eggert, Lars
2015-05-15 13:09 ` Bill Ver Steeg (versteb) [this message]
2015-05-15 13:35 ` Jim Gettys
2015-05-15 14:36 ` Simon Barber
2015-05-18 3:30 ` dpreed
2015-05-18 5:06 ` Simon Barber
2015-05-18 9:06 ` Bill Ver Steeg (versteb)
2015-05-18 11:42 ` Eggert, Lars
2015-05-18 11:57 ` luca.muscariello
2015-05-18 12:30 ` Simon Barber
2015-05-18 15:03 ` Jonathan Morton
2015-05-18 15:09 ` dpreed
2015-05-18 15:32 ` Simon Barber
2015-05-18 17:21 ` [Cerowrt-devel] [Cake] " Dave Taht
2015-05-18 15:40 ` [Cerowrt-devel] " Jonathan Morton
2015-05-18 17:03 ` Sebastian Moeller
2015-05-18 17:17 ` Jonathan Morton
2015-05-18 18:14 ` Sebastian Moeller
2015-05-18 18:37 ` Dave Taht
2015-05-19 16:25 ` [Cerowrt-devel] [Cake] " Sebastian Moeller
2015-05-15 16:59 ` [Cerowrt-devel] " Dave Taht
2015-05-15 17:47 ` [Cerowrt-devel] " Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AE7F97DB5FEE054088D82E836BD15BE9319E70EC@xmb-aln-x05.cisco.com \
--to=versteb@cisco.com \
--cc=Carl_Klatsky@cable.comcast.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=lars@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox