From: Michael Richardson <mcr@sandelman.ca>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Wes Felter <wmf@felter.org>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration.
Date: Fri, 01 Aug 2014 00:40:18 -0400 [thread overview]
Message-ID: <12287.1406868018@sandelman.ca> (raw)
In-Reply-To: <E6FC5EA7-132E-44B0-9889-A836FCDD8848@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
Sebastian Moeller <moeller0@gmx.de> wrote:
>> The trouble is that to measure bandwidth, you have to be able to send
>> and receive a lot of traffic.
> Well that is what you typically do, but you can get away with less
> measurement traffic: in an ideal quiescent network sending two packets
> back to back should give you the bandwidth (packet size / incoming time
> difference of both packets), or send two packets of different size
> (needs synchronized clocks, then difference of packet sizes /
> difference of transfer times).
Apparently common 802.1ah libraries in most routers can do speed tests at
layer-2 for ethernet doing exactly this. (Apparently, one vendor's code is
in 90% of equipment out there, cause some of this stuff invoves intimate
knowledge of PHYs and MII buses, and it's not worth anyone's time to write
the code over again vs licensing it...)
> But this still requires some service on the other side. You could try
> to use ICMP packets, but these will only allow to measure RTT not
> one-way delays (if you do this on ADSL you will find the RTT dominated
> by the typically much slower uplink path). If network equipment would
And correct me if I'm wrong, if you naively divide by two, you wind up
overestimating the uplink speed.
>> you can't just test that link, you have to connect to something beyond
>> that.
> So it would be sweet if we could use services that are running on the
> machines anyway, like ping. That way the “load” of all the leaf nodes
> of the internet continuously measuring their bandwidth could be handled
> in a distributed fashion avoiding melt-downs by synchronized
> measurement streams…
sadly, ICMP responses are rate limited, even when they are implemented in the
fast path. PPP's LCP is not, AFAIK.
--
Michael Richardson
-on the road-
[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]
next prev parent reply other threads:[~2014-08-01 13:20 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 14:03 R.
2014-07-25 18:37 ` Valdis.Kletnieks
2014-07-25 21:03 ` David Lang
2014-07-26 11:30 ` Sebastian Moeller
2014-07-26 20:39 ` David Lang
2014-07-26 21:25 ` Sebastian Moeller
2014-07-26 21:45 ` David Lang
2014-07-26 22:24 ` David Lang
2014-07-27 9:50 ` Sebastian Moeller
2014-07-26 22:39 ` Sebastian Moeller
2014-07-26 22:53 ` David Lang
2014-07-26 23:39 ` Sebastian Moeller
2014-07-27 0:49 ` David Lang
2014-07-27 11:17 ` Sebastian Moeller
2014-08-01 4:21 ` Michael Richardson
2014-08-01 18:28 ` Sebastian Moeller
2014-07-25 20:48 ` Wes Felter
2014-07-25 20:57 ` David Lang
2014-07-26 11:18 ` Sebastian Moeller
2014-07-26 20:21 ` David Lang
2014-07-26 20:54 ` Sebastian Moeller
2014-07-26 21:14 ` David Lang
2014-07-26 21:48 ` Sebastian Moeller
2014-07-26 22:23 ` David Lang
2014-07-26 23:08 ` Sebastian Moeller
2014-07-27 1:04 ` David Lang
2014-07-27 11:38 ` Sebastian Moeller
2014-08-01 4:51 ` Michael Richardson
2014-08-01 18:04 ` Sebastian Moeller
2014-08-02 20:17 ` Michael Richardson
2014-08-01 4:40 ` Michael Richardson [this message]
2014-07-26 11:01 ` Sebastian Moeller
-- strict thread matches above, loose matches on Subject: below --
2014-05-24 14:12 R.
2014-05-24 17:31 ` Sebastian Moeller
2014-05-24 19:05 ` David P. Reed
2014-05-20 22:11 Frits Riep
2014-05-20 23:14 ` Dave Taht
2014-05-21 11:42 ` Frits Riep
2014-05-21 14:51 ` dpreed
2014-05-21 15:19 ` Dave Taht
2014-05-21 16:03 ` dpreed
2014-05-21 16:30 ` Dave Taht
2014-05-21 17:55 ` dpreed
2014-05-21 17:47 ` Jim Gettys
2014-05-21 17:53 ` Dave Taht
2014-05-21 17:56 ` dpreed
2014-05-21 17:57 ` Jim Gettys
2014-05-21 18:31 ` Dave Taht
2014-05-21 15:07 ` Dave Taht
2014-05-21 16:50 ` Michael Richardson
2014-05-21 17:58 ` David Lang
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=12287.1406868018@sandelman.ca \
--to=mcr@sandelman.ca \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
--cc=wmf@felter.org \
/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