Server Help

ASSS Questions - high c2s
BlueGoku - Thu Nov 03, 2005 1:00 pm
Post subject: high c2s
Has anyone had a problem with certain people having high c2s on ASSS? I've been exchanging some ?lag/?laginfo/?info stats with grel of people who are having the problem, but so far he hasn't been able to figure it out. With the season being two weeks away, I'm hoping this problem can be resolved, otherwise we'd have no choice but to move back to subgame. We've made a whole lot of progress on ASSS and I really don't want to give up, but a lot of people are having this lag problem.

Another problem we're having that we've tried many, many fixes and tweaks for is burst downloads. Loading up bw_nolimit instead of default doesn't seem to have any effect on it, neither does playing around (though I've only tried two or three different values for them) with the net:presizedqueuepackets and net:presizedqueuethreshold settings that grel suggested.

But anyway, here are some lag stats of people with the high c2s problem. It seems to happen when they first enter the zone, but goes down slowly if they leave pub, and then goes back up if they re-enter pub.

X-oGoN: ping: s2c: 14 (11-45) c2s: 123 (0-790) ploss: s2c: 0.08 c2s: 9.93
BlueGoku> ?laginfo
X-oGoN: s2c ping: 13 14 (11-45) (reported by client)
X-oGoN: c2s ping: 60 108 (0-790) (from position pkt times)
X-oGoN: rel ping: 62 61 (0-148) (reliable ping)
X-oGoN: ploss: s2c: 0.08 c2s: 9.93 s2cwpn: 0.00
X-oGoN: reliable dups: 4.35% reliable resends: 86.48%
X-oGoN: s2c slow: 0/0 s2c fast: 0/549
BlueGoku> ?info
info: pid=8 name='X-oGoN' squad='Admirals' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=467 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=24880 encname=enc-cont-3 macid=655378608 permid=0
info: avg bw in/out=140/289 ignoringwpns=0% dropped=0
info: bwlimit=7958 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

Same guy, few minutes later:

BlueGoku> ?lag
X-oGoN: ping: s2c: 15 (9-224) c2s: 65 (0-2110) ploss: s2c: 0.09 c2s: 11.09
BlueGoku> ?laginfo
X-oGoN: s2c ping: 19 15 (9-224) (reported by client)
X-oGoN: c2s ping: 80 65 (0-2110) (from position pkt times)
X-oGoN: rel ping: 78 71 (0-1023) (reliable ping)
X-oGoN: ploss: s2c: 0.09 c2s: 11.09 s2cwpn: 0.00
X-oGoN: reliable dups: 2.13% reliable resends: 87.06%
X-oGoN: s2c slow: 0/3 s2c fast: 373/2629
BlueGoku> ?info
info: pid=8 name='X-oGoN' squad='Admirals' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=1723 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=24880 encname=enc-cont-3 macid=655378608 permid=0
info: avg bw in/out=140/295 ignoringwpns=0% dropped=0
info: bwlimit=9049 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

BlueGoku> ?info
info: pid=11 name='rockman' squad='#1 HP FAN!!' auth=y ship=8 freq=8025
info: arena=rshl client=<continuum, v. 39> res=1280x1024 onfor=1141 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=51707 encname=enc-cont-3 macid=1934017675 permid=0
info: avg bw in/out=85/2324 ignoringwpns=0% dropped=0
info: bwlimit=10000 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls
BlueGoku> ?laginfo
rockman: s2c ping: 10 7 (4-30) (reported by client)
rockman: c2s ping: 40 30 (0-130) (from position pkt times)
rockman: rel ping: 31 31 (0-187) (reliable ping)
rockman: ploss: s2c: 0.79 c2s: 24.35 s2cwpn: 0.00
rockman: reliable dups: 1.12% reliable resends: 54.26%
rockman: s2c slow: 0/77 s2c fast: 10660/116221
BlueGoku> ?lag
rockman: ping: s2c: 7 (4-30) c2s: 32 (0-130) ploss: s2c: 0.79 c2s: 24.35

