The following link provides access to assorted Network related drivers including NICs and Modems
»www.rogershelp.com/yahoo ··· drivers/
USB modem drivers and cab files for Win98SE and higher can also be found on the Rogers-Yahoo! CD
Speedtests will usually give you an idea of the speed of your connection, but beware, they are NOT necessarily an accurate measure.
There are essentially 3 ways of testing your speed ...
•You can download a large file from a known site and time it
•You can use a random downloader which downloads logos from lots of sites
•You can use a speedtest site which uses a java or flash software
These all have their uses but they all have limitations that may not give you an accurate picture of your speeds.
•Downloading a large file from a known site only tells you how fast you can get data from *that* site and that will vary depending on network conditions both on and off Rogers network.
•Random downloaders eliminates the problem of downloading from just one site, but introduces latencies as random sites are selected and still the performance will vary according to the network conditions both on and off Rogers network
•Speedtest sites are probably the more accurate way to measure speeds, because they usually eliminate problems such as browser "prefetch" (where your browser has already fetched a good piece of your file before you actually tell it where you want it stored) and they eliminate webserver performance issues at the remote site, and browser performance issues on your own system.
There are two lots of speedtest sites that you can access. Those that are either "on network" or "close network" and those that are "remote".
Remembering that most Rogers traffic goes through sites in Toronto before going out to the world, speeds may be impacted by any delays that result from this trip to and from Toronto.
Now remote tests are for example in New York, Seattle, Washington, etc. When you go to a remote test site your speeds will be impacted by network conditions between you and the server. These conditions can be extremely variable. Some days you may get clear sailing to one server and the next you may get horrible performance to the same server. Remember too that if you use multiple servers, you can only say that your connection speed is *at least* the speed of the FASTEST test site.
Local on network or close network tests are generally more reliable at giving you your actual connection speed. Rogers own speedtest at www.rogers.com/speedcheck is on Rogers own network, so Rogers network can be usually eliminated as a source of problems when measured here. Cogeco has a speedtest site at speedtest.cogeco.net which is "near network" in Cogeco and Rogers have a peering agreement through the Toronto Internet Exchange. Also now available are assorted tests on www.speedtest.net. If you choose to use speedtest.net, you have the choice of lots of different speedtest servers. Generally pick one close to Rogers in Toronto.
If the speeds reported by Rogers and Cogeco's tests are similar, you can be fairly certain that this is the speed of your connection to the network.
Rogers speedcheck can be a little slow at times, presumably due to system load, or its location on the network. Cogeco's is usually very consistent.
When using speedtests, one of the things we look for is consistency particularly if you're using distant servers. Note that you can't use a speedtest and say that "this is the speed I expect for sites in and around NYC" because there are multiple routes to get to NYC ... some may be slow, and some may be fast.
Traceroute (or tracert) is a network tool that will send packets called ICMP Ping packets to a destination system and routers enroute there to determine the time delay to get a packet to and from that router or system.
Traceroute can be executed from a windows "command window" (aka a DOS box) with the command
e.g. tracert www.dslreports.com
The result will look something like this ...
On the left is the "hop number" ... this corresponds with the router or system in *outward bound order*.
The next 3 numbers are the time it took to go to that hop and back on 3 tries
The right is the IP address and system name for that router or system
What we are looking for is relative consistency and progression of the times consistent with the distances from you to the system in question.
In the example above,
Hop 1 is my home router so you expect a very fast response from it.
Hop 2 is the CMTS and that's the time to go from you, out your modem and back again. With DOCSIS modems, you expect this to be 7 to 12 mS
Hops 3 & 4 are routers in the Fallowfield "head end" facility in Ottawa. Notice the time at hop 4 is even faster than hops 2 and 3. This can happen because it is able to respond to the ping faster. And since we're talking milliseconds here, small variations are to be expected.
Hop 5 is a Rogers router somewhere in Toronto (note that it is un-named, like the CMTS and my own router)
The times Ottawa to Toronto are consistent with the total times shown.
Hop 6 is a Rogers gateway router in the TORIX facility on Front street Toronto.
Hop 7 is a nac.net router again at TORIX
Hops 8, 9 & 10 are nac.net routers in New York City. Note the jump to 90 mS on hop 10. This may be caused by network congestion somewhere along the way or it may be caused by loading on the router. Note that routers give pings very low priority and may drop them altogether, which can be seen next ...
Hop 11 is in fact dslreports.com which is hosted at nac.net DSLreports has chosen to disable ICMP ping response to prevent ping attacks. So, the timed out (as indicated by the askerisks) conditions here are absolutely normal.
So, when you do a tracert, your ping request to DSLreports as in this example can be expected to take the route shown above *to get there*. Note that this is NOT NECESSARILY the route that the reply packet from DSLreports will follow. This is a common confusion when interpreting a tracert.
Taking the example above, let's say that hop 8 looked like this instead ...
and all the rest of the hops were as shown.
First reaction says that there's a problem here. The reality is that there is in fact no problem here.
Because the subsequent hops are normally accepted times to the location, this means that this particular router has ping responses on very low priority, so takes a long time to respond ... but that it is forwarding packets with normal speeds since subsequent hops are normal. One can safely ignore the odd numbers here.
Now again taking the same example, say hop 8 looked like that and hops 9 & 10 looked like this
In this case we can now say that there is a problem ... but we cannot determine from the tracert exactly where and what the problem is ... that takes network engineers working in conjunction with other companies engineers to work out.
The problem starts at hop 8, which can mean that
So, what can you do? Report it as a problem to Rogers and if it's on their network, they'll see to it, but if it's say on nac.net, they MAY contact nac.net and work with nac.net to resolve the issue. You can also report it to nac.net yourself, but you may get some resistance since you aren't a customer of theirs directly.
So bottom line is that tracert can give clues as to where problems are ... but can't be definitive.
One place it can be definitive is to the first hop if it's your own router ... if say the pings to my router were 300mS, I'd know that there's a definite problem between my system and the router. It could be someone else clogging up the router such as a someone stealing my wireless signal! It could be a faulty NIC on my compute(s)r. It could be spyware on my systems.
If you're not using a router and you get poor pings on the first hop, it can be your system, your modem or a very poor connection.