Some of us (most do not) are experiencing big lag problems on XS4All. When more than 8-10 people
join ping will usually double or tripple. And if that wasn't enough it will cycle from 40ms to 100+ randomly
and even though Mensa still wants me to join them for tea at tuesdays the fun, accurate fragging in
the presence of the usual quad whore is just not feasible. Admins have acknowledged the problem, but I
guess they don't know where to start looking/fixing.

It's probably not a server problem per. se, but rather points to a local network problem. And for all you
armchair network jokeys out there: the problem is presistent even on different PC's, different ISPs and
different Qizmos. BUT there is no PL. I will admit, based on 15 years in the business, that the cause of
the problem eludes me.

Perhaps someone here might have a clue? At this point, even the lamest of the lame suggestion disguised
as a lame village idiot lamer is very much welcomed.

/PaRa

cpu usage to high?

It's because the sv_maxrate is too low IMO, you can see this on your netgraph in the form of yellow lines.
Of course, it might be that if this were increased, the cpu couldn't handle it when there's a lot of clients connected, I don't know.

You may be right. Why didn't I think of that. gah

Ruskie: Good suggestion, but can't be CPU or everyone would be affected.


/PaRa

For those interested, the server is a 1.8GHz 4-way SMP Xeon setup. Right now with 10 persons on FFA, the CPU usage is somewhere between 10% and 15% (and for the Windows users out there, this means 10 to 15 percent of a single CPU).

But as with most other problems I encounter, it is most likely an Ezcake bug. Have you tried with a different client?

I was _so_ close to posting that picture of you eating a big portion of cake

Do you know what the sv_maxrate setting is? I know a couple of years ago it was too low, I asked Flepser to increase it and once at 50000 there was no problem. Maybe it's gone back again.
Everything I've seen when looking at this lag problem points to insufficient maxrate..... if you monitor r_netstats in your client during big fights in open areas you can see that once the incoming data rate exceeds ~10k you start dropping packets and ping goes up.

One more thing for you (slightly OT) - I think there's a bug in FOD ffa that I got rxr to fix in ktpro many years ago. Quad grenade damage isn't being calculated correctly, there are some occasions where the splash damage is applied to the shooter first, killing him, and then his target only takes single damage. On maps like e1m2 it should be impossible to survive a direct quad grenade hit.

