micin: below is some general network testing advice I posted somewhere else, perhaps it will help you.
You can do some basic testing on your connection with ping and tracert. First, tracert to somewhere (don't really matter, use the IP of an ET server you like to play on, or etcenter or google) like this, in a command prompt:
tracert www.google.com
The output will be something like this:
Code: Select all
Tracing route to www.l.google.com [66.102.7.99]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1 [192.168.1.1]
2 14 ms 13 ms 13 ms rdns.of.your.isp.gateway [1.2.3.4]
3 13 ms 14 ms 13 ms rdns.of.some.other.router[5.6.7.8]
...
To test your connection between you and your router, use:
ping -n 100 -l 1000 <ip.of.your.router>
The -n 100 means to use 100 packets, and the -l 1000 means use 1000 byte packets (that's a lower case L). Longer packets are far more likely to show up line problems.
This should give zero packet loss and <10ms pings. If it gives you packet loss, either your router sucks, your ethernet cable is bad, or perhaps some setting for your ethernet card is incompatible.
To test your DSL line, find the IP of the second hop (the one that isn't your router, i.e. the first one that has a >10ms ping), and ping it with the same command. Any packetloss most likely indicates a problem (unless its 100%, in which case, it is likely that router is simply ignoring your pings). The pings times should be fairly steady if there is no other traffic on the line, typically in the range of 30-80 ms for DSL with this packets size. If there is any significant packet loss, chances are you need to complain to your ISP.
You can move on down the IPs listed in the tracert using the same method, if you want, however, if the problem is in a router that is more than a couple hops away, chances are it is a temporary issue, and you can't do much to get it fixed.
