Monday, August 18, 2008

DG834 stats daemon

Since I moved I've had a lot of problems with my ADSL connection intermittently dropping out for as much as 10-15 seconds. While any drop-out is annoying because it interrupts my browser, gmail, loses my IRC and iChat connections and so on, it's back quickly enough that I'm not motivated to complain. Last Friday, however, it dropped out for nearly 30 minutes and that's over the line.

Three months ago when the BT engineer came to install my line (the previous tenant having moved it elsewhere) he tested it and told me it was good for a line of this length (I'm about 1.5km from the exchange IIRC). However testing on Friday the Nildram engineer told me that the signal-to-noise ratio was too low.

I have a DG834v1 ADSL router with a web interface. Whenever I went and checked the noise margin was about 6db. According to the engineer 6 is very marginal and is the lower limit the DSLAM requires to hold onto the ADSL connection. During testing I saw it drop below 6. Presumably this is the reason for my dropouts.

He thought that the intermittent nature of the problem meant it was most likely my line but suggested swapping my line filter as a precaution.

After changing the line filter I noticed this morning that my noise margin was 9. Then it was 4. Then it was 9 again. I decided it was time to get serious about tracking this. I didn't fancy scraping the website, but It turns out that the DG834 has a telnet interface that you can turn on.

The DG834 runs linux and, with some reading, I was able to find the right file containing the ADSL stats (most instructions are for the v3, mine is a v1). From there it was childs play to cook up a Ruby daemon that makes a telnet connection to the router and periodically captures the ADSL line info to a file.

In case it's of interest I've put my dg834statsd code up on github. Every 10 seconds it logs the ADSL line info to disk in both CSV and JSON formats. Here's a sample of the output:


The columns are time, downstream line speed, downstream attenuation, downstream margin, downstream transferred, upstream line speed, upstream attenuation, upstream margin, upstream transferred

Now I can easily track my S/N margin in semi-realtime and will have some useful stats for the Nildram guys when I phone them back.

18/08/2008 11:24 by Matt Mower | Permalink | comments:
More about:

Turning noise back into signal

My DG834 stats daemon has been collecting data all day, some 3387 samples at last count. Since Apple's Numbers (no matter how pretty) makes an appalling data analysis tool I turned instead to R.

samples <- read.csv( '/Users/matt/Projects/ruby/dg834statsd/log/dg834.csv', header = FALSE )
data <- table(V4)
plot( data )

It took me 5 minutes with my copy of Statistics: An introduction using R to remember the <- and attach invocations needed, otherwise generating the data was a breeze. Here are the raw numbers:


and a basic plot:

Quartz 2 [*]
Uploaded with plasq's Skitch!

All of which shows that my connection is fairly stable except for those moments when it's not. Given that there are no 2's or 3's at all and the margin is solidly 9, not 6, something seems to have changed since Friday. Given that there are 4's and 5's I'm hoping that the new line filter has improved things and some effort from BT might improve them further. It's possible of course that BT have responded to Nildram's fault ticket and this is as good as it will get.

I also note that I have connected at 5.4mbps today which is about 1mbps slower than normal. In ways I don't quite follow I think this may be connected to a higher margin when the connection was established. But at 5+mbps I'd certainly trade a little speed for not getting constantly disconnected. And I haven't noticed being disconnected today.

18/08/2008 20:25 by Matt Mower | Permalink | comments:
More about: