Over the last few days, anyone who has been in C10 or even in the nation war today has noticed some unusual lag. Shots stop registering when they hit the target. This happens often when there get to be a lot of ships in a sector, but it has started happening when sectors aren't even loaded with people lately. I've seen it happen with as little as 4 people in the sector, and it seems to happen at the same time to everyone, which shows it's not just the individual's machine.

I noticed this a couple of days ago, when it was just me and 1 or 2 bot foes.
It lasted for a few seconds, and didn't occur again for the rest of the BP, so it slipped my mind.
But I remember thinking that it was odd at the time.

Yeah, i've noticed this all over.

Noticed as well. One time, many rockets detonated but no damage dealt.

ive noticed a recent jump in convoy lag in h2 in the past couple days.

Had the same problem in c10 on friday and saturday and there were only 2 players and 2 bots in sector.

Much as I hate to shout Lag , I too have noticed some . It isn't continuous , just occurs for 10 seconds or so then picks back up .

Of course this may not be due to vo but to the internet in general, I'm not enough of an expert to say and intermittent faults are notoriously difficult to investigate .

Ecka

Yeah, i've noticed it too, seems more like packet loss than high latency though. WHen I see lag the ships usually *spin*, but are still hittable, it just takes a second or so to register, but during the *lag* I had in BP (5 people in sector) ships seemed to be moving normally, but weapons fire did not register at all. Very random too, I have noticed it while botting too, in a small sector with like 6 bots, and me.

On another note, I have noticed it in other online games, so I really do not think it is VO related.

I'll blaime congent again!

Tracing route to majikthise.guildsoftware.com [204.11.209.42]
over a maximum of 30 hops:

1 1 ms 1 ms <1 ms 192.168.1.1
2 9 ms 9 ms 10 ms 10.236.80.1
3 9 ms 12 ms 9 ms xxx.xxx.xxx.xxx
4 25 ms 11 ms 9 ms 195.182.175.73
5 167 ms 12 ms 24 ms 213.105.175.1
6 10 ms 186 ms 35 ms 62.253.187.178
7 138 ms 10 ms 11 ms 213.105.175.141
8 12 ms 13 ms 12 ms 62.253.185.101
9 86 ms 16 ms 15 ms 62.253.184.2
10 17 ms 37 ms 20 ms 130.117.14.141
11 154 ms 16 ms 21 ms 130.117.2.217
12 16 ms 32 ms 35 ms 130.117.2.18
13 114 ms 110 ms * 130.117.0.185 (flakey router!) [or a multi-homed router and the packet took different path. -a1k0n]
14 109 ms 109 ms 109 ms 154.54.6.18
15 258 ms 113 ms 114 ms 154.54.6.206
16 110 ms 111 ms 142 ms 154.54.1.165
17 126 ms 113 ms 116 ms 38.112.26.190
18 130 ms 122 ms 125 ms 204.11.209.42

Blah...

[edit]

Anyone else feel a DDoS coming on? :D

major lag pretty much everywhere for anyone....

yup

@yoda: "It's Blak! [The now disbanded Black Lance Guild -ed.] Has to be. They're like 50-armed puppeteers, pulling their strings all over the galaxy, steering every one of us toward their own devious end game!"

I'll try a traceroute to that server and see what happens. Hrm. I get this:
3 gig2-3.wkshwiwksh-rtr1.wi.rr.com (24.160.225.105) 8.583 ms 14.001 ms 11.550 ms
4 srp1-0.brfdwijana-rtr1.wi.rr.com (24.160.224.65) 12.170 ms 10.037 ms 14.476 ms
5 srp14-0.milwwirtco-rtr1.wi.rr.com (24.160.225.1) 17.640 ms 15.792 ms 16.051 ms
6 gig6-2.milwwirtco-dar1.wi.rr.com (24.160.225.141) 22.272 ms 10.419 ms 9.629 ms
7 rrcs-24-123-87-2.central.biz.rr.com (24.123.87.2) 10.711 ms 10.739 ms 9.832 ms
8 * * *
[blocked at the router. no traceroute for you. -a1k0n]

Now I KNOW that not all of those damn servers are "non-reporting." We've got some packet collisions or some congestion there. Or that switch doesn't have a proper return path or is dropping the query request. Or something else is broken.

Wow, how do you have 25 hops?

welcome to my world. on a general basis, 1/4th of all my shots never register. c-10 and b-12 are totally unusable for me. it takes far too many shots for me to register a kill.

given the blue's current fad is also to abuse bp/bs by not taking the mission and thus gaining gankerbot advantage, i've totally stopped going in vo for a fight in the short amount of time i can allocate to the game.

once i'm done with my rl training, in a couple of weeks, i'll be back in game for a while and reassess weither it makes sense for me to go on.

edit;
i ran traceroute too, fer fun:

