Originally Posted by aeroclown
Like i have said before and Like ill say again, most of the problems typically occur in route, its not specifically either end but typically a problem in route.
Routes are not always dynamic in most cases, Routes are very often statically assigned by your region and by your default gateway. The majority of which is determined at your c/o, If your Default gateway or dns changes so will your route. There are known network routes that always seem to have problems as has been illustrated before. I know that when my isp changes the default gateway to work on something and I'm routed through arpnet my connection works like crap, when they switch it back and i'm off arpnet things are normal. If you are having problems the first place you can probably check is your default gateway. That is the default gateway assigned to your modem, if you have a router you will need to check the page that contains ip information for it, this should not be a private Class c address (192.xxx.xxx.xxx). Run something like pathchirp or run a ping with a packet count of atleast 50. If things are looking good from your modem to your isp assigned default gateway its a pretty good chance that the problem is outside the bounds of control for either arena net or your isp. The sad part about that is that if that is the case there is little you or areana net can do about the issue beyond report it or send nastygrams to the offending network support lines. While there may very well be other factors at play, with a thin client system, I am far more inclined to believe the issue is an external network issue then a localized system issue. I would also like to add that utilities like PathChirp do you very little good if you don't know the route/destinations to check with the tools. As the syntax seems to indicate the need for both a send/originating ip address and a recieving/destination address. while i'm sure it is great for checking on bandwidth bottle necks you have to first find the Destinations you want to check. Thats my 0.02 i apologize if my first post in this thread was a bit cold cut, but there are just a flood of threads on this issue and they are all the same and very often all remain unresolved because the Point of the problem extends outside the control of either party. |
Forgot to add this in.
Originally Posted by gr3g
I love seeing people who have no clue about how the internet works saying big words like "traceroute" and "backbone". Here's a little experiment: try tracerouting to a bunch of different places on the internet such as google, amazon, guildwarsguru.com, etc. See how on many of them traceroute just stops working after a few lines? Go a dozen hops away on the internet and traceroute and the like stop being reliable. The packets are being dropped because of strange TTLs (which can indicate all sorts of things including internet attacks), not because no routes exist.
If you want to do serious end-to-end bandwidth and latency measurements, traceroute doesn't do it. Traceroute only (kinda sorta) shows the route. You don't care about the route, because you know that you can connect to GW. What you care about is bandwidth and latency. use a tool like pathChirp or netest. If you have lower end-to-end bandwidth to guildwarsguru.com than to GW's servers, then that there is your problem. Of course knowing where the problem exists is only half the battle. If somewhere on the path between your computer and GW's servers some service provider is playing silly QoS games, you're basically SOL. |
I DID do those test(ANet, Guru, Google, like you said, and Amazon was the ONLY one that dropped out(after 25 hops). Heres pics of the others
These CLEARLY show that the problem is somwhere along the away, NOT at my end, and NOT at ANets end. Its in the pathing getting from my PC to ANet. Yes, knowing the latency spikes and bandwith is nice, but since its probably not something you can fix, all that tells you is exactly where the problem lies.