Is it just me that it's getting, or is the whole mud experiencing the attacks from this awful critter?
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.
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
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?
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.]
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. :)
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.