The Infernal Lagmonster

Started by Cuusardo, March 09, 2005, 01:24:56 PM

Is it just me that it's getting, or is the whole mud experiencing the attacks from this awful critter?
Quote from: AnaelYou know what I love about the word panic?  In Czech, it's the word for "male virgin".

Quote from: "Taken Directly from Help Files"

When a user repeatedly engages in acts of sexual deviance, they may experience minor to major lag. This lag is caused by the light-avoiding immortals sitting in their basement, constantly review the scene. Should mudders wish to abolish this unfortunate lag, they should seek their thrills outside of the virtual gaming world. Or, to get more of an excersize, write yourself a story, buy some KY, and relax the old fashioned way.
your mother is an elf.

Yes, I've experienced horrible lag. It's been the cause of death for several of my pc's.

Yep.  Over the last week, but I hadn't noticed it much before that.

Seeker
Sitting in your comfort,
You don't believe I'm real,
But you cannot buy protection
from the way that I feel.

It appears to be network not game related.

--- ginka.armageddon.org ping statistics ---
25 packets transmitted, 25 received, 0% packet loss, time 24020ms
rtt min/avg/max/mdev = 137.772/423.740/613.958/124.606 ms, pipe 2


I tried to do a traceroute to test the next route upstream but I can't get a clean traceroute.  Overloaded router?
quote="Morgenes"]
Quote from: "The Philosopher Jagger"You can't always get what you want.
[/quote]

I'm lagging as well, but I'm also lagging on various websites. I connect to SBC in Connecticut, the same "general" location as Ginka. So it probably isn't the server, but instead some router issue in the state.

Thanks SBC, for buying SNET and utterly destroying it.

Quote from: "Bestatte"I'm lagging as well, but I'm also lagging on various websites.

Ditto. I doubt it's Ginka, it's that <bleep bleep bleep> SNET. It's gotten so bad that I can't play at all sometimes - then it'll clear up for a few minutes, then strike again unexpectedly.

I think Moofassa's quote is the most accurate.

I think Moofassa's quote is the most accurate.

Okay, really hard to play certain roles in network lag. If the game is lagged the critters are as well. Unfortuantly, they are a zippy as ever and I am not. So I dug in a little deeper.

The problem is pretty close to ginka.

*warning* Tech gobbdly gook follows.

PIng to ginka.armageddon.org
PING ginka.armageddon.org (64.252.79.51) 56(84) bytes of data.
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=0 ttl=237 time=467 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=1 ttl=237 time=417 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=2 ttl=237 time=643 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=3 ttl=237 time=605 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=4 ttl=237 time=604 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=5 ttl=237 time=604 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=6 ttl=237 time=549 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=7 ttl=237 time=544 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=8 ttl=237 time=540 ms
64 bytes from 51.79.252.64.snet.net (64.252.79.51): icmp_seq=9 ttl=237 time=503 ms

--- ginka.armageddon.org ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 417.600/548.260/643.810/66.620 ms, pipe 2


Alright.. pretty nasty stuff there. Now traceroute to ginka.
traceroute to ginka.armageddon.org (64.252.79.51), 30 hops max, 38 byte packets
1  [censored]  21.225 ms  7.271 ms  10.396 ms
2  [censored]  19.054 ms  10.552 ms  24.921 ms
3  68.2.13.234 (68.2.13.234)  9.608 ms  13.488 ms  14.144 ms
4  68.2.13.134 (68.2.13.134)  14.016 ms  14.655 ms  10.495 ms
5  68.2.13.34 (68.2.13.34)  24.922 ms  16.478 ms  15.088 ms
6  chnddsrc01-gew0304.rd.ph.cox.net (68.2.14.9)  11.590 ms  13.794 ms  12.786 ms
7  chndbbrc01-pos0101.rd.ph.cox.net (68.1.0.164)  13.319 ms  16.857 ms  14.359 ms
8  langbbrc01pos0401.r2.la.cox.net (68.1.1.228)  40.240 ms  22.711 ms  22.375 ms
9  ex1-p4-0.eqlaca.sbcglobal.net (151.164.89.21)  49.156 ms  22.442 ms  36.674 ms
10  bb1-p6-0.cranca.sbcglobal.net (151.164.41.30)  35.826 ms  28.838 ms  33.855 ms
11  core1-p9-0.cranca.sbcglobal.net (151.164.40.93)  36.286 ms  38.750 ms  34.920 ms
12  core2-p1-0.cranca.sbcglobal.net (151.164.241.222)  23.016 ms  24.203 ms  25.458 ms
13  core2-p4-0.crskut.sbcglobal.net (151.164.241.106)  46.507 ms  50.473 ms  44.117 ms
14  core1-p8-0.crskut.sbcglobal.net (151.164.243.249)  40.679 ms  49.319 ms  39.302 ms
15  core1-p2-0.crdnco.sbcglobal.net (151.164.243.242)  49.765 ms  50.202 ms  66.329 ms
16  core1-p5-0.crkcmo.sbcglobal.net (151.164.42.23)  52.031 ms  51.586 ms  57.273 ms
17  core2-p5-0.crchil.sbcglobal.net (151.164.191.199)  61.111 ms  61.223 ms  62.201 ms
18  core1-p8-0.crchil.sbcglobal.net (151.164.188.42)  87.020 ms  75.444 ms  65.675 ms
19  core1-p3-0.crcloh.sbcglobal.net (151.164.188.182)  163.053 ms  169.613 ms  228.915 ms
20  core2-p8-0.crcloh.sbcglobal.net (151.164.188.194)  68.992 ms  69.296 ms  68.202 ms
21  bb1-p3-0.bcvloh.sbcglobal.net (151.164.41.182)  73.656 ms  71.800 ms  69.773 ms
22  bb2-p9-0.mrdnct.sbcglobal.net (151.164.188.242)  99.320 ms  80.549 ms  88.871 ms
23  dist1-vlan40.mrdnct.sbcglobal.net (66.159.184.113)  80.716 ms  100.673 ms  78.722 ms
24  rback3-fa2-0.mrdnct.snet.net (66.159.184.198)  89.034 ms  82.338 ms  80.203 ms
25  51.79.252.64.snet.net (64.252.79.51)  529.256 ms *  566.866 ms