iMac-Core-2-Duo:~ mouser$ traceroute majikthise.guildsoftware.com
traceroute to majikthise.guildsoftware.com (204.11.209.42), 64 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 0.597 ms 0.363 ms 0.439 ms
2 * * *
[your traceroute doesn't work, most likely due to your cable/dsl router. -a1k0n]
64 * * *
iMac-Core-2-Duo:~ mouser$

and ping:

iMac-Core-2-Duo:~ mouser$ ping majikthise.guildsoftware.com
PING majikthise.guildsoftware.com (204.11.209.42): 56 data bytes
64 bytes from 204.11.209.42: icmp_seq=0 ttl=52 time=37.455 ms
64 bytes from 204.11.209.42: icmp_seq=1 ttl=52 time=37.842 ms
64 bytes from 204.11.209.42: icmp_seq=2 ttl=52 time=37.194 ms
^C
--- majikthise.guildsoftware.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 37.194/37.497/37.842/0.266 ms
iMac-Core-2-Duo:~ mouser$

traceroute to majikthise.guildsoftware.com (204.11.209.42), 64 hops max, 40 byte packets
1 * * *
2 blk-89-200-1.eastlink.ca (24.89.200.1) 11.540 ms 18.748 ms 45.027 ms
3 24.222.97.217 (24.222.97.217) 31.325 ms 20.358 ms 14.878 ms
4 hlfx-br1.eastlink.ca (24.222.79.205) 12.725 ms 21.379 ms 16.454 ms
5 hlfxns01dr01.bb.telus.com (209.29.247.157) 15.046 ms 19.265 ms 17.768 ms
6 hlfxns01br00.bb.telus.com (154.11.7.211) 76.280 ms 46.872 ms 48.737 ms
7 mtlxpqvvbr00.bb.telus.com (204.225.245.137) 46.772 ms 43.581 ms 44.306 ms
8 nycmny83gr00.bb.telus.com (204.225.245.2) 43.435 ms 47.173 ms 57.110 ms
9 g6-1.core01.jfk05.atlas.cogentco.com (154.54.10.169) 43.739 ms 47.249 ms 44.569 ms
10 v3496.mpd03.jfk02.atlas.cogentco.com (154.54.6.49) 64.820 ms 58.101 ms 44.707 ms
11 t2-2.mpd01.bos01.atlas.cogentco.com (154.54.6.1) 59.373 ms 59.840 ms 60.943 ms
12 t7-2.mpd01.ord01.atlas.cogentco.com (154.54.6.154) 64.877 ms 95.933 ms 204.520 ms
13 v3498.mpd01.ord03.atlas.cogentco.com (154.54.5.2) 267.046 ms 242.846 ms 248.398 ms
14 g1-1.core01.mke01.atlas.cogentco.com (154.54.1.165) 75.249 ms 62.569 ms 63.776 ms
15 redanvil.demac.cogentco.com (38.112.26.190) 68.791 ms 64.655 ms 60.777 ms

64 * * *

Deneb server side lag has been ridiculous lately with about 25% of shots registering and constant warping. Is some of the background/stability work that's going on addressing this issue?

Guys, posting traceroutes that are mostly "* * *" doesn't prove anything other than that some router is blocking ICMP, and thus traceroute doesn't work. [I've edited yours to trim down this thread] traceroute is really only useful if you can't actually contact a host. If you can, use ping. Let ping run for several minutes, and post the packet loss and "round-trip min/avg/max/stddev" results, if you want to give some indication of your connection quality. The stddev and packet loss figures are the most important, but are only valid with a large enough sample.

Also, indicate whether you are using the "compatibility mode" setting in the network MTU discovery option. Unfortunately the client doesn't tell you what your MTU is; that would be useful to know too.

There are several possible problems here. One is that your client's frame rate correlates with its network performance because there isn't a separate thread for networking. So knowing your FPS (/fps command) is also helpful. Comparing the result you get with /ping in the game and the avg/stddev figures you get with ping on your OS might also be helpful.

This affects the sector process as well. When there are a lot of bots or just collisions in general, the sector can start to get behind (i.e., it also has a low frame rate). When it gets behind, or just generally out of sync, it stops believing your laser fire hit your target, as you have noticed.

Ghost, none of the software work we're doing right now specifically addresses this directly but it does indirectly.

I think it's more of a problem now than it used to be because we are currently running on a "reduced" cluster (total of 5 machines instead of 8, and one of the three we're not currently using is the dual Athlon that used to be the main front-end server) while we reconfigure some servers, so we ARE doing some what I'd call IT work to improve the situation.

The other thing is that Deliverator eats a LOT of CPU for no very good reason, which slows everything else down and contributes to the problem, so we're working to get rid of it ASAP.

But there are other software architectural things we can do to improve the responsiveness of sectors (and clients!) under load and it's something I've had in the back of my mind for a long time. It's a sort of change that might make things worse stability-wise before they get better, so I've been reticent.