Thomas 'PointedEars' Lahn wrote:
David Golightly wrote:
>Perhaps the point of this test is not to directly detect the user's
actual connection speed, but their connection speed relative to your
server. Therefore, if your server is in the U.S.A. but the user is in
South Africa, they may well have a T1 connection, but the effective
speed is like a dialup connection. That may give you all the
information you need to determine that "rich," heavy content will take
a long time to download as well.
Given the number of possible different ways each packet could be routed from
host A to host B in a WAN such as the Internet, the results are utterly
insignificant, no matter the connection.
Which shows a remarkable ignorance of how backbone ISP routing is
*actually* done.
Stick to Java script P.E. You can't be an expert in everything, and
trying may not be a wise course if you don't want to look foolish.
In practice, between any two point in the internet, there are normally
just two routes at the IP level. The route there and the route back.
Unless a fault occurs they will tend to persist, being the ones
calculated to be the most advantageous by the ISPs in between.
You can tell this is so using traceroute, which explores the forward route.
It nearly always shows the same set of machines up the route..
Whilst in theory the actual usable bandwidth of any given point to point
connection cannot be guaranteed exactly, it is generally between 20% and
100% of the bandwidth of the weakest link. Any more is impossible, any
less is generally synonymous with severe packet loss and users giving up
on the link or the ISP upgrading the link to get packet loss down.
So very meaningful tests can be done on any given link: the transfer of
e.g. a random image or some such, timed, will give a good indication of
transit speeds and because it is random, will not be cached..
Now thats the bit I DO know about. The Javascript I don't, so over to
someone who does, to indicate how to time a download...