Notice item 24. Thats the router just upstream from ginka. Now, lets guess at an address that is not ginka but is served by the same router.

traceroute to 64.252.79.50 (64.252.79.50), 30 hops max, 38 byte packets
1  [censored] 36.714 ms  8.033 ms  8.237 ms
2  [censored]  14.275 ms  12.351 ms  10.198 ms
3  68.2.13.238 (68.2.13.238)  13.875 ms  8.209 ms  9.874 ms
4  68.2.13.134 (68.2.13.134)  15.820 ms  6.925 ms  7.897 ms
5  68.2.13.34 (68.2.13.34)  11.567 ms  17.777 ms  9.371 ms
6  chnddsrc01-gew0304.rd.ph.cox.net (68.2.14.9)  10.461 ms  9.397 ms  12.504 ms 7  chndbbrc01-pos0101.rd.ph.cox.net (68.1.0.164)  11.379 ms  9.656 ms  8.265 ms 8  langbbrc01pos0401.r2.la.cox.net (68.1.1.228)  21.146 ms  22.324 ms  33.821 ms
9  ex1-p4-0.eqlaca.sbcglobal.net (151.164.89.21)  23.260 ms  22.858 ms  22.653 ms
10  bb1-p6-0.cranca.sbcglobal.net (151.164.41.30)  26.168 ms  27.524 ms  26.631 ms
11  core1-p9-0.cranca.sbcglobal.net (151.164.40.93)  23.889 ms  24.291 ms  23.075 ms
12  core2-p1-0.cranca.sbcglobal.net (151.164.241.222)  47.148 ms  24.262 ms  22.352 ms
13  core2-p4-0.crskut.sbcglobal.net (151.164.241.106)  44.089 ms  42.934 ms  45.913 ms
14  core1-p8-0.crskut.sbcglobal.net (151.164.243.249)  40.074 ms  38.725 ms  42.256 ms
15  core1-p2-0.crdnco.sbcglobal.net (151.164.243.242)  52.271 ms  61.911 ms  51.105 ms
16  core1-p5-0.crkcmo.sbcglobal.net (151.164.42.23)  48.887 ms  48.273 ms  55.682 ms
17  core2-p5-0.crchil.sbcglobal.net (151.164.191.199)  63.501 ms  72.727 ms  69.820 ms
18  core1-p8-0.crchil.sbcglobal.net (151.164.188.42)  63.264 ms  71.883 ms  73.026 ms
19  151.164.42.9 (151.164.42.9)  99.058 ms  75.415 ms  70.585 ms
20  bb2-p6-0.bcvloh.sbcglobal.net (151.164.41.194)  70.829 ms  72.802 ms  73.160 ms
21  bb1-p10-0.bcvloh.sbcglobal.net (151.164.242.45)  81.663 ms  70.772 ms  74.934 ms
22  bb2-p9-0.mrdnct.sbcglobal.net (151.164.188.242)  81.678 ms  80.835 ms  85.485 ms
23  dist1-vlan35.mrdnct.sbcglobal.net (204.60.219.227)  78.445 ms  92.322 ms  81.694 ms
24  rback3-fa2-0.mrdnct.snet.net (66.159.184.198)  87.816 ms  100.448 ms  80.774 ms
25  50.79.252.64.snet.net (64.252.79.50)  90.110 ms  98.645 ms  95.739 ms


