MM Server Performance

[}TCP{Wolf]

I was able to deduce that the remaining lag spikes are CPU limit spikes.

At this point I will not be able to neutralize them entirely. I have REDUCED the tickrate to 15 hoping to make this better but it won't go away. I will need to talk to Smirftsch. Also please note that this has INCREASED PING for everyone (heh giving out ping times like candy lol).

Nah seriously... When lag happens, it is now clear that the ONE CORE on which Unreal runs exclusively is maxed out in that moment - while the other 7 are idling. This is a limit of the old Unreal engine of course. If I find something else out I'll put it out there. Server is also running with 227i, if I recall correctly there were some problems with connections for some with the later versions? Not sure anymore but there was a reason we didn't upgrade... anyone remember?

[}TCP{Wolf]

.... well....

I did some 227j experiments especially since that has a 64 bit build... but... that doesn't seem to work at all with UTF. I suppose that explains the not updating thing...

[Van]

Experiment in 227j....good....I see 227i is still there.

[}TCP{Wolf]

Yup... and for now it will need to stay.

I've had a little chat with Smirftsch and while he hasn't been doing anything Unreal related for over a year himself, he was able to give me some pointers.

There were indeed more problems with 227j due to changes Dots (Marco Hulden) had made to the engine. The 227 UTeamFix map vote incompatibility was just one of them already introduced in ... i(?) - which he patched 3 years ago for me but I never released that UTF. Turns out there were more changes and Smirftsch has been telling Dots to fix them, which is what the "k" version mostly is - a bugfixed "j". But "k" isn't a final release yet... nevertheless the beta is public, so I will direct my experiments there.

The problem with the Unreal server lag spikes are indeed the monsters themselves. Turns out, hit traces en masse are a problem, especially since the engine doesn't do multi-core. Performance should be better in j and k, plus there is the 64 bit variant, and you can optimize it by using CPU core adhesion, but this will remain a one-core single thread performance issue in the end

I'll see what else I can figure out.

[Van]

Hi, I believe the MM server has been down for a few days. No big deal or rush. Thanks!

[}TCP{Wolf]

Apologies... this was probably my fault.

One of the maps I removed (DMTravincalFV) for being defective/unusable was in the regular map list and thus the server tried to load it indefinitely as it looped on the loading failure.

[}TCP{Wolf]

... oh btw I replaced the map with "DM-Taz"

[Van]

Thank you!

[}TCP{Ramses]

How many maps did you remove Wolf ? It is a long map list so must have taken some time to go through them and decide which were failures. Cheers for the cleanup

[}TCP{Wolf]

That's premature praises, Rams

I remove maps which we find bad during actual play in our sessions. I didn't go through the entire list by hand and check every one, I wouldn't have time for that ^^ This is why I need your reports on which maps are unplayable especially for MM.

I do remove them by hand from the map list cycle if they are listed there, and I physically remove the mapfile (move in a different, non-monitored directory) so when I rebuild the index for UTF's mapvote it stops appearing there. I leave dependent packages (such as textures...) since I would have to dig up the original zip file(s) to figure out which belongs to what. I was briefly entertaining the notion of asking Coco for his cache-cleaner sourcecode, as I think I could reuse some of it to improve my own toolset and actually "analyze" Unreal packages easily and display all dependent packages belonging to a map... but... yeah... these are the thoughts which pop up in between and are then quickly put back way down on the gargantuan mountain of stuff todo in life

[}TCP{Ramses]

Yeah that makes sense, a typically logical method of pruning the deadwood. I was thinking it would have taken days to work through that list