Now this would be a valid observation only if 'everywhere else' is located in the same physical location as the STO Servers, as different physical locations on the Internet are going to have different connection paths with different performance metrics...
You really should try knowing what you're talking about before making statements like this...
I do know what I'm talking about, if you knew what you are talking about you'd look at the ping report I posted.
I do know what I'm talking about, if you knew what you are talking about you'd look at the ping report I posted.
Ping is not a valid tool for diagnosing a 'dropped packet' condition, as it only measures connection latency. Now if you did know something about TCP/IP, you would have posted your 'Trace Route' and 'Net Test' results, (described in this thread... http://sto-forum.perfectworld.com/showthread.php?t=225155 ) as well as the 'pathping' results, which use the same syntax as the 'tracert' command...
Ping is not a valid tool for diagnosing a 'dropped packet' condition, as it only measures connection latency. Now if you did know something about TCP/IP, you would have posted your 'Trace Route' and 'Net Test' results, (described in this thread... http://sto-forum.perfectworld.com/showthread.php?t=225155 ) as well as the 'pathping' results, which use the same syntax as the 'tracert' command...
Could you take a look at my pathping, then? I'm having similar issues. All other connections work fine, but connecting normally to STO completely fails. I am only able to play STO by using the EU proxy, which nets me 500-700ms of ping. Further traceroutes and net test results are on my other thread in this forum.
Pathping:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
Ping is not a valid tool for diagnosing a 'dropped packet' condition, as it only measures connection latency. Now if you did know something about TCP/IP, you would have posted your 'Trace Route' and 'Net Test' results, (described in this thread... http://sto-forum.perfectworld.com/showthread.php?t=225155 ) as well as the 'pathping' results, which use the same syntax as the 'tracert' command...
Guess what dumb dumb, I'm the OP, and I did post nettest and trace route command results. And that IS enough to diagnose the problem. So you either are pretty ignorant, or you don't know how to read.
Could you take a look at my pathping, then? I'm having similar issues. All other connections work fine, but connecting normally to STO completely fails. I am only able to play STO by using the EU proxy, which nets me 500-700ms of ping. Further traceroutes and net test results are on my other thread in this forum.
Pathping:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
So 'Path Ping' reports that you start having severe Packet Drop starting with Hop #4, which is close enough to your entry point into the Internet to mostly likely be a ISP related issue. Its probably best to contact your ISP and get their help in diagnosing your connection problem...
Guess what dumb dumb, I'm the OP, and I did post nettest and trace route command results. And that IS enough to diagnose the problem. So you either are pretty ignorant, or you don't know how to read.
And with this kind of attitude in your post, do you really expect to receive help with your issue???
Tracing route to patchserver.crypticstudios.com [208.95.185.41]
over a maximum of 30 hops:
1 5 ms 98 ms 99 ms 192.168.1.1
2 * * * Request timed out.
3 23 ms 22 ms 41 ms 172.17.49.53
4 24 ms 31 ms 31 ms 172.17.48.33
5 34 ms 34 ms 35 ms 172.19.240.69
6 35 ms 34 ms 35 ms pos0-11-0-0.milano50.mil.seabone.net [93.186.128
.105]
7 54 ms 57 ms 53 ms xe-9-3-1.franco31.fra.seabone.net [89.221.34.34]
8 54 ms 54 ms 54 ms be3030.agr21.fra03.atlas.cogentco.com [130.117.1
4.217]
9 53 ms 53 ms 52 ms be2188.ccr42.fra03.atlas.cogentco.com [130.117.4
8.114]
10 60 ms 60 ms 60 ms be2262.ccr42.ams03.atlas.cogentco.com [154.54.37
.33]
11 71 ms 71 ms 71 ms be2183.ccr22.lpl01.atlas.cogentco.com [154.54.58
.69]
12 139 ms 140 ms 142 ms be2387.ccr22.bos01.atlas.cogentco.com [154.54.44
.165]
13 136 ms 135 ms 135 ms te4-2.ccr01.bos06.atlas.cogentco.com [66.28.4.25
4]
14 149 ms 142 ms 144 ms 38.111.40.114
15 137 ms 136 ms 137 ms patchserver2.crypticstudios.com [208.95.185.41]
Now your 'Trace Route' and 'Net Test' Results... the 'Trace Route' while within the recommended upper limit of 180ms latency, looks suspicious with the sudden increase along the Cogent Backbone and suggest you have a issue with the Cogent Boston Hub. And the inconsistent results of sustained network throughput in your 'Net Test' results suggest that you're suffering from a silently dropped packet issue... However, neither 'Net Test' nor the 'Trace Route' are good tools for diagnosing dropped packets. This is what the 'Path Ping' diagnostics are for...
You are right, I'm sorry, I am the one with the bad attitude... I had an internal brain error and completely misread one of your posts... Your attitude hasn't been the best either but I can't blame you. Sorry for all that.
Got back home today ... went to do an Elachi Alert ... Lagging MK XII and server not responding for ever ... Can they extend this Elachi alert event at least?
Comments
I do know what I'm talking about, if you knew what you are talking about you'd look at the ping report I posted.
Ping is not a valid tool for diagnosing a 'dropped packet' condition, as it only measures connection latency. Now if you did know something about TCP/IP, you would have posted your 'Trace Route' and 'Net Test' results, (described in this thread... http://sto-forum.perfectworld.com/showthread.php?t=225155 ) as well as the 'pathping' results, which use the same syntax as the 'tracert' command...
Could you take a look at my pathping, then? I'm having similar issues. All other connections work fine, but connecting normally to STO completely fails. I am only able to play STO by using the EU proxy, which nets me 500-700ms of ping. Further traceroutes and net test results are on my other thread in this forum.
Pathping:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\User>pathping patchserver.crypticstudios.com
Tracing route to patchserver.crypticstudios.com [208.95.185.41]
over a maximum of 30 hops:
0
1 182.55.228.3
2 an-tl-br05.starhub.net.sg [183.90.44.54]
3 183.90.44.5
4 203.117.36.41
5 203.117.34.201
6 203.117.34.34
7 203.116.61.118
8 * * *
Computing statistics for 175 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 [TRIBBLE.TRIBBLE.TRIBBLE.TRIBBLE]
0/ 100 = 0% |
1 5ms 0/ 100 = 0% 0/ 100 = 0% 182.55.228.3
0/ 100 = 0% |
2 11ms 0/ 100 = 0% 0/ 100 = 0% an-tl-br05.starhub.net.sg [183.90.
44.54]
0/ 100 = 0% |
3 13ms 0/ 100 = 0% 0/ 100 = 0% 183.90.44.5
0/ 100 = 0% |
4 --- 100/ 100 =100% 100/ 100 =100% 203.117.36.41
0/ 100 = 0% |
5 --- 100/ 100 =100% 100/ 100 =100% 203.117.34.201
0/ 100 = 0% |
6 16ms 0/ 100 = 0% 0/ 100 = 0% 203.117.34.34
1/ 100 = 1% |
7 192ms 1/ 100 = 1% 0/ 100 = 0% 203.116.61.118
Trace complete.
Guess what dumb dumb, I'm the OP, and I did post nettest and trace route command results. And that IS enough to diagnose the problem. So you either are pretty ignorant, or you don't know how to read.
I got 6Megas connection, and Youtube and Torrent go fine!...
Salutes!
So 'Path Ping' reports that you start having severe Packet Drop starting with Hop #4, which is close enough to your entry point into the Internet to mostly likely be a ISP related issue. Its probably best to contact your ISP and get their help in diagnosing your connection problem...
Now your 'Trace Route' and 'Net Test' Results... the 'Trace Route' while within the recommended upper limit of 180ms latency, looks suspicious with the sudden increase along the Cogent Backbone and suggest you have a issue with the Cogent Boston Hub. And the inconsistent results of sustained network throughput in your 'Net Test' results suggest that you're suffering from a silently dropped packet issue... However, neither 'Net Test' nor the 'Trace Route' are good tools for diagnosing dropped packets. This is what the 'Path Ping' diagnostics are for...