Yep, same router, hmm line 25 looks better, lets ping it.

PING 64.252.79.50 (64.252.79.50) 56(84) bytes of data.
64 bytes from 64.252.79.50: icmp_seq=0 ttl=31 time=94.0 ms
64 bytes from 64.252.79.50: icmp_seq=1 ttl=31 time=91.1 ms
64 bytes from 64.252.79.50: icmp_seq=2 ttl=31 time=94.6 ms
64 bytes from 64.252.79.50: icmp_seq=3 ttl=31 time=99.3 ms
64 bytes from 64.252.79.50: icmp_seq=4 ttl=31 time=101 ms
64 bytes from 64.252.79.50: icmp_seq=5 ttl=31 time=109 ms
64 bytes from 64.252.79.50: icmp_seq=6 ttl=31 time=92.5 ms
64 bytes from 64.252.79.50: icmp_seq=7 ttl=31 time=94.2 ms
64 bytes from 64.252.79.50: icmp_seq=8 ttl=31 time=93.4 ms
64 bytes from 64.252.79.50: icmp_seq=9 ttl=31 time=110 ms

--- 64.252.79.50 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 91.166/98.083/110.469/6.689 ms, pipe 2


Yep, a different address served by the same router is fine.  By the latency it also looks like dsl line. This means the problem is close to home.  Now this coulld mean the the router may have issues, there are line problems,  someone hacked the system and is using the site as a "wares" site (doubtfull, easy to detect), faulty nic, etc, etc.  I am sure the ginka staff is diligently working on the problem. At least it is up and running, just forces us to slow down.

[edited for typos. reminder to self: Don't post when tired.]
quote="Morgenes"]
Quote from: "The Philosopher Jagger"You can't always get what you want.
[/quote]

There's nothing wrong with Ginka. There is something wrong with the route leading TO Ginka. It is a problem with SBC.

In your traceroute to ginka:

Quotecore2-p1-0.cranca.sbcglobal.net (151.164.241.222)  23.016 ms  24.203 ms  25.458 ms
13  core2-p4-0.crskut.sbcglobal.net (151.164.241.106)  46.507 ms  50.473 ms  44.117 ms

That's where the trouble begins. You double the ms in a single hop, shooting WAY over 30, which is the usual benchmark to determine trouble.

And from then on, it continues to rise, almost doubling every 2nd hop from that point on.

This would explain why I am ALSO having trouble getting packets in and out of MY computer, even when I'm -not- trying to get to ginka. It's because I also use SBC for my internet service, and I'm also using their DSL lines.

Remember there was a HUGE storm here 2 days ago, which is kinda sorta when the real trouble started. A few lines were down, and accidents everywhere. It wouldn't surprise me in the least if there was some damage to a DSL box on some obscure street corner somewhere.

Quote from: "Bestatte"There's nothing wrong with Ginka. There is something wrong with the route leading TO Ginka. It is a problem with SBC.

I'm not disputing that.  Yes network problem. I listed the others because I have seen them, the strong likelyhood is that it is telco related.

Quote from: "Bestatte"
In your traceroute to ginka:

Quotecore2-p1-0.cranca.sbcglobal.net (151.164.241.222)  23.016 ms  24.203 ms  25.458 ms
13  core2-p4-0.crskut.sbcglobal.net (151.164.241.106)  46.507 ms  50.473 ms  44.117 ms



That's where the trouble begins. You double the ms in a single hop, shooting WAY over 30, which is the usual benchmark to determine trouble.

That is certianly A problem, but probably not THE problem in this case.

Point in case is the second address on the SAME series of hops(look at lines 11 and 12, same jump), yet it's latency is 1/5 that of ginka.  The difference is here is telco.  If this was Arizona I would have stated storm related.  Because it rains so seldom here, when it does rain, weather related issues crop up right and left.

There are probably multiple points of failure here, the critical one being most likely telco related. We are are just armchair quarterbacking here, I'm sure ginka's staff is working on it.  Dealing with Telco and internet companies requires patience. Point of all of this was to state that this is not a game problem, but rather something out of thier immediate control.  Legitimate as it is, I probably should have left the last paragraph out, but I have been burned too many times to ever rule anything out.  Like I stated, I was tired. :)
quote="Morgenes"]
Quote from: "The Philosopher Jagger"You can't always get what you want.
[/quote]

Help_Concern says:

QuoteIn the case of internet issues, all concerns referencing Ginka will be ignored. Especially two days after a storm. Most particularly, when ANYONE accessing the internet via SBC in Connecticut, who normally takes under 50ms to reach RUSSIA requires at least 50ms to reach a server 5 towns away from the central office in their own town.

20 good, 40 bad!  I know!  I techie!  I know.  Borsh.