Superhub Bufferbloat - is it bad? - Page 3

Ignitionnet · 25-01-2016, 21:03

Quote:

Originally Posted by Eeeps

How would these result be impacted by Weighted Fair Queuing though?

As far as I know they wouldn't. The queueing is simple FIFO on the CMTS cards.

richbhanover · 26-01-2016, 00:59

Quote:

Originally Posted by SnoopZ

[this is the original posting in this thread]
However after running the DSLreports speedtest i have been getting readings of C,D and F for bufferbloat, is this bad as based on my other graphs below everything appears to be fine apart from the TBB graph, although this is only like that as i am running on 16 downstream channels on my Hub3 since moving to an Arris CMTS and everyone experiences the same result, and i am not sure if it is really causing a problem, unless it is causing the bufferbloat?

Both the DSLReports and TBB graphs agree. You're seeing big lag/latency from time to time. This is Bufferbloat - the undesirable latency that comes from a router or other network equipment buffering too much data.

Bufferbloat makes VoIP calls get bad, gaming gets laggy, and general web browsing gets sticky. You'll see it whenever there's traffic competing to be sent on the link. If your home router is buffering too much data, you'll see upload bloat, and if your ISP's headend/equipment is buffering too much data you'll see it on the download.

Most people think, "Oh yes, someone else is using the internet now, so things will be slow."

But it doesn't have to be - this is a solved problem. The fq_codel algorithm in OpenWrt, Linux kernels, and many commercial routers means that you can upload and download files while gaming and doing VoIP without any bad effect. (DOCSIS 3.1 cable modems also offer an effective anti-bloat system.)

As for measuring Bufferbloat, the DSLReports system uses websocket request/responses to measure the latency *during* the transfers to see how much lag is induced when transferring files. If DSLReports says there's latency, it's there.

The Bufferbloat team has a short article, "What to do about Bufferbloat?" at http://www.bufferbloat.net/projects/...ut_Bufferbloat

MUD_Wizard · 28-01-2016, 18:26

Quote:

Originally Posted by SnoopZ

Are we saying the DSLreorts are miss reporting my connection bloat? Are there any alternatives to a bloat test i can do?

Run a comparison between the single-threaded and multi-threaded TBB tests over ethernet.

Single threaded: http://labs.thinkbroadband.com/speed...gaUEKWiwklw392

Multi-threaded: http://labs.thinkbroadband.com/speedtest/

My bufferbloat results below for the Hub 3.0.

Single-threaded:

Multi-threaded:

As you can see, a big difference in downstream bufferbloat depending on number of threads/connections utilised, as expected.

You may want/need to run the tests several times, as these flash tests can suffer from spikes in data coming from the network card.

SnoopZ · 28-01-2016, 19:00

These results are with HUB3 and 16 downstreams, what do you make of it and do you think my upstream looks strange, maybe it is the wrong time of the day to do it? I did speedtest.net too and it gave a far smoother download.

Single threaded.

Multi threaded.

Sephiroth · 28-01-2016, 19:40

I don't see anything strange in the upload.

What you're seeing in the upload is the buffering in your router. On my speed test, it peaks/bursts at 14.4 meg - so that has to be into a buffer en route to TBB.

Kushan · 28-01-2016, 20:53

I just want to leave this here. My "200mbit" connection:

richbhanover · 29-01-2016, 01:01

Quote:

Originally Posted by SnoopZ

Are we saying the DSLreorts are miss reporting my connection bloat? Are there any alternatives to a bloat test i can do?

Yes, there are a few other tests.

MUD_Wizard suggests trying single or multiple streams.
You could post the link to your DSLReports tests - there's a lot of info there...
For a "down in the details" test, you could run a ping test while using any of the other speed tests. Just start a ping to a well-connected host (say, google.com), then start the speed test.

MUD_Wizard · 29-01-2016, 03:01

Quote:

Originally Posted by SnoopZ

These results are with HUB3 and 16 downstreams, what do you make of it and do you think my upstream looks strange, maybe it is the wrong time of the day to do it? I did speedtest.net too and it gave a far smoother download.

Looks normal for that flash test.

Like I said, bear in mind that the network card is receiving spikes of data from the hub. i.e. It arrives in clumps and surges. With multiple threads you get more spikes but they're closer together and can flatten out the graph a bit.

Some tests also flatten out that effect, but the effect is still there somewhere in any test.

richbhanover · 29-01-2016, 05:05

Quote:

Originally Posted by MUD_Wizard

Looks normal for that flash test.

Like I said, bear in mind that the network card is receiving spikes of data from the hub. i.e. It arrives in clumps and surges. With multiple threads you get more spikes but they're closer together and can flatten out the graph a bit.

Some tests also flatten out that effect, but the effect is still there somewhere in any test.

I agree. These tests don't really mean anything except maybe for braggin' rights. The primary question is whether your network performance is good enough.

Do you get the speed you're paying for? Does it let you do anything you want, anytime you want? Does gaming work great (no lag) and do your voice calls sound OK? Is that true even when someone else is up/downloading files? If so, then you're golden. Your network is doing fine.

But... If high traffic (streaming/torrenting) screws up your connection - you get lagged out, browsing feels sticky, voip is terrible - then you need to find out why.

Most speed tests only tell about... speed. They give a quick ping time measurement, but only when the line's idle. They don't measure latency *during* the download and upload. That's why the Bufferbloat test at www.dslreports.com/speedtest is so cool. It can put numbers to the lag: if it's OK, then you can look elsewhere.

I know how to fix it - my net at home works great. It's simple, but needs a little attention.

Ignitionnet · 29-01-2016, 08:12

Quote:

Originally Posted by MUD_Wizard

[COLOR="Blue"]Looks normal for that flash test.

Like I said, bear in mind that the network card is receiving spikes of data from the hub. i.e. It arrives in clumps and surges. With multiple threads you get more spikes but they're closer together and can flatten out the graph a bit.

Shouldn't be. Absolutely no reason for the Hub to hold onto anything downstream, it should be getting shot of packets as soon as processing is done. Exception to that being where wireless connection is slower than broadband connection.

If the Hub is holding onto TCP traffic for excessive periods WoW and Starcraft 2 players are going to be very upset by it. If it's trying to be too clever with TCP likewise they aren't going to be happy.