If you watch r_netgraph, you'll see yellow bars when the server's sv_maxrate (or your client's rate setting) is too low.
You'll see red bars (real actual packetloss) when *other people's* rate is too high, in which case a higher sv_maxrate will not help, but will hinder instead.

So are the bars red or yellow?

(this is assuming your client hasn't got modified behaviour of this stuff)

They are yellow and the rate indeed seems to be capped at 10k.

A couple of years ago maxclients was 28, now it is 16.

sv_maxrate is 10000.

Did you try with a different client?


Seeing as this only seems to happen to a select few, I'd say client bug. Or maybe you've got cl_nodelta set to 1?


The QW gamecode is full of bugs, unfortunately. If I remember it, I'll look at it soon.

cl_nodelta is 0. The reason it 'only seems to happen to a select few' is because the server sends different amounts of data to different players at different times. A player who is camping a sideroom on ultrav won't be seeing that much action. If you've got say, 6+ players all shooting in the main atrium, then at least some of those players will be receiving (rate permitting) much more data. Some players probably don't even notice it, because in the situations where you are rate limited, you will in all likelihood be in a big fight and concentrating on that rather than checking your netgraph. If it's a client bug, then it's in qwcl, mqwcl, zquake, fuhquake, ezquake at least.

10000 maxrate is too low for 16 players. In fact some years ago I proved that under some circumstances even ONE player can make the rate requirement exceed 10000 (continually shooting SNG down the really long corridor on e4m3 from one end to the other; connect to a server - even on your LAN so long as it's not a loopback - limit your rate to 10000 and try it for yourself). The client should be irrelevant (barring any additional compression that may have been added to both server and client), it's just an inherent limitation that if the server needs to send more than 10000 bytes of data to a given player, yet it is artificially limited, then this causes a problem.

FFA servers suffer the most from low maxrate settings because they usually have high maxclients and run dmm3. This means that, especially on smaller open maps with many weapons like fribweb1 (powder keg) you get huge fights with a much higher amount of data being sent to some players than usual. For duel/2v2 it's not such a big deal, and indeed because 4on4 is played dmm1 on larger maps it's not all that common to need more than 10000 (although of course it should be set higher for optimum conditions, server cpu allowing).

Personally I would have thought that 25000 is the absolute bare minimum (preferably much higher) that should be used on an FFA server like XS4all which has small action packed maps and high maxclients (again, you have to be wary of whether the server can handle it, of course). The irony is that the other xs4all servers (clanwars, allround etc) have half the maxclients, yet maxrate is 5 times higher!

Paradizer, the guy who started the thread, told me on the server that he indeed had cl_nodelta set to 1, and that setting it to 0 fixed the problems for him. So at least some of the select few is due to cl_nodelta being set to 1.

Nonetheless, last night with 16 persons on dm4 I did notice the occasional choked network packet, so I've increased sv_maxrate to 20000


All I wanted to know was if you had tried it in another client. Most of the problems people report to me turn out to be problems with Ezquake.

One player can waste 27kB/s with his client only on amphi map by shooting nails through the map with nailgun (not sng) at 77fps. HangTime's suggestion of 25k+ rate is really good suggestion. Hence rate 50k on my admin'ed servers, even if the players can't hit that high bw, it's still not wasted since server won't send excessive amounts of data anyway.

Confirmed! Neither client nor server was to blame, but rather my config. Rate was OK, cl_nodelta was NOT. I hereby officially clame the title of incompetent whining laaemoaah!


/PaRa

sv_nailhack 0 used to the default. And for good reason. And now you know why.

Yes I think it's important to point out that setting sv_maxrate 50000 won't suddenly make the server use 5x the bandwidth/cpu of 10000 (in case that is of concern to any admins), it just sets the MAX rate that could be used afterall. It just means that there is some extra headroom for the odd circumstance where some client(s) needs to use a bit extra.

Essentially servers should really run as high as they can get away with rather than just choosing some arbitrary low value (although it's probably worth imposing some kind of realistic limit around 50k to avoid any potential exploits).

Spike, can you elaborate on that? Is nailhack bad for non-qizmo users?

Bigfoot: thanks for listening

Nah, it won't use extra cpu with that low figures. Besides, NICs have their own cpus to be used unless they are pieces of shit from the early 90's. Also with the exploits, there isn't really any worth mentioning since clients have trouble getting over 50k rate with other pings than 13ms.

nailhack does indeed increase traffic usage if you're not using Qizmo compression. The reason it makes sense to use nailhack even without Qizmo is that it lets you distingish sng and ng spikes visually, and their movement is smoother.

with nailhack disabled (that is, logically, if you hexedit the exe so it doesn't detect its a nail), a nail is sent using 13 bytes when it is first seen (more of these with higher latency), dropping to 8 bytes in the following packets. Nailhack uses a flat 6 bytes (7 in an mvd). So I guess its not that significant in the long corridor situation, but if you're spamming nails around dm4 with a 50ms ping, then you've probably halved your rate.

Qizmo presumably compresses by predicting based upon velocity. Which requires something that uniquely identifies each nail which is why they're the ones that first advertised how to hack the quakeworld server to stop it from recognising nails as special. Which means sv_nailhack 1 disables the original hack.
Nailhack is probably more of a per-client setting really.

This is way to complicated:

Is it possible to fix the problem at hand or is it unsure yet what the cause is? Because apparantly one setting worked for one person and a different setting, might, work for others.

Uh, no?

Already stated: Too low rate for big carnivals, use 50000 serverside just to be sure. Also cl_nodelta 0 should be used clientside.

all the technical jibberish!

OK, I'll bite. Why 50000? Why not 60000?

Because it looks nicer.

Also because I haven't been able to achieve much more than 30kB/s traffic with clients at 77fps (150fps, however, is different, but do we have high-fps enabled servers anymore?) when lots of players are jumping around and shooting. I also mentioned something about ping and download rate a bit above, but even that is irrelevant these days thanks to chunked downloading.

Perhaps it would be time to re-test rates and see how much bw can be used by using 8 or so players shooting nails on some very big map with lots of visibility.

OK, but surely 100000 looks nicer than 50000? 10000 does too, BTW.


So at the, according to you, nice looking rate, 2 players is too much?

10000000 looks even nicer. BTW, while you're digging my replies, why don't you read ALL of them and quote the important ones too? Those that actually tell something else than just one player shooting nails on amphi?

Nah, it looks like some number a child makes up when he wants to make up a biiiiiiiiiiig number.


You mean like this one?


Where to start, where to start...

Well, first of all, please let me know how you manage to do extra processing without actually doing extra processing.

Next you can let me know which CPU there is on your NIC. Surely your NIC isn't a piece of shit from the early nineties, right?

And now the last part of that post. Since you're mentioning a data rate in relation to ping time, I assume you're talking about oldstyle QW downloads (are you guys still using those?), in which case both FTE and MVDSV have a separate cvar dictating the maximum rate during downloads, which is usually relatively high.

Now, as for the potential exploits mentioned by HangTime, while they probably wouldn't be of much or any concern to anyone, it isn't very hard to make a QW server use *A LOT* of bandwidth if you were so inclined. And doing so would have absolutely sod all to do with whatever ping time the client has.

Yawn.


Oh the amount of quibbling.

But well, I'll humour you, this one time. Most of the newer (if not all) network cards have onboard processor (yes, by CPU I really meant that) that can offload checksumming and other protocol processing from the computer's main CPU. Earlier Realtek el-cheapo cards weren't like this and they used a lot more of CPU resources than a NIC with proper onboard processor, like 3c905tx or similar.

Sarcastically, a company called "bigfoot networks" has released two "killer NICs" that can even run software on their CPU's, and these should provide lower ping-times to gamers. click for more info


I know I am not, who knows if someone does, hopefully not.