BlueGoku> ?lag
Abvolt: ping: s2c: 4 (4-5) c2s: 17 (0-50) ploss: s2c: 0.00 c2s: 10.01
wicked C> i think
BlueGoku> ?laginfo
Abvolt: s2c ping: 5 4 (4-5) (reported by client)
Abvolt: c2s ping: 10 13 (0-50) (from position pkt times)
Abvolt: rel ping: 23 16 (0-1289) (reliable ping)
Abvolt: ploss: s2c: 0.00 c2s: 10.04 s2cwpn: 0.00
Abvolt: reliable dups: 12.50% reliable resends: 13.79%
Abvolt: s2c slow: 0/0 s2c fast: 0/0
BlueGoku> ?info
info: pid=38 name='Abvolt' squad='Illuminati' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1152x864 onfor=84 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=56069 encname=enc-cont-3 macid=640619740 permid=0
info: avg bw in/out=90/225 ignoringwpns=0% dropped=0
info: bwlimit=10000 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

BlueGoku> ?lag
Carlito Brigante: ping: s2c: 12 (11-13) c2s: 63 (0-110) ploss: s2c: 0.12 c2s: 13.41
BlueGoku> ?laginfo
Carlito Brigante: s2c ping: 14 12 (11-17) (reported by client)
Carlito Brigante: c2s ping: 80 66 (0-110) (from position pkt times)
Carlito Brigante: rel ping: 62 61 (0-210) (reliable ping)
Carlito Brigante: ploss: s2c: 0.12 c2s: 13.41 s2cwpn: 0.00
Carlito Brigante: reliable dups: 0.00% reliable resends: 47.25%
Carlito Brigante: s2c slow: 0/0 s2c fast: 3400/3920
:: Save by xfx!
BlueGoku> ?info
info: pid=64 name='Carlito Brigante' squad='Admirals' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1600x1200 onfor=135 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=30725 encname=enc-cont-3 macid=615195991 permid=0
info: avg bw in/out=201/1344 ignoringwpns=0% dropped=0
info: bwlimit=9991 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 21 (0-60) ploss: s2c: 0.12 c2s: 5.70
BlueGoku> ?laginfo
Resonant: s2c ping: 5 4 (3-5) (reported by client)
Resonant: c2s ping: 40 26 (0-60) (from position pkt times)
Resonant: rel ping: 31 23 (0-31) (reliable ping)
Resonant: ploss: s2c: 0.12 c2s: 5.70 s2cwpn: 0.00
Resonant: reliable dups: 7.69% reliable resends: 9.11%
Resonant: s2c slow: 0/0 s2c fast: 904/0
BlueGoku> ?info
info: pid=27 name='Resonant' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=53 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=8181 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=184/1211 ignoringwpns=0% dropped=0
info: bwlimit=10000 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

Same guy, with BW_nolimit loaded up:

BlueGoku> ?lag
Resonant: ping: s2c: 5 (3-9) c2s: 18 (0-70) ploss: s2c: 0.62 c2s: 9.63
BlueGoku> ?laginfo
Resonant: s2c ping: 6 5 (3-9) (reported by client)
Resonant: c2s ping: 20 18 (0-70) (from position pkt times)
Resonant: rel ping: 23 16 (0-62) (reliable ping)
Resonant: ploss: s2c: 0.60 c2s: 9.57 s2cwpn: 0.00
Resonant: reliable dups: 0.00% reliable resends: 18.52%
Resonant: s2c slow: 0/0 s2c fast: 6008/12455
BlueGoku> ?info
info: pid=54 name='Resonant' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=201 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=53234 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=115/2190 ignoringwpns=0% dropped=0
info: bwlimit=(no limit)
info: lag too high to play
info: lag too high to carry flags or balls

Edit: One more I just took right now:

BlueGoku> ?lag
Leafy: ping: s2c: 11 (6-25) c2s: 76 (0-110) ploss: s2c: 0.81 c2s: 43.56
BlueGoku> ?laginfo
Leafy: s2c ping: 16 11 (6-25) (reported by client)
Leafy: c2s ping: 50 72 (0-110) (from position pkt times)
Leafy: rel ping: 55 52 (0-101) (reliable ping)
Leafy: ploss: s2c: 0.81 c2s: 43.56 s2cwpn: 0.00
Leafy: reliable dups: 0.00% reliable resends: 102.28%
Leafy: s2c slow: 0/0 s2c fast: 0/0
BlueGoku> ?info
info: pid=8 name='Leafy' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=259 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=44287 encname=enc-cont-3 macid=10790699 permid=0
info: avg bw in/out=94/281 ignoringwpns=0% dropped=0
info: bwlimit=3114 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

Any help would be appreciated.
Mine GO BOOM - Thu Nov 03, 2005 1:42 pm
Post subject:
I guess a way to test to see if this is actual packet loss would be to build a little proxy. Something in which the client connects to locally, and forwards all the packets to the server, while keeping a record of them all. Then, on ASSS, write a module/hack the net code/create a proxy to record all packets from this user. On either end, have these modules/proxies talk via TCP and exchange all packet information sent from the client, and what was actually received by ASSS.

This would show which packets are being dropped, or may show that ASSS is incorrectly counting the packets.

To make it simplier, all you really need is a proxy on both sides, the server and the client. Have the proxies record the packets in an identical way (only need c2s), and use GNU diff on the two logs.
Dr Brain - Thu Nov 03, 2005 3:28 pm
Post subject:
We've been using ASSS for a long while and never seen that happen.
Grelminar - Fri Nov 04, 2005 1:13 am
Post subject:
I think it's likely the packets really are getting lost, although I'd love to set up a proxy like MGB described to see what exactly is getting lost (I had a similar idea recently). The logic for c2s packetloss is pretty simple: count how many packets come in, and when a time sync packet comes in, it contains a count of how many the client sent, so you can calculate the total percent lost.

High reliable resends is consistent with high c2s ploss: if the c2s acks get dropped, the packets have to be resent. Although, in that case you'd also expect some c2s reliable packets themselves to get lost, and have to be resent, which would mean a nonzero reliable dups number. The people with 0% dups but high resends are very confusing. The only explanation I can come up with is that they're simply not sending any reliable packets (chat, ship/freq changes, etc.).

Besides server race conditions, which shouldn't really matter here, the only logic error I can imagine is that the client and server aren't counting the same thing. Perhaps the client is counting multiple packets in a grouped packet as separate packets? But if that was true, everyone's ploss numbers would be off, not just some people's. And if the client reset its count periodically or something, we'd be getting negative numbers, not high ones.

One guess would be that the clients are just sending too much for their pipes. What's your Misc:SendPositionDelay? Is Misc:ExtraPositionData on? What about Misc:SpecSeeExtra, SpecSeeEnergy, and SeeEnergy? Is anyone with the "seeepd" capability speccing these people?

You claim that the ploss problem happens while people are in pub, and not while they're in other arenas. That suggests something specific to your pub arena. What are the differences in settings between pub and the other arenas?
BlueGoku - Fri Nov 04, 2005 11:47 am
Post subject:
Misc:ExtraPositionData=0
SendPositionDelay=5
SeeEnergy=SEE_NONE
SpecSeeEnergy=SEE_NONE
SpecSeeExtra=SEE_NONE

No one with the seeepd capability is speccing these people because they can't actually get into the game once their lag registers. Which is weird, because when they first enter and their lag hasn't registered, they look perfectly normal.

Also, just a quick addon to my comment about it only happening in pub: Arnk and I ran a quick test yesterday and asked two people who are having the problem to re-enter and sit in pub. They both had equally high c2s and it was not going down. We then asked them to re-enter but quickly go into a generic arena that had basically no (hockey) modules loaded. Their ploss was still relatively high (read: around 10 or so, compared to the 20-40 they got in pub), but it was going down fairly fast. Eventually it had reached well below our lag limits.

