Print

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

[GigabitEthernet]

But does it combat Bufferbloat, that is the question.



--------------------------
Admin note: Split off from this thread
--------------------------

[Weaver]

Could you explain AlecR, expand on that ? - as I'm being a bit dim this morning.

[GigabitEthernet]

When the router is under heavy load (i.e. when all bandwidth is being used), if the ping suddenly shoots up to a huge number (more than 100ms) then you have what is referred to as Bufferbloat.

It occurs because your modem is having to hold back packets because its buffer has filled up. This causes an increase in latency and as a result, the connection feels sluggish.

Very few modems have implemented a fix for the problem but many routers have (e.g. those running OpenWRT).

It would he interesting to see, if a router as good as the Firebrick has implemented the fix also.

[kitz]

Bufferbloat seems to be the new 'in thing' to measure line performance.   With you being on a 20CN line your speeds arent perhaps high enough to notice any lag caused specifically by hardware buffering rather than the lack of speed type buffering.  AIUI someone who is only able to receive data at 2Mbps is hardly likely to see modem based buffer bloat compared to one that has data coming down at 80Mbps.  (Less chance of the buffer filling up)   

I think there's a general debate out whether the likes of dsl reports should be using buffer-bloat as a performance for ISPs because there's various places where buffer-bloat can occur.. ie ISP network, BTw network, transit links and of course how the customers own router handles it.   Should an ISP be marked as say 'F' because the EU may have put on a router which is causing buffer bloat.  Unfortunately there isn't any way from these tests to identify where the bufferbloat is occurring, just that its there somewhere.

TBH buffer-bloat isnt an area that Ive investigated in depth, but I think Alec is on a mission to get all router manufacturers to implement proper handling against bufferbloat in order to be able to maximise bandwidth

[ejs]

I thought "bufferbloat" was more the reason why you end up with high latency while fully utilising your upload bandwidth. That's because when you do that, a large queue tends to build up in your router, so trying to do something else results in packets joining the end of the queue, without some kind of queue management.

With downstream traffic, there shouldn't be much buffering in the router because the LAN tends to have more bandwidth than the WAN connection.

[kitz]

Youre probably correct ejs .. as mentioned its not something Ive ever investigated in depth other than note what others have said elsewhere.

>> With downstream traffic, there shouldn't be much buffering in the router because the LAN tends to have more bandwidth than the WAN connection.

So basically the fact that I get A for upstream and B for downstream is that indicating that my router is ok taking traffic out onto the WAN...  yet there's an issue that something is slightly suffering outside my network?

[GigabitEthernet]

I thought "bufferbloat" was more the reason why you end up with high latency while fully utilising your upload bandwidth. That's because when you do that, a large queue tends to build up in your router, so trying to do something else results in packets joining the end of the queue, without some kind of queue management.

With downstream traffic, there shouldn't be much buffering in the router because the LAN tends to have more bandwidth than the WAN connection.

It affects the downstream and upstream as the modem sends data too fast so its buffer fills up quickly.

I suspect it affects the upstream more because upstream bandwidth is generally lower than downstream bandwidth and so the buffer gets more easily used up.

OpenWRT routers (and others) essentially prevent the modem's buffer ever being used by preventing all of the available bandwidth being used. If the modem manufacturers would implement the fixes too, nearly all the available bandwidth could be used.

However, the issue could also be solved by the ISPs but they seem unwilling to look into it. The only ISP I know of that has a fix in place is AAISP.

[ejs]

Youre probably correct ejs .. as mentioned its not something Ive ever investigated in depth other than note what others have said elsewhere.

>> With downstream traffic, there shouldn't be much buffering in the router because the LAN tends to have more bandwidth than the WAN connection.

So basically the fact that I get A for upstream and B for downstream is that indicating that my router is ok taking traffic out onto the WAN...  yet there's an issue that something is slightly suffering outside my network?

I'm not familiar with the latest test that gives bufferbloat grades. ICSI's netalyzr also measures the amount of buffering in each direction. The buffers in places tended to be there to ensure that all the bandwidth can be used, but they're not good for latency. I think these tests try to somehow work out the latency in milliseconds due to buffering.

I think Plusnet's traffic management does add a small amount of buffering, so that could be it.

It occurs because your modem is having to hold back packets because its buffer has filled up.

I'm sorry but this really doesn't make any sense. Where are the packets being held back? They must be in another buffer! I don't think the problem is really a buffer, a.k.a. a queue, being completely full or not. It's about the size of the queue.

[GigabitEthernet]

Overly large buffers have been placed in some models of equipment by their manufacturers. In such equipment, bufferbloat occurs when a network link becomes congested, causing packets to become queued in buffers for too long. In a first-in first-out queuing system, overly large buffers result in longer queues and higher latency, but do not improve network throughput and may even reduce goodput to zero in extreme cases.

https://en.wikipedia.org/wiki/Bufferbloat

[ejs]

I think the main fix in OpenWRT is using fq_codel to actively manage the queue, not preventing all the bandwidth from being used.

[GigabitEthernet]

In order to prevent the buffer from being used in the modem, you have to move the buffer to another device, i.e. the router.

Doing this you have to lose a bit of bandwidth but it is definitely worth it to keep latency low when downloading.

[tommy45]

One thing that i have noticed is this, when i download a file muti threaded  and can max out the connection the latency is quite low sub 30ms typically, but if i can't get max throughput the latency increases to at least double what i see when i can max out the connection, is this bufferfloat ? if not imo it's an indication that something is not working as it should . also  re upstream, latency will differ depending on what hardware is used as a modem, the ECI is faster than the Huawei bt modem

[Weaver]

reading matter:-

bufferbloat explained:

    https://queue.acm.org/detail.cfm?id=2071893

wikipedia article:

    https://en.wikipedia.org/wiki/Bufferbloat

[Weaver]

As a former protocol designer myself (apol for sounding like bragging), I simply can't believe how we got to where we are. There are so many wrong decisions that were taken in the beginning by os designers, router designers and so on. Why single queues, not multiple ones. Where's the use of flow control and effective back pressure?

Ugh.

[Weaver]

Someone made a good point here that the speed tester websites and apps that give a bufferbloat figure are very confused or confusing as you don't know where the bufferbloat is, is it some os or edge router or some ISP's router that are guilty? There's no reason to be including this while suggesting it's about your ISP or you Internet connection when it could be such a variety of things that have nothing to do with your ISP or link.