Print

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

[Weaver]

Isn't AlecR campaigning to get things sorted out properly by hassling hw mfrs? Go for it AlecR! 

[GigabitEthernet]

I'm just trying to convince people that when you're downloading, your ping doesn't have to go crazy. People assume it's supposed to work like that but it really is down to poor software and firmware design on modems and routers.

[Weaver]

@AlecR - very commendable.

[Chrysalis]

if the router is able to police bandwidth, then it can at least in theory combat bufferbloat.

I have managed to do this on my asus ac68, however it wasnt without difficulty.  Asus (and broadcom) still are stuck in the stone ages using a 2.6 kernel, which has very old QoS type code, there is none of the modern QoS stuff loaded into the kernel etc.

e.g. I want to add an exception to my samknows box so as to not skew those testing results, the module needed to police NAT devices seperatly is not available in the asus firmware.  So instead I had to look at the ip addresses used by samknows and use exceptions based on those, which is not desirable as those ip addresses can change at any time.  Currently I have whitelisted its downstream tests but not upstream yet.  Also I whitelisted tbb's speedtester ip which was a pain to find as the hostname points to the wrong ip.

[richb-hanover]

I want to commend @AlexR for trying to raise the profile of the bufferbloat problem with manufacturers as well as their customers.

@Weaver - you're asking the right question: how can vendors still claim to have good implementations relying on a single queue for all traffic?

Bufferbloat bites you at the bottleneck link: usually that's your connection to your ISP. It'll happen in either direction, down or up, depending on the gear at the ends. Using fq_codel, you can take control of the bandwidth in *both* directions, so that you minimize bloat/latency each way. I would recommend that everyone try the speed test at www.dslresports.com/speedtest since it measures the latency *during* the download and upload. (I suppose that it's possible that your ISP's internal network is more bloated than the link to your home, but that is not really likely long-term.)

I've been following the discussion on the Bufferbloat.net site for about three years, and it has been delightful to see the improvements in latency/response time after implementing fq_codel. 

In fact, I'm going to put my money where my mouth is. I plan to record a podcast next week over Skype while using netperf to fully-load my 7mbps/768kbps DSL circuit. In practice sessions, it has worked absolutely fine - no garbling, dropouts, etc. as long as I use the fq_codel in the OpenWrt firmware. If it turn it off, the Skype session gets as bad as you might expect.

[Weaver]

@richb-hanover typo in that url back there btw

Its good that you are able to fix problems using the right sw design in your own router. Was the bloat problem located right inside your openwrt device or further upstream? I'm not understanding.

[GigabitEthernet]

There's actually a new algorithm currently in development, called Cake, which should further help to combat Bufferbloat.

[Weaver]

I found this, thanks to AlecR
    http://www.bufferbloat.net/projects/codel/wiki/Cake

which I thought was very good reading. Set me thinking about how I myself could write this stuff, would need to do a lot more reading, that's how

[Chrysalis]

its good but people with asus routers again wont be able to use it due to the old software issue.

I have started considering running my own nix based router from a pc to get round these limitations.

[Chrysalis]

here is some info, downloading win10 now and with it ongoing sent some pings to the bbc.

C:\Windows\system32>ping bbc.co.uk

Pinging bbc.co.uk [212.58.244.18] with 32 bytes of data:
Reply from 212.58.244.18: bytes=32 time=9ms TTL=56
Reply from 212.58.244.18: bytes=32 time=9ms TTL=56
Reply from 212.58.244.18: bytes=32 time=9ms TTL=56
Reply from 212.58.244.18: bytes=32 time=15ms TTL=56

Ping statistics for 212.58.244.18:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 15ms, Average = 10ms

[ejs]

Plusnet's traffic management prioritises pings above normal traffic, so that should keep ping response times looking good while downloading. Something that measures http latency might tell a different story.

[Chrysalis]

ejs that actually doesnt happen, as I have made many posts explaining when I joined sky my pings improved massively during downloading, whatever plusnet are doing to traffic I know one thing for sure, it makes latency worse during activity. To be blunt their QoS system in my view is junk.  Its really a way for them to manage their network and then pretend it improves the end user's experience.

[GigabitEthernet]

I always disliked how Plusnet marketed their QoS as a "good" thing. If I want QoS I'll do it myself.

[ejs]

I don't think Plusnet's traffic management is particularly useful or well implemented, if nothing else, far too much is given the same priority. And you often see people's TBB monitors with increased latency where they were making heavy use of their connection. I think it did work for slower ADSL speeds, at least for an artificial test of downloading something and running the ping command.

I'm still not too convinced about doing QoS at your router on the downstream, it seems a bit late by the time the traffic has already reached your router.

[Chrysalis]

Now my samknows box is exempted down (via samknows ip range) and up (via device MAC), exempting devices on the upstream is easy as it just tags them in iptables.

TBB is exempted down via ip range, but not up.  I toggle my pc MAC on the router QoS if I need to diagnose upload speeds.  The asuswrt GUI oddly has no facility to add destination ips for upstream QoS (asked firmware dev to add it tho), so if I exempt dest ip ranges on upstream for now i would need to manually add the QoS rules.

Also another comment on plusnet, my .us VPN is now over 700% faster.