There's only really one difference between our pub and other arenas: we use dual rinks in pub. Meaning there are two rinks in the same arena so 24 people can play instead of the 12 in any other arena. The weird thing is, the people having the ploss issue have high ploss in pub regardless whether there are 24 people playing and a few speccing, or if there are 10 spectators. We've also slightly edited balls.c to allow for two balls to be used, one in each rink. The rinks are fairly far away from eachother, so AW on one rink won't reach the other, and so people playing in one rink won't see the other on radar and get position packets. Other than that, the settings are the exact same.
Mine GO BOOM - Fri Nov 04, 2005 12:42 pm
Post subject:
BlueGoku wrote:
SendPositionDelay=5

Holy crap! Thats twice as fast as it should be. There is probably why you are getting huge c2s drops, as you are sending positions sometimes more often that Continuum will calculate a new position (GetTickCount sucks). This may cause either routers somewhere to drop this packet thinking it is a duplicate (aka, shitty home routers), Windows may just do this for the hell of it, or Continuum may just not send the packet but still count it into it's tally.

SendPositionDelay should be 10. Anything less is overkill. In zones with lots and lots of weapons flying around, I recommend pushing it upto 15. But you never need to drop it below 10 unless you are running 100% on a LAN.
BlueGoku - Fri Nov 04, 2005 1:19 pm
Post subject:
Thanks for the quick reply. Just set it to 10, waiting on someone with the c2s problem to log on.
BlueGoku - Fri Nov 04, 2005 8:46 pm
Post subject:
One of the people that is having the c2s problem was on today and apparently he's still having the issue. What's weird is that he says when he resets his router his ploss becomes normal, though he has to do it every 45 minutes or so. Here are his lag stats just a bit after he reset his router:

BlueGoku> ?lag
Thrill HZ: ping: s2c: 3 (3-6) c2s: 25 (0-130) ploss: s2c: 0.02 c2s: 0.02
BlueGoku> ?laginfo
Thrill HZ: s2c ping: 4 3 (3-6) (reported by client)
Thrill HZ: c2s ping: 10 18 (0-130) (from position pkt times)
Thrill HZ: rel ping: 23 16 (0-398) (reliable ping)
Thrill HZ: ploss: s2c: 0.02 c2s: 0.02 s2cwpn: 0.00
Thrill HZ: reliable dups: 6.72% reliable resends: 6.55%
Thrill HZ: s2c slow: 0/0 s2c fast: 6103/49271
BlueGoku> ?info
info: pid=1 name='Thrill HZ' squad='Phasers' auth=y ship=2 freq=1
info: arena=vets client=<continuum, v. 39> res=1280x1024 onfor=683 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=640 encname=enc-cont-3 macid=391859770 permid=0
info: avg bw in/out=179/1595 ignoringwpns=0% dropped=0
info: bwlimit=10000 bytes/s

After this, I found another person who had really high c2s before. I asked him to first re-enter and stay in pub and checked his lag.

BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 3 (0-20) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 19 (0-60) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 25 (0-60) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 22 (0-60) ploss: s2c: 0.38 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 19 (0-60) ploss: s2c: 0.42 c2s: 4.60
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 20 (0-60) ploss: s2c: 0.42 c2s: 4.60
BlueGoku> ?laginfo
Resonant: s2c ping: 0 0 (0-0) (reported by client)
Resonant: c2s ping: 40 20 (0-60) (from position pkt times)
Resonant: rel ping: 15 15 (0-109) (reliable ping)
Resonant: ploss: s2c: 0.18 c2s: 4.91 s2cwpn: 0.00
Resonant: reliable dups: 16.67% reliable resends: 8.75%
Resonant: s2c slow: 0/0 s2c fast: 0/0
BlueGoku> ?info
info: pid=22 name='Resonant' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=40 connectas=<default>
info: ip=xx.xxx.xxx.xxx port=24564 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=202/983 ignoringwpns=0% dropped=0
info: bwlimit=8812 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

