Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[aesmith]

Hi,

I see a few discussions of so call Buffer Bloat as a defect in some typical end-user routers (Plusnet's 2704N was named as a culprit for example).  Would anyone like to come up with some examples of equipment which does suffer?   Or other example of ones to avoid as well.

As a separate question, how do separate router/modem combinations fare?  My thoughts are that unless PPPoE has some specific pacing mechanism then the bottleneck, and therefore any buffering issues will be at the modem.

Regarding poor performers I'm going to tentatively name the Linksys WAG320N as one, based on some tests last weekend.

Tony S

[richb-hanover]

I see a few discussions of so call Buffer Bloat as a defect in some typical end-user routers (Plusnet's 2704N was named as a culprit for example).  Would anyone like to come up with some examples of equipment which does suffer?   Or other example of ones to avoid as well.

Regrettably, most commercial today today are afflicted with Bufferbloat. The easiest test is DSLReports Speed Test at http://dslreports.com/speedtest It measure the latency/lag *during* transfers which is when bufferbloat kills you.

As a separate question, how do separate router/modem combinations fare?  My thoughts are that unless PPPoE has some specific pacing mechanism then the bottleneck, and therefore any buffering issues will be at the modem.

Yes, PPPoE affects bufferbloat. The fq_codel algorithm implemented in Linux and many third-party firmware packages (OpenWrt, DD-WRT) accounts for this. (It takes control of the bottleneck, so that it can minimize latency while keeping the link fast.) See What to do about Bufferbloat for more details.

Regarding poor performers I'm going to tentatively name the Linksys WAG320N as one, based on some tests last weekend.

Quite possibly. It would be good for you to post the results from DSLReports (www.dslreports.com/speedtest)

[aesmith]

Cheers,

That tester reports Bufferbloat of up to 1400ms in both download and upload directions.   I'm not sure how to read that regarding download.   Almost by definition the bloat occurs at the bottleneck, where a high speed connection transitions to a lower speed.  So where do they say this 1400ms lies during download?   Are they measuring TCP seq to ack latency at their server?   If so then a number of other factors apply, not least that many host show some internal latency in any case, and this doesn't hurt TCP throughput unless it's so extreme that the window empties.   In any case if I run a continuous ping I don't see any more than just over 60ms during the Download test.   

On the other hand during  Upload, that ping RTT does indeed go up to that sort of figure.   That doesn't necessarily point the finger at my router, but I should get hold of a Cisco in a few days so can make direct comparisons.

Tony S

[ejs]

The tests don't and can't really say where the buffering is occurring.

On Plusnet, their downstream traffic management does prioritise ping packets above normal traffic, that may explain the difference between the ping times and the test result.

Another test that measures the amount of buffering (amongst many other things) is ICSI Netalyzr. Java required, or there's an Android app.

[aesmith]

That's interesting re PN prioritising pings.   When I'm testing I'll try with other packet types.   Do you know if it's specifically ICMP replies they prioritise, or is it small packets in general?

[ejs]

Specifically ICMP replies, certain nothing to prioritise packets based on size. ICMP replies get the same higher prioritisation as whatever gets classed as VoIP and gaming.

[Oldjim]

not sure what this indicates Billion 8800NL on Plusnet

[aesmith]

Are you using that directly on VDSL, or with an external modem?   Assuming the upload latency is in your router then proportionally, that's similar to what I see on upload in terms of buffer size, but your 20x faster speed makes the absolute effect less.  Would be interesting to see how the same hardware behaves on a slower link.

[Oldjim]

directly on VDSL as I don't use the modem