Bandwidth selection affecting gameplay?

[w0dk4]

You know, since some certain "wise" "developers" preferred still giving server ops the ability to tinker with nupdatespersec setting which directly affects bandwidth, the whole bandwidth patch shouldnt actually be accepted into the source code, since it relies on a hard-coded nupdatespersec setting (the standard, being 20 or so, cannot exactly remember).
Back on topic, if I remember correctly, the standard bandwidth usage with the patch would be slightly less than the old Alleg standard, however it shouldnt be that noticeable.
Crowded sectors have always been largely unplayable. Btw. I would have made the standard 56k at least, but Dogbones and other devs back in the day decided to be ignorant about new technology, making it a priority that Alleg runs on 1-bit computers by default.

Go figure.

[pkk]

QUOTE (w0dk4 @ Oct 7 2010, 06:59 PM) You know, since some certain "wise" "developers" preferred still giving server ops the ability to tinker with nupdatespersec setting which directly affects bandwidth, the whole bandwidth patch shouldnt actually be accepted into the source code, since it relies on a hard-coded nupdatespersec setting (the standard, being 20 or so, cannot exactly remember).

GPZ is currently using 20. After next restart of service it will be 10 (default) again. Maybe it will change something, but I don't think so.

[MrChaos]

Solap used the same, iirc. The issue of unplayable lag jumping started around the release of R5. Sorry for the less kind message a moment ago, not only did I take a lot of @#(! for it but I no longer can play. Im an ignorant savage on this stuff w0dk4 but please someone look into it.

MrChaos

edit: remembered my manners and I only have little clue on this entire subject

[Broodwich]

QUOTE (notjarvis @ Oct 7 2010, 03:07 AM) Oh right - This should really be in Code bugs and suggestions...

Brood have you tried playing with the Bandwidth selection stuff w0dk4 added in R5?

If not try that.

it would really, really, really, help if you actually read what i posted, then i wouldnt dislike you as much. ive had it selected on the highest amount since it came out. this is about if users are overloading the server with too high a demand for information at one time.

@pkk, when will/was gpz updated with this new rate? I played a game today on gpz that was smaller than the last one (around 15v15) and was probably worse than before. There was a period of time where i just warped 3k everywhere =\

[UncleBuck]

The game has had serious lag issues since R5, one must wonder why TF has been allowed to keep the acceleration they have, further fuxing the lag issue.

[pkk]

@Brood
If restarted the service a minute ago. Maybe something changed, maybe not. We will see results this weekend.

[notjarvis]

QUOTE (Broodwich @ Oct 8 2010, 04:23 AM) it would really, really, really, help if you actually read what i posted, then i wouldnt dislike you as much. ive had it selected on the highest amount since it came out.

Yup, I was asking if you had experimented with different settings to see if it changed your situation, as part of the bug tracking process.

QUOTE this is about if users are overloading the server with too high a demand for information at one time.[/quote]

Yup, I understood exactly what you wrote, you are making an assumption that what you have wrote is the cause of the problem with little-no evidence that is obvious to me.

If you had evidence that the server being overloaded causes the issue I would love to see it, so I know exactly where to look in the code....

[w0dk4]

I just checked, the bandwidth patch was coded with 20 updates per sec in mind:

QUOTE // w0dk4 Bandwidth Patch - removed registry-check and set tickrate to 20 so client bandwidth settings are not fooled[/quote]

I know in the code the default is 10, but the server install has always been distributed with a default registry setting of 20 which makes sense looking at the comments of former Alleg developers.

Anyways, if the issue is overloading the server with too many people having too high bandwidth settings, there is already a possibility for server admins to limit the max. available bandwidth for players:

Code: Select all

RegQueryValueEx(hKey, "MaxBandwidth", NULL, &dwType, (unsigned char*)&g.cMaxBandwidth, &cbValue);

The key is "MaxBandwidth" and you can set it to anything between 2 and 32, 2 being around ~33kbit (standard value) per sec per player and 32 being around 0.5 mbit or something like that.

[Broodwich]

the only thing i have evidence of is larger games are laggy as $#@! now and they didnt use to be. Before, sure, if everyone is in the same sector in a big game, it will get laggy. But this is happening in 15v15 games where people are spread all over the map and its STILL happening. Games used to be 30v30 every primetime and it was never this bad. The only thing i could think of because I havent really followed the development or everything that was put into r5 is the bandwidth patch. So I brought it up in general so that someone would know whether it was the bandwidth patch or if it was something else and do whatever they needed so that myself and others can join a game on a different continent and enjoy themselves somewhat instead of alt tabbing and doing something else.

[w0dk4]

QUOTE But this is happening in 15v15 games where people are spread all over the map and its STILL happening.[/quote]

That actually doesnt sound like its a problem with the bandwidth patch, but rather a general problem with server performance.
It could also be that due to the bandwidth patch, the bandwidth limit of the server is exceeded, but I doubt that.
It could also be that the bandwidth patch itself is causing a high server load, but I doubt that as well.

So, what to do. First, find out if its a bandwidth problem or not.
If it is, try to reduce MaxBandwidth.
If it is not, the server needs to be profiled to determine which part of the code is the bottleneck.