BlueGoku> is your c2s now better than it was yesterday?

BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-6) c2s: 16 (0-60) ploss: s2c: 0.09 c2s: 5.87
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-6) c2s: 16 (0-60) ploss: s2c: 0.09 c2s: 5.98

Resonant> yeah, i remember it being up to 9 yesterday

BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-6) c2s: 20 (0-60) ploss: s2c: 0.13 c2s: 6.68
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-6) c2s: 22 (0-60) ploss: s2c: 0.13 c2s: 6.68
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-6) c2s: 25 (0-60) ploss: s2c: 0.13 c2s: 6.72
BlueGoku> ?lag

He re-entered once again.

Resonant: ping: s2c: 0 (0-0) c2s: 13 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 11 (0-50) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 16 (0-50) ploss: s2c: 0.73 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 7 (0-50) ploss: s2c: 0.44 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 18 (0-50) ploss: s2c: 0.36 c2s: 4.82
BlueGoku> ?laginfo
Resonant: s2c ping: 0 0 (0-0) (reported by client)
Resonant: c2s ping: 30 18 (0-50) (from position pkt times)
Resonant: rel ping: 23 16 (0-117) (reliable ping)
Resonant: ploss: s2c: 0.30 c2s: 5.02 s2cwpn: 0.00
Resonant: reliable dups: 7.69% reliable resends: 9.55%
Resonant: s2c slow: 0/0 s2c fast: 0/0
BlueGoku> ?info
info: pid=16 name='Resonant' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=39 connectas=<default>
info: ip=xx.xxx.xx.xx port=4598 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=211/873 ignoringwpns=0% dropped=0
info: bwlimit=8720 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 13 (0-50) ploss: s2c: 0.35 c2s: 5.15
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 19 (0-50) ploss: s2c: 0.35 c2s: 5.15
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 9 (0-50) ploss: s2c: 0.23 c2s: 5.08
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 7 (0-50) ploss: s2c: 0.23 c2s: 5.08
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 20 (0-50) ploss: s2c: 0.14 c2s: 4.93

At this point I told him to re-enter but go straight into a generic arena.

BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 14 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 3 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 4 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 0 (0-0) c2s: 26 (0-50) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 11 (0-50) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 17 (0-50) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 15 (0-50) ploss: s2c: 0.00 c2s: 0.65
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 10 (0-50) ploss: s2c: 0.00 c2s: 0.59
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 12 (0-50) ploss: s2c: 0.00 c2s: 0.59
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 15 (0-50) ploss: s2c: 0.00 c2s: 0.48
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 20 (0-50) ploss: s2c: 0.00 c2s: 0.47
BlueGoku> ?laginfo
Resonant: s2c ping: 4 4 (3-5) (reported by client)
Resonant: c2s ping: 30 21 (0-50) (from position pkt times)
Resonant: rel ping: 16 15 (0-31) (reliable ping)
Resonant: ploss: s2c: 0.00 c2s: 0.47 s2cwpn: 0.00
Resonant: reliable dups: 3.03% reliable resends: 11.40%
Resonant: s2c slow: 0/0 s2c fast: 76/0
BlueGoku> ?info
info: pid=22 name='Resonant' squad='' auth=y ship=2 freq=0
info: arena=asdf client=<continuum, v. 39> res=1280x1024 onfor=83 connectas=<default>
info: ip=xxx.xxx.xxx.xxx port=7670 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=329/149 ignoringwpns=0% dropped=0
info: bwlimit=4919 bytes/s
BlueGoku> ?lag
Resonant: ping: s2c: 4 (3-5) c2s: 21 (0-50) ploss: s2c: 0.00 c2s: 0.41

I then asked him to try resetting his router and meeting me back in pub.

