Bandwidth measurement

For a project which I may be working on in the near future, I need to think about how I can measure user’s bandwidth. Although there are many tools available for doing this already (such as speedtest.net and many others), these generally all require java or a recent version of flash to be installed. Plus they appear mainly geared towards testing a broadband connection, rather than a dial up (or other slow type of connection). I’d like to avoid creating a program that needs to be installed on a users machine as I need to keep it as simple as possible.

My current thinking, avoiding any installation and as little effort as possible on the users part, is to use a simple webpage with a small piece of AJAX to download a file of fixed (known) size and just use javascript to calculate how long it takes to retrieve. I realise that there are obvious drawbacks to this approach:

  • hard to measure latency
  • accuracy of javascript timer
  • other processes running on the machine
  • proxy or caching servers getting in the way

However, I don’t need something extremely accurate, just something that is easy to use and gives a reasonable approximation of a users bandwidth (which will be dependent on a huge number of factors anyway, such as time of day, no of other users etc), is it 2kbps, 20kbps or 200kbps?

To get a better idea of the usual speed of a users connection, I can attempt to download several files of different sizes (from different servers), and take averages.

Is there anything I’m missing that would make this a really bad way to approach this? Or would it produce results so inaccurate they’d be useless?

2 Comments

  1. Doug Clow says:

    The one concern I have is the tradeoff between accuracy and impact on the user. For accuracy, you want a fairly large test file, but for impact on the user, you want a very small file. Especially if they’re on a slow connection!

    One way round this might be to measure bandwidth by counting how many small files you can download in N seconds, rather than counting how long it takes to download a large file – which might take substantially longer than N seconds.

    Another option would be a stepped approach – try a 1k file, if it downloads in less than N seconds, try a 10k file, and so on, until you go over N seconds.

  2. Alex says:

    Thanks Doug, yes, I was thinking about using several different file sizes (1k, 10k, 100k) and then downloading each several times – but as you say, you wouldn’t want to download a large file multiple times for someone on a slow connection.

    For impact on the user, it would be something that only ran at their request, I certainly wouldn’t want this to be something that ran without the user knowing about it.

    I think if you were very upfront and clear about how it was working and how the speed was calculated, you could get some useful info from it, especially to show that connection X was roughly Y times quicker/slower than connection Z.

Leave a Reply

*