Shanira
Nov 2, 2006, 03:16 PM
This method won't be usable by PS2 users obviously, unless they have a PC hooked up, and even then the results might be tainted. (but better than nothing)
First off. Apparantly Gameguard doesn't block netstat from revealing what you're connected to, at least as far as I can discern. After logging in to a random universe (I'm not sure which it is; it really doesn't matter in my case as lag is constantly over a second regardless of universe or mission)
The IP I came up with: 198.176.10.9
Using ARIN/RIPE/APNIC (don't ask me, this is all my friend's work) which apparantly hold data for what IP ranges belong to what registrar I found this:
Sega of America, Inc. SEGAOA3 (NET-198-176-10-0-1) 198.176.10.0 - 198.176.10.255
Sega of America, Inc. NETBLK-SEGAOA (NET-198-176-8-0-1) 198.176.8.0 - 198.176.15.255
The IP is definately within their netblock. If it's not the server, it should be good enough; even if there are a few extra hops within SEGA's own network that are bad, it's still a problem SEGA needs to solve.
On to the technical stuff. First I traced the route to the IP. I'd like it if other people getting lag like this could do this as well.
To trace the route do this:
- Start > Run... >
- Type in cmd (Windows 2000/XP) or command (Windows 98/ME)
- A prompt should show up, input tracert 198.176.10.9
- If you want to save the traceroute directly to a file use tracert 198.176.10.9 > tracert.txt which will store the traceroute in a file called tracert.txt
Here's mine:
Tracing route to 198.176.10.9 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 25 ms 25 ms 25 ms s55923c01.adsl.wanadoo.nl [85.146.60.1]
4 29 ms 30 ms 30 ms V774.dr3-asd5.nl.euro.net [194.134.156.13]
5 31 ms 29 ms 30 ms GX-X.cr2-asd4.nl.euro.net [194.134.162.21]
6 30 ms 29 ms 30 ms PC12.er1-asd4.nl.euro.net [194.134.162.9]
7 37 ms 38 ms 37 ms ge-3-0-0-0.loncr5.London.opentransit.net [193.25
1.252.213]
8 37 ms 37 ms 37 ms ge-4-0-0-0.loncr4.London.opentransit.net [193.25
1.242.182]
9 210 ms 210 ms 211 ms po10-0.ashcr1.Ashburn.opentransit.net [193.251.2
40.182]
10 210 ms 210 ms 210 ms gi13-0.ashcr2.Ashburn.opentransit.net [193.251.2
41.54]
11 225 ms 224 ms 390 ms so-1-0-0-0.atlcr1.Atlanta.opentransit.net [193.2
51.240.154]
12 243 ms 244 ms 243 ms so-6-0-0-0.dalcr2.Dallas.opentransit.net [193.25
1.240.142]
13 243 ms 243 ms 243 ms sprint.GW.opentransit.net [193.251.247.158]
14 244 ms 244 ms 245 ms sl-bb20-fw-13-0.sprintlink.net [144.232.20.16]
15 245 ms 244 ms * sl-bb21-fw-14-0.sprintlink.net [144.232.11.218]
16 185 ms 186 ms 185 ms sl-bb22-ana-12-0.sprintlink.net [144.232.20.131]
17 187 ms 187 ms 187 ms sl-bb20-ana-15-0.sprintlink.net [144.232.1.178]
18 186 ms 187 ms 187 ms sl-bb24-sj-4-0.sprintlink.net [144.232.9.93]
19 187 ms 187 ms 187 ms sl-bb21-sj-12-0.sprintlink.net [144.232.3.201]
20 188 ms 187 ms 187 ms sl-st20-sj-13-0.sprintlink.net [144.232.9.58]
21 201 ms 201 ms 204 ms sl-browing-24-0.sprintlink.net [144.223.242.10]
22 200 ms 207 ms 202 ms g2-2-0.a1.hywr.broadwing.net [216.140.3.41]
23 203 ms 202 ms 203 ms 216.140.3.158
24 201 ms 202 ms 202 ms 66-114-194-236.focaldata.net [66.114.194.236]
25 204 ms 204 ms 203 ms 198.176.8.194
26 203 ms 203 ms 203 ms 198.176.10.9
Trace complete.
This shows the route, while long and not particularly the fastest on my end, is not broken. There are no nodes timing out completely. The only glitchy node is sl-bb21-fw-14-0.sprintlink.net which failed to time out on two subsequent traceroutes.
Nothing broken there. It's showing a 203 ms ping as well. So lets verify that for a second:
Pinging 198.176.10.9 with 32 bytes of data:
Reply from 198.176.10.9: bytes=32 time=203ms TTL=43
Reply from 198.176.10.9: bytes=32 time=202ms TTL=43
Reply from 198.176.10.9: bytes=32 time=202ms TTL=43
Reply from 198.176.10.9: bytes=32 time=203ms TTL=43
Ping statistics for 198.176.10.9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 202ms, Maximum = 203ms, Average = 202ms
Yup. Around 200ms ping. If you want to try and post your ping as well follow the same instructions found above but instead of tracert type ping.
Why am I getting over five times the lag my ping would indicate? Is SEGA's netcode so bad it more then quintuples one's ping?
Either way, my conclusion is that this mystery lag people are getting, wether it's constant like in my case and some others, or bursts, I'm thinking it's mostly a problem on SEGA's end.
Of course, it never hurts to have more evidence, so that's why I'm posting this here, so others with lag can contribute to try and find the cause of the problems; and if it lies with SEGA possibly to badger them into doing something. >_>
First off. Apparantly Gameguard doesn't block netstat from revealing what you're connected to, at least as far as I can discern. After logging in to a random universe (I'm not sure which it is; it really doesn't matter in my case as lag is constantly over a second regardless of universe or mission)
The IP I came up with: 198.176.10.9
Using ARIN/RIPE/APNIC (don't ask me, this is all my friend's work) which apparantly hold data for what IP ranges belong to what registrar I found this:
Sega of America, Inc. SEGAOA3 (NET-198-176-10-0-1) 198.176.10.0 - 198.176.10.255
Sega of America, Inc. NETBLK-SEGAOA (NET-198-176-8-0-1) 198.176.8.0 - 198.176.15.255
The IP is definately within their netblock. If it's not the server, it should be good enough; even if there are a few extra hops within SEGA's own network that are bad, it's still a problem SEGA needs to solve.
On to the technical stuff. First I traced the route to the IP. I'd like it if other people getting lag like this could do this as well.
To trace the route do this:
- Start > Run... >
- Type in cmd (Windows 2000/XP) or command (Windows 98/ME)
- A prompt should show up, input tracert 198.176.10.9
- If you want to save the traceroute directly to a file use tracert 198.176.10.9 > tracert.txt which will store the traceroute in a file called tracert.txt
Here's mine:
Tracing route to 198.176.10.9 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 25 ms 25 ms 25 ms s55923c01.adsl.wanadoo.nl [85.146.60.1]
4 29 ms 30 ms 30 ms V774.dr3-asd5.nl.euro.net [194.134.156.13]
5 31 ms 29 ms 30 ms GX-X.cr2-asd4.nl.euro.net [194.134.162.21]
6 30 ms 29 ms 30 ms PC12.er1-asd4.nl.euro.net [194.134.162.9]
7 37 ms 38 ms 37 ms ge-3-0-0-0.loncr5.London.opentransit.net [193.25
1.252.213]
8 37 ms 37 ms 37 ms ge-4-0-0-0.loncr4.London.opentransit.net [193.25
1.242.182]
9 210 ms 210 ms 211 ms po10-0.ashcr1.Ashburn.opentransit.net [193.251.2
40.182]
10 210 ms 210 ms 210 ms gi13-0.ashcr2.Ashburn.opentransit.net [193.251.2
41.54]
11 225 ms 224 ms 390 ms so-1-0-0-0.atlcr1.Atlanta.opentransit.net [193.2
51.240.154]
12 243 ms 244 ms 243 ms so-6-0-0-0.dalcr2.Dallas.opentransit.net [193.25
1.240.142]
13 243 ms 243 ms 243 ms sprint.GW.opentransit.net [193.251.247.158]
14 244 ms 244 ms 245 ms sl-bb20-fw-13-0.sprintlink.net [144.232.20.16]
15 245 ms 244 ms * sl-bb21-fw-14-0.sprintlink.net [144.232.11.218]
16 185 ms 186 ms 185 ms sl-bb22-ana-12-0.sprintlink.net [144.232.20.131]
17 187 ms 187 ms 187 ms sl-bb20-ana-15-0.sprintlink.net [144.232.1.178]
18 186 ms 187 ms 187 ms sl-bb24-sj-4-0.sprintlink.net [144.232.9.93]
19 187 ms 187 ms 187 ms sl-bb21-sj-12-0.sprintlink.net [144.232.3.201]
20 188 ms 187 ms 187 ms sl-st20-sj-13-0.sprintlink.net [144.232.9.58]
21 201 ms 201 ms 204 ms sl-browing-24-0.sprintlink.net [144.223.242.10]
22 200 ms 207 ms 202 ms g2-2-0.a1.hywr.broadwing.net [216.140.3.41]
23 203 ms 202 ms 203 ms 216.140.3.158
24 201 ms 202 ms 202 ms 66-114-194-236.focaldata.net [66.114.194.236]
25 204 ms 204 ms 203 ms 198.176.8.194
26 203 ms 203 ms 203 ms 198.176.10.9
Trace complete.
This shows the route, while long and not particularly the fastest on my end, is not broken. There are no nodes timing out completely. The only glitchy node is sl-bb21-fw-14-0.sprintlink.net which failed to time out on two subsequent traceroutes.
Nothing broken there. It's showing a 203 ms ping as well. So lets verify that for a second:
Pinging 198.176.10.9 with 32 bytes of data:
Reply from 198.176.10.9: bytes=32 time=203ms TTL=43
Reply from 198.176.10.9: bytes=32 time=202ms TTL=43
Reply from 198.176.10.9: bytes=32 time=202ms TTL=43
Reply from 198.176.10.9: bytes=32 time=203ms TTL=43
Ping statistics for 198.176.10.9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 202ms, Maximum = 203ms, Average = 202ms
Yup. Around 200ms ping. If you want to try and post your ping as well follow the same instructions found above but instead of tracert type ping.
Why am I getting over five times the lag my ping would indicate? Is SEGA's netcode so bad it more then quintuples one's ping?
Either way, my conclusion is that this mystery lag people are getting, wether it's constant like in my case and some others, or bursts, I'm thinking it's mostly a problem on SEGA's end.
Of course, it never hurts to have more evidence, so that's why I'm posting this here, so others with lag can contribute to try and find the cause of the problems; and if it lies with SEGA possibly to badger them into doing something. >_>