Resonant: ping: s2c: 0 (0-0) c2s: 16 (0-60) ploss: s2c: 0.66 c2s: 5.19
BlueGoku> ?laginfo
Resonant: s2c ping: 0 0 (0-0) (reported by client)
Resonant: c2s ping: 10 15 (0-60) (from position pkt times)
Resonant: rel ping: 15 15 (0-133) (reliable ping)
Resonant: ploss: s2c: 0.46 c2s: 5.45 s2cwpn: 0.00
Resonant: reliable dups: 8.33% reliable resends: 8.97%
Resonant: s2c slow: 0/0 s2c fast: 0/0
BlueGoku> ?info
info: pid=58 name='Resonant' squad='' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1280x1024 onfor=43 connectas=<default>
info: ip=xx.xx.xx.xx port=48623 encname=enc-cont-3 macid=1394000970 permid=0
info: avg bw in/out=157/666 ignoringwpns=0% dropped=0
info: bwlimit=8860 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls

Guess resetting the router only works for thrill.

So the setting did help out, but people are still having the issue.

One other thing I wanted to ask is if objon's and objoff's could be a possible cause? We have a scoreboard in pub but not in the generic arenas. I know a few years ago when I had my old computer/connection I used to get DC'd upon entrance, and the sysop at the time figured out that if he made the scoreboard optional, I wouldn't get d/c'd anymore. I'll try making the scoreboard optional tonight and post if it does anything.

Edit: I made the scoreboard optional and had someone with high c2s re-enter pub. It didn't seem to have any effect, since his lag stats were practically the same even when he turned off optional level graphics and sound off:

BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 8 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 30 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 12 (0-40) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 10 (4-43) c2s: 10 (0-40) ploss: s2c: 0.71 c2s: 7.22
BlueGoku> ?lag
Abvolt: ping: s2c: 10 (4-43) c2s: 11 (0-40) ploss: s2c: 0.71 c2s: 7.22
BlueGoku> ?lag
Abvolt: ping: s2c: 10 (4-43) c2s: 12 (0-40) ploss: s2c: 0.73 c2s: 7.74
BlueGoku> ?lag
Abvolt: ping: s2c: 10 (4-43) c2s: 13 (0-40) ploss: s2c: 0.73 c2s: 7.74

After turning off optional level graphics/sound:

Abvolt: ping: s2c: 0 (0-0) c2s: 9 (0-50) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 31 (0-50) ploss: s2c: 0.27 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 22 (0-50) ploss: s2c: 0.23 c2s: 8.78
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 21 (0-50) ploss: s2c: 0.23 c2s: 8.78
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 22 (0-50) ploss: s2c: 0.36 c2s: 9.73
BlueGoku> ?lag
Abvolt: ping: s2c: 4 (4-6) c2s: 18 (0-50) ploss: s2c: 0.07 c2s: 10.41
BlueGoku> ?laginfo
Abvolt: s2c ping: 4 4 (4-6) (reported by client)
Abvolt: c2s ping: 30 17 (0-50) (from position pkt times)
Abvolt: rel ping: 23 23 (0-39) (reliable ping)
Abvolt: ploss: s2c: 0.07 c2s: 10.41 s2cwpn: 0.00
Abvolt: reliable dups: 17.65% reliable resends: 16.62%
Abvolt: s2c slow: 0/0 s2c fast: 1410/0
BlueGoku> ?info
info: pid=7 name='Abvolt' squad='Illuminati' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1152x864 onfor=65 connectas=<default>
info: ip=xxx.xx.xx.xx port=46085 encname=enc-cont-3 macid=640619740 permid=0
info: avg bw in/out=168/714 ignoringwpns=0% dropped=0
info: bwlimit=9979 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 17 (0-60) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 10 (0-60) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 10 (0-60) ploss: s2c: 0.00 c2s: 0.00
BlueGoku> ?lag
Abvolt: ping: s2c: 0 (0-0) c2s: 15 (0-60) ploss: s2c: 0.14 c2s: 11.00
BlueGoku> ?lag
Abvolt: ping: s2c: 4 (4-5) c2s: 16 (0-60) ploss: s2c: 7.85 c2s: 11.57
BlueGoku> ?laginfo
Abvolt: s2c ping: 5 4 (4-5) (reported by client)
Abvolt: c2s ping: 10 15 (0-60) (from position pkt times)
Abvolt: rel ping: 31 23 (0-39) (reliable ping)
Abvolt: ploss: s2c: 0.31 c2s: 20.67 s2cwpn: 0.00
Abvolt: reliable dups: 6.67% reliable resends: 46.00%
Abvolt: s2c slow: 49/0 s2c fast: 698/0
BlueGoku> ?info
info: pid=40 name='Abvolt' squad='Illuminati' auth=y ship=8 freq=8025
info: arena=0 client=<continuum, v. 39> res=1152x864 onfor=56 connectas=<default>
info: ip=xx.xxx.xxx.xx port=47109 encname=enc-cont-3 macid=640619740 permid=0
info: avg bw in/out=167/588 ignoringwpns=0% dropped=0
info: bwlimit=6914 bytes/s
info: lag too high to play
info: lag too high to carry flags or balls
Mine GO BOOM - Sat Nov 05, 2005 1:29 am
Post subject:
Run a diff between your public arena and a subarena. Or try copying the public arena's setting to some subarena and seeing how that runs.

