LWN.net Logo

The CoDel queue management algorithm

The CoDel queue management algorithm

Posted May 29, 2012 7:46 UTC (Tue) by spaetz (subscriber, #32870)
In reply to: The CoDel queue management algorithm by Jonno
Parent article: The CoDel queue management algorithm

> While I know that some backwater nations, such as the US, have all but no working infrastructure, don't assume that is the norm

Let me assure you that this is *not* the norm even in EU countries (can't speak for Asia). If you are below 20-30ms ping time for the first hop, you are the exception. (perhaps not in Sweden, but in Europe for sure).

And there is no need to insult countries here.


(Log in to post comments)

The CoDel queue management algorithm

Posted May 29, 2012 8:47 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

the simple truth is that it's far easier to wire a small country than it is to wire a large county.

If you have a high population density you also have the ability to spread the cost of doing so across many more people.

and frankly, it helps to be late to the party as you only have to implement the latest and best technology, not each generation as it is developed (never mind paying the cost of the development)

the result is that in small, high population density countries you can have really good infrastructure, but in larger areas you aren't going to have nearly as goon an infrastructure, not matter what the cost.

I live in the greater Los Angeles area, but out around the edge of it. I pay $130/month for 1.5Mb down/768Kb up. I could upgrade to an ethernet connection up to 5Mb, but then it would cost me $100 per Mb.

and I'm in a 'good' (but not 'great') area for connectivity. Where my sister lives, their only option is satellite (with a ~1000 ms first hop ping time) to give you an idea of how remote they are, they literally live 20 miles from the nearest fast food place.

now there are places in the US with connectivity almost as good as what you get (although at higher out-of-pocket costs, I'm assuming that your system has some tax money included in it), and I wouldn't lay a bet either way on if there is more area covered with such good coverage in the US vs in Sweden, but it could be several multiples larger in the US and not make a significant dent in the problem.

The CoDel queue management algorithm

Posted May 29, 2012 13:46 UTC (Tue) by Jonno (subscriber, #49613) [Link]

> the simple truth is that it's far easier to wire a small country than it
> is to wire a large county.

Sweden may only be 5% of the US, but it's still larger than any US state but Texas and Alaska. In a more fair country-to-country comparison, Sweden is larger than for example Germany, Italy and the United Kingdoms.

> If you have a high population density you also have the ability to
> spread the cost of doing so across many more people.

Well, Sweden has 20.6 residents/km², while US has 33.7 residents/km², so obviously US should have much better Internet connection than Sweden...

> and frankly, it helps to be late to the party as you only have to
> implement the latest and best technology, not each generation as it
> is developed (never mind paying the cost of the development)

Well, the Swedish broadband infrastructure project began back in 1998, and for the last few years people have started to complain that next-to-nothing have happened for over 5 years. While most of Sweden have been upgraded to ethernet, fiber or cable connections over the years, 35% of all Swedish households are still limited to the previous generation broadband access, because the goverment stopped subsidizing broadband infrastructure projects once ADSL was deployed everywhere (well, 99.91% of households) back in 2005.

Yes, ADSL is considered previous generation broadband access in Sweden, even though base stations have been upgraded to support 24/1 Mbps compared to the 8/1 Mbps that was common in 2005.

The current generation of broadband access (usually an ethernet jack, sometimes a cable-tv modem) started to roll out in 2000, but wasn't common until 2005, when it reached 40% coverage. Today that figure is 65%. Personally, I got a "real" broadband connection in 2002, albeit back then the speed was only 10/2 Mbps and it cost $28 per month. I got my current 100/10 Mbps connection when I moved in 2004, though at the time it was quite expensive at $45 per month.

> I live in the greater Los Angeles area, but out around the edge of it.
> I pay $130/month for 1.5Mb down/768Kb up. I could upgrade to an ethernet
> connection up to 5Mb, but then it would cost me $100 per Mb.

Poor soul, for that kind of money ($126) I could get 250/100 Mbps. Of course, that is because I live in an apartment complex in the middle of a medium-sized town. Most rural residents can't get anything better than ADSL at 24/1 Mbps, and will have to pay $49 to get even that much.

> I'm assuming that your system has some tax money included in it

Well, 2002 through 2005 the government subsidized about half the cost of all broadband infrastructure project, but since then they have only subsidized rural broadband projects, and usually only in the form of targeted low interest loans.

The CoDel queue management algorithm

Posted May 30, 2012 13:50 UTC (Wed) by job (guest, #670) [Link]

Higher population density? Late to the party? Please try to get your facts straight next time if you're going to waste electrons on a post.

The CoDel queue management algorithm

Posted May 30, 2012 14:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

In Ukraine no tax money go into ISP business. Indeed, competition is fierce.

Yet we get 100Mb for $8 a month in cities.

The CoDel queue management algorithm

Posted May 29, 2012 22:05 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. I *might* be able to get this in the UK with fibre to the premises (rare as hen's teeth), but fibre to the cabinet couldn't do it and my existing bonded ADSL connection to an exchange <100m away has no hope:

1 spindle.srvr.nix (192.168.16.15) 0.056 ms 0.040 ms 0.063 ms
2 fold.srvr.nix (192.168.14.1) 0.341 ms 0.317 ms 0.297 ms
3 [ADSL router] 1.688 ms 1.685 ms 1.674 ms
4 c.gormless.thn.aa.net.uk (90.155.53.53) 17.026 ms 24.144 ms 27.475 ms
5 b.aimless.thn.aa.net.uk (90.155.53.42) 26.062 ms 33.940 ms 33.919 ms

(as usual, the timing figures from the last two hops are upper bounds because those machines are going to be delaying ICMP replies as they see fit: still, it's in the 20ms range, not the 3ms range).

The CoDel queue management algorithm

Posted May 30, 2012 10:08 UTC (Wed) by nye (guest, #51576) [Link]

>my existing bonded ADSL connection

Now we're *really* OT, but what are you using to do the bonding?

I was hoping to do that with a couple of Sangoma PCI ADSL2 modems, but in the small print it turned out that you can only do bonding with them if you're using PPPoE, and I don't know of any UK ISPs that offer that.

I've seen ADSL cards that can do it, but at that point you're better of just going to ADLS2 unless you're doing 4-way bonding or more, and I've seen expensive proprietary boxes that just sort it all out for you, but nothing affordable for an individual or small business.

The CoDel queue management algorithm

Posted May 30, 2012 10:46 UTC (Wed) by TomH (subscriber, #56149) [Link]

Well http://compton.nu/2009/12/per-packet-load-balancing-with-... explains how I bonded four ADSL links with the same ISP.

We're bonding two fibre to the cabinet lines instead now, which use PPPoE and makes things a bit simpler as they are terminated with pppd on the linux box where they can be bonded with teql.

In fact the BT Wholesale ADSL platform does support PPPoE but most ISPs don't tell you that... I did have my line at home running that way for a short while though, in preparation for upgrading it to fibre to the cabinet.

The CoDel queue management algorithm

Posted May 30, 2012 14:32 UTC (Wed) by nye (guest, #51576) [Link]

>Well http://compton.nu/2009/12/per-packet-load-balancing-with-... explains how I bonded four ADSL links with the same ISP.

Thank you for that link. I hope nobody minds the thread-hijacking to ask a little more about this - it's not a topic that seems to have much Google juice.

With that setup, do I understand correctly that - assuming the ISP has the bonding set up on their end - configuring the TEQL interface as you have will work regardless of the connection method used? It looks like it's actually very simple so long as you know the secret sauce.

What I'm not sure about is the IP addresses on the routers. You say that they need to support two different *LAN* addresses; how are the WAN ports configured? Are they bridged or do they need an additional address?

Say for the sake of example that you have a /29 netblock, giving you 6 addresses once you've accounted for the network and broadcast addresses. You use one that's shared between the routers and one for the teql0 interface, leaving 4 available for other machines. Is that correct?

Incidentally, would you recommend the Zyxel P-660 series? I do wonder if a better modem/router might solve my periodic loss of ADSL synchronisation, and while I've tried two different models, it's entirely plausible that they're both fairly intolerant of noisy lines.

The CoDel queue management algorithm

Posted May 30, 2012 14:50 UTC (Wed) by TomH (subscriber, #56149) [Link]

Those routers allow the LAN interface to be given up to two aliases in addition to their primary address.

So what I did was to set the primary address to a unique RFC1918 address, which was just used for management purposes when I needed to telnet to a specific router, and then to set the alias on each router to the same, shared, public address.

I then added static routes on each router to pass traffic for our public IPs back to the linux box where the bonding was done.

The WAN ports were configured with separate public addresses - a unique one for each router.

Bridge mode wasn't used - they were acting as normal routers.

I wouldn't like to say if the P660 is particularly good or bad - they were the free routers our ISP provided with the lines.

The CoDel queue management algorithm

Posted May 30, 2012 15:16 UTC (Wed) by nye (guest, #51576) [Link]

>The WAN ports were configured with separate public addresses - a unique one for each router.

Interesting, so this sounds like a different configuration than some bonding setups which appear to require only a single public IP address. I wonder if that's down to how the ISP configures their interfaces.

I suspect I could make a lot more progress here if experimentation didn't mean scheduling connection downtime of an unknown duration, which in practice means being physically present in a locked office building in the dead of night (for which honestly they Do Not Pay Me Enough™).

At any rate, thanks for the information.

The CoDel queue management algorithm

Posted May 31, 2012 11:21 UTC (Thu) by nix (subscriber, #2304) [Link]

The question really is, will any respondents to this question be using any ISP *other* than AAISP? They really do seem to be the only people who've tried to make line bonding work in any meaningful way, in the UK at least.

The CoDel queue management algorithm

Posted May 31, 2012 13:26 UTC (Thu) by james (subscriber, #1325) [Link]

This is going somewhat off-topic, but Eclipse do, although I haven't used it.

The CoDel queue management algorithm

Posted May 31, 2012 15:03 UTC (Thu) by nye (guest, #51576) [Link]

Entanet also offer a bonded option, and they're one of the wholesalers used by UKFSN.

The CoDel queue management algorithm

Posted May 31, 2012 11:20 UTC (Thu) by nix (subscriber, #2304) [Link]

All I'm using to bond is a multihop default route

ip route add default nexthop via 81.187.191.130 dev adsl weight 1 nexthop via 81.187.191.132 dev bdsl weight 1

to Zyxel P-660R ADSL routers that have no idea I'm bonding them, and two of Julian Anastasov's patches from http://www.ssi.bg/~ja/, to wit 00_static_routes-2.6.39-15.diff and 01_alt_routes-3.0-12.diff, to ensure that when one hop's routes go stale because of upstream problems we switch to the other. (I can't rely on normal 'when the link goes dead' bonding-driver stuff because the link that would go dead comes out of the router. I could fix this by using bridging, but Zyxel's documentation for that setup is so appalling that I haven't tried to make that work yet.)

However, I am lucky in that my ISP (AAISP) provides direct support for bonding on the ISP end: any packets sent to my public IPv4 or IPv6 address ranges will end up being evenly scattered between my lines (which fortunately are of similar speed, see the weight above). So all I have to handle is outbound routing.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds