they have one but its password protected so only VM staff can use it.

The best way is using dumeter or networx and watch it as you do speedtests, downloads etc. Or even tbb's software as they have a live graph monitor as well.

If even at busy times if I find a fast line I can exceed 50Meg from our tester without much issue at all, so not sure what needs fixing on our server

No issue just now getting 80Mbps and higher from download.thinkbroadband.com (the server used did not have flash or java on it). That was a single file thead too

In reply to a post by MrSaffron:

.. not sure what needs fixing on our server..

There's no need to fix anything. It's clearly running to your satisfaction and those, like me, who don't get useful results from it can use alternatives.

just watched a clip of sky news, full 3.9meg/sec for about 30 seconds until it buffered the video.

followed up with a test on tbb and again slow start followed by full speed, classic sympton of dodgy congestion/slow start algorithm, something which is controlled by sending server.

I already told you I have no issue on the file download tests, they fine, whats broken is the speedtester. Assuming the file downloads are on the same network this also puts the peering aside as a culprit as well. It is something unique to the speedtester that is the problem, whether its the code, the settings or the server.

i have also noticed a major difference between ur Java and Flash based testers.

For example and this has happened to me many times.

I tested using Java and it gives me 17.1mb down and 4.4mb up
I tested using flash and got 43.53 down and 4.4mb up

I then retested using Java and got 19.2mb down and 4.5mb up
retested using flash and got 42.18mb down and 4.4up.

You talk about averaging, but don't discuss the environment upstream and downstream of the ISP. That also needs examination: pinging software does so and you'll never get 100MB feeds when the source is only delivering 20MB, for example, or the local LAN only delivers 10MB thanks to the building structure.
True, averaging is important, but it also depends on the reasonable service delivery expectation of the ISP and client. Someone looking for streaming out of a 500KB contract is obviously away with the fairies, someone getting 700KB from a notional 30MB is being dumped on, provided of course they've not abused their download in the past. Is there any reason not to deliver a matrix of tests, burst, continuous and average, against a variety of data types?
Then again, time is also important: to draw valid conclusions a test should be run at intervals over at least a day, to identify maximum likely delivery (0330am!) and stochastic loading: an ISP will never have broadwidth proportionate to its customer base, as the more customers it has the more stable the demand and the more it can trade off on the queueing average. That can come gloriously unstuck when, for example, a new online game is launched all their customers want to download at once.

Just ignore the thinkbroadband speedtest. It is slow and inaccurate. There is a reason that nobody uses it, save for some tbb members.

Edited by deleted (Sat 20-Aug-11 08:24:19)

In reply to a post by Roph:

Just ignore the thinkbroadband speedtest. It is slow and inaccurate. There is a reason that nobody uses it, save for some tbb members.

Its inaccurate on Virgin Media because of issues with Virgin Media's routing. This is discussed in the Talk To the Staff forum. To me on BE the TBB speedtest gives the same results as speedtest.net, or bbmax and other sites.

If the sites you want to use also share the same routing, then they will be slow on Virgin Media. If the sites you want to use don't use this routing then they will be fine.

YMMV.

It can't just be the routing. No UK routes are busy at 6:30 AM.

In reply to a post by kwikbreaks:

It can't just be the routing. No UK routes are busy at 6:30 AM.

No, its probably caused by VM testing latest throttling technologies. Worth reading the thread a few weeks back in Talk To The Staff.