[Bloat] I am unable to pinpoint the source of bufferbloat

[Forums1000 <forums1000@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4282 bytes --]

The newer modem supports the bonding of more download channels (8 vs. 4 for
the 6120) and is also used in conjunction with telephony (whereas I have a
pure Internet subscription without telephony). Anyway, all of that should
not matter as you also indicate: both can handle the respective up- and
download speeds with ease.

Yes, both she and I have the same subscription (minus the telephony): 60 Mb
down and 4 Mb up. We also only live 25 kilometres apart (small country:-))
The uplink speed is mostly consistent around 3.76 megabit. I've never
caught our cable company going lower than 3.50 megabit in the upload
direction and I've done a lot of speedtests. The only limit I have been
able to observe is in the download direction when their network is really
busy.

I guess I will have to venture into traffic shaping. (I'll probably loose a
lot of sleep setting this up lol). Is there any way to determine the buffer
size reliably?

On Sat, Feb 9, 2013 at 7:15 PM, Jonathan Morton <chromatix99@gmail.com>wrote:

> Latency caused by bufferbloat always appears at the bottleneck device.
> Usually that is the modem, and you've given no alternative that it could
> plausibly be. The modems you mention are slightly different model numbers,
> but that can hide substantial differences in internal configuration.
>
> For a typical drop-tail queue, the induced latency under load is the size
> of the buffer divided by the speed of the link draining it. Assuming both
> modems have a 4Mbit uplink, 550ms is consistent with a 256KB buffer, and
> 220ms is consistent with a 48KB buffer - neither of which would seem
> excessively large to a modem builder who hasn't heard of bufferbloat.
> However with a shared cable infrastructure, it is possible that the uplink
> is constrained by other users on the same segment, which will skew this
> calculation.
>
> To cure it without modifying the modem, you need to move the bottleneck to
> a point where you can control the buffer. You do this by introducing
> traffic shaping at slightly below the advertised modem uplink speed on one
> of your own machines and directing all upstream traffic through it.
>
> - Jonathan Morton
>  On Feb 9, 2013 7:27 PM, "Forums1000" <forums1000@gmail.com> wrote:
>
>> Hi Jonathan and Dave
>>
>> My entire LAN-network is gigabit. My cable subscription is 60 megabit
>> down and 4 megabit up.
>> Now, both my routers' WAN-port and the cable modems' LAN port are also
>> gigabit. The router can route LAN to WAN and the other way around (with NAT
>> and connection tracking enabled) in excess of 100 megabit.
>>
>> Now my cable modem is a Motorola Surfboard SV6120E and hers is a Motorola
>> Surfboard CV6181E. My upload lag is 550ms and hers is only 220ms. Moreover,
>> at her place there are Powerplugs in the path limiting her download to 30
>> megabit instead of 60 megabit. Yet, the upload lag is much lower than mine.
>> There, it also did not matter where I ran Natalyzr, the result was always
>> 220ms of bufferbload.
>>
>> Could this still be only the modem?
>>
>>
>> On Sat, Feb 9, 2013 at 10:52 AM, Forums1000 <forums1000@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> Can anyone give some tips on how to diagnose the sources of bufferbloat?
>>> According to the Netalyzr test at http://netalyzr.icsi.berkeley.edu/, I
>>> have 550ms of upload bufferbloat. I tried all kinds of stuff on my Windows
>>> 7 laptop:
>>>
>>> - For the Intel(R) 82567LF Gigabit Network Connection, I put receive and
>>> transmit buffers to the lowest value of 80 (80 bytes? 80 packets? I don't
>>> know). I also disabled interrupt moderation.
>>> Result? Still 550ms.
>>> - Then I connected my laptop directly to my cable modem, bypassing my
>>> Mikrotik 450G router. Result? Still 550ms of bufferbloat.
>>> - Then I put a 100 megabit switch between the cable modem an the laptop
>>> (as both cable modem and Intel NIC are gigabit). Result? Still 550ms of
>>> upload bufferbloat.
>>>
>>> I'm out of ideas now. It seems I can't do anything at all to lower
>>> bufferbloat. Or the Netalyzr test is broken?:-)
>>>
>>> many thanks for your advice,
>>> Jeroen
>>>
>>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>

[-- Attachment #2: Type: text/html, Size: 5461 bytes --]