Another idea is to create a new public arena with ASSS and have him sit in there (aka, empty public arena). The more random things you try, the better chance of finding something weird.

Have you tried using Subspace yet?
Goldeye - Sun Nov 06, 2005 2:53 pm
Post subject:
Our scoreboard could be causing the problem. There was a problem (just fixed) where it might have been sending dups.
It's not up in the zone yet till we make sure it runs elsewhere.
BlueGoku - Sun Nov 06, 2005 7:23 pm
Post subject:
Any ideas about the slow downloading speed?

I've added the following to my global.conf a couple of weeks ago as per Grel's suggestions and made some various tweaks but noticed no overall change in the download speeds. Any ideas?

Net:PriLimit1=15
Net:PriLimit2=45
net:presizedqueuepackets = 10
net:presizedqueuethreshold = 3
net:limitminimum = 2500
net:sendatonce = 30
net:limitscale = 300
net:limitmaximum = 10000
BlueGoku - Sun Nov 06, 2005 8:08 pm
Post subject:
Sorry for the double post, but there was one other thing I wanted to ask. What exactly does this message mean: "You have been disconnected because of lag (too many reliable retries)." A few players have told me they sometimes get that disconnect message upon entering the zone, and I've also experienced it myself when tabbing in every once in a while.
Grelminar - Sun Nov 06, 2005 11:23 pm
Post subject:
asss isn't (yet?) smart enough to behave differently when you're in "playing" mode versus "downloading" mode. If you want fast downloads, I can suggest tweaks that will help, but they may cause other undesirable things.

Just to see how fast downloads can get, you could try: presizedqueuepackets=50, presizedqueuethreshold=5, sendatonce=50, limitscale=512 (default), limitmaximum=102400. And perhaps also reduce prilimit2 by 15 and add 15 to prilimit3 (downloads happen at level 3).

There's probably some middle point between where you are now, and settings optimized for fast downloads, that will put downloads at a reasonable speed without causing other bad stuff. I don't know of a good way to find it, though.

It would also help if asss could actually use different settings during downloads and during gameplay, but that's a much more complex change.
Grelminar - Sun Nov 06, 2005 11:31 pm
Post subject:
It means asss sent a particular reliable packet 15 times without getting an acknowledgement. Perhaps all 15 got lost s2c, or all 15 acks got lost c2s, or some combination of the above. Or more likely, the packets got to the other side, but the client was busy doing other things (changing the video mode) and didn't ack them in time. The actual timeout is adjusted based on average latency, so I can't give a specific number.

You could try Net:MaxRetries=20, or 25, or whatever you want, but of course making that number higher means it'll take longer for the server to disconnect people who really lost connectivity.
BlueGoku - Sun Nov 06, 2005 11:59 pm
Post subject:
I will try those tweaks and let you know how they work out.

