Stuff I did last night

Whahey! Another installment of Ash fiddling with his gear.

Let me start by saying this: what usually sets 'enthusiasts' (as the muggles like to call us) apart is that we don't always assume something is inherently operating at its peak. That's what makes Atomic what it is -- taking something, and pushing it further. Finding its limits. Breaking it spectacularly, at times. It's all fun.

When it comes to tweaking, and the pursuit of performance, this sometimes simply involves asking 'What if I did this?' even if there's no real reason to assume doing so would make a difference.
But sometimes, it does.

Bear with me as I wade my way to the point. I've got a nice phat 1000/12000 ADSL connection with iinet. I've had, for some time now, an Uber Linux Box gateway that's using the same firewall and bandwidth shaping scripts I wrote for the Uber Linux Box Project back in Issue 20. Last year, I took it a bit further when, in one of those 'What if I did this?' moments, I decided I wanted to move PPPoE from the ADSL modem to my Uber Box gateway.

The thinking was this: the modem's processor, while sufficient for shuffling packets, is far slower than my gateway. If I ran PPPoE on the gateway, would I get better speeds or lower ping? Afterall, these broadband modems and routers all run embedded Linux, so it was really just moving the task from one machine to another, faster, box.
I know, we're splitting hairs here in differences measured in milliseconds, speeds the likes of which are generally imperceptible to us mushy brained human types. But you know, what if?

So I set the ADSL modem to act as a bridge, and installed PPPoE on my Gentoo Linux box. Wasn't that hard, just a little fiddling and changes to the Atomic scripts, and voila, my Uber Gateway was now talking to the ISP direct. It's actually a natural progression to move PPPoE to the box anyway, I figured, afterall it already manges the iptables firewall, bandwidth shaping, and squid cache.

Actually, there's one caveat. The network expects an MTU of 1500, but PPPoE has an overhead of 8 bytes, so the max MTU of the link itself -- and especially all boxes behind it sharing the link -- has to be 1492 or less. For Linux clients, this is as simple as running 'ifconfig eth0 mtu 1492'. For Windows clients, a little tricky registry hackery is needed. You can still access and use the net fine without setting the max MTU, but you'll get random (and entirely inappropriate) timeouts on tranfers.

Anyway, with it all setup was it any faster? Well, yeah it was. Joining my usual Natural Selection (g0g0 www.ausns.com) haunts showed an ever so slightly lower ping to the servers. In fact, for local servers at least, I seemed to register one of the lowest pings on most of the boxes, not that it far behind before though, and usually only beaten by the gaming admin midgets that live inside the servers themselves. Tweak Windows' TCP/IP settings helps as well, but that's another conversation entirely.

Anyway, this is all a digression. This isn't the Ashton playing with his gear session I was going to allude to.
This latest 'What if?' episode happened just last night, and was one of those simple what-the-heck affairs.
As I said before I'm with iinet and they recently upgraded all plans to ADSL2. The catch of course is that you're going to need an ADSL2 modem to take advantage of the higher rates.

No problem! Recently we got the new Netcomm ADSL2+ NB5Plus4W modem in for review (look out for this soon). So, naturally, I 'What if?'ed and decided to see what sort of speeds ADSL2 could provide over my aging ADSL modem, now that my account was upgraded and all.

Unlike my old ADSL modem the new Netcomm modem has a nice feature of reporting the negotiated ADSL speeds with the DSLAM. I wasn't expecting the full speeds iinet claim of 1000/12000 as naturally all sorts of factors can play a role -- distance from the exchange, quality of the phone line etc.

With the model hooked up and set to use 'ADSL2' it reported a healthy 1024/9260. Higher would be nice, but as a 'free' speed upgrade frm ADSL 8000 speeds, I wasn't about to complain.

Now, the Netcomm comes with its own inline filter for the phone (which, as ADSL users know, is necessary to prevent voice comms from interfering with the ADSL connection). So here's the thing -- I presumed that all filters were created equal. Afterall, the ADSL spec is what it is for the frequency range that can be used. In this 'What if?' moment I was wondering if the line filter had an impact on negotiated ADSL speeds. I'm no telecommunications geek however and don't know enough about frequency spectrums to understand just how the line filter could impact the ADSL signals, especially as it sits between phone and socket and not the modem, but it was worth a try, right?

As it happens, it does!

This simple little device was, indeed, impacting the signal. Hooking up the Netcomm line filter in place of the original Alcatel line filter resulted in the modem re-negotiating a speed of around 860/8240. By contrast, the original Alcatel filter with the Netcomm modem initially gave 1023/9260. That's a 10% difference in efficiency, just by switching line filters on the phone.

Additionally, the Netcomm modem also sports ADSL2Plus and while this connected at just a little higher than standard ADSL2 with the Netcomm filter, it couldn't connect at all with the old Alcatel filter. So clearly the different filters are filtering to different frequencies. It'd be interesting to see what ADLS2Plus is capable of (and with, it seems, the appropriate filter) closer to the exchange.

So long story short if you're using ADSL, and you happen to have more than one filter on hand, try switching them and experiement with your max download speeds. Maybe there's room left to tweak in your connection yet, even after everything else you've done.

Ash