Also, I'd rather not change our prilimit settings since those are optimized so we could have the least amount of weird ball phase warps.
BlueGoku - Mon Nov 07, 2005 1:35 am
Post subject:
Also, we seem to still be having the powerball phase warp problem. We've tried many, many things, and although it happens less with the prilimits you suggested before, it still happens often enough to interfere with the actual game play.

I know this may be asking too much, and you've helped us out so much already, but is there any way you can check through balls.c again to see if any funky stuff is going on with the code? To refresh your mind, what happens is Player A passes the puck and the sound is heard, though he still has the puck on everyone's screen (including his) and suddenly the puck warps to where where would've been if it was shot properly. As well as when someone is passed the puck but it appears to phase right through, then suddenly it reappears and the person it phased through is holding it.

What we've done so far is set the soccer:sendtime to 25, which lowers the time it takes for the puck to re-appear, but it doesn't really help, since HZ is so fast paced even if it were to phase for a split second it would throw players off.

Again, any help would be appreciated.
Grelminar - Mon Nov 07, 2005 2:50 am
Post subject:
This is a really crazy idea, but perhaps the time in outgoing ball packets is getting screwed up. What if you changed line 675 in balls.c to "bd->time = current_ticks() - 5;"? Ideally, I think you'd want something like "if fb->time looks reasonable, use it, otherwise use (current_ticks() - c2s latency)". But I'm curious what would happen if it just used current_ticks all the time. I suspect it will be a disaster, but it might provide useful information.

Otherwise, I guess we should try to get the server to log detailed information about pickups and passes, especially timing info, and see if anything jumps out of that.
BlueGoku - Wed Nov 09, 2005 2:29 pm
Post subject:
What was the original line you want us to change to "bd->time = current_ticks() - 5;"? We're using a modified version of balls.c because vampz made a few changes to it, such as having the ball bounce back out if it's shot within the crease.

EDIT: Did you mean "bd->time = 0;" to "bd->time = current_ticks() - 5;"?
Grelminar - Thu Nov 10, 2005 3:11 am
Post subject:
In PFireBall, replace "bd->time = fb->time;" with what I said. Like I said, I don't know exactly how it would work out, and it could make the ball behave much worse.
BlueGoku - Fri Nov 11, 2005 8:57 pm
Post subject:
We didn't make that change, but Arnk changed the pickup function to have it set the time to current_ticks (it was 0) and it seems to have fixed the problem, which is awesome.

Unfortunately though, the c2s issue still seems to be happening, Goldeye's fix didn't help.
Grelminar - Sat Nov 12, 2005 3:49 am
Post subject:
What?! I have subgame packet captures (from 2001, even) that clearly show that the time on picked-up balls is zero. And why would changing the pickup function affect something that happens after firing? What happens if you change it to "bp->time" instead of current_ticks()? That makes slightly more sense to me.

One difference I do note is that subgame left xspeed and yspeed alone from before the pickup, but asss sets them to zero. But I can't believe that makes a difference.

Hmm.... Could it be that subgame sends a ball packet with time 0 to the person holding the ball, but one with a real time to everyone else? That sounds very unlikely to me, since it's extra work for no apparent reason.
BlueGoku - Sat Nov 12, 2005 4:12 am
Post subject:
Well, it does make sense because the more rampant phase warp was the delayed pickup one, where a player will catch the ball but it will supposedly phase through, and then a second later it would re-appear and the player would have it. That's only happened twice or three times that I've seen since the change went live, but the phase warp where the ball is shot but the player still has it seems to still be happening sometimes. I think making the same change for the firing function should fix that one.
Anonymous - Fri Nov 18, 2005 1:04 pm
Post subject:
Turns out the problem was in our module that wrapped around objects. Sending objon's/offs for things that were already in the proper state. Not sure how this turned into the ploss though.
Cyan~Fire - Fri Nov 18, 2005 5:34 pm
Post subject:
Maybe Cont never acknowledged the sorta-repeated packets?
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group