www.omnipotents.com/forums

Interesting that you don't go through cogentco.com. I assumed that was NFO's ISP in Chicago.

In my pic, I'm not sure what those routes are but it looks like I might be going through salt lake city and denver? That seems like a round about way to get from Washington to Illinois.

And that's better for me than the old server, even though old server was 45 miles away. (ISP routing would cross michigan to chicago, back to mid michigan..)

3.2 avg to router?

3.2 avg to router?

Yeah I wondered about that myself... I guess the Orbi sucks... I am wired to PC from Orbi satillite...

Hey! No redacting. How are we supposed to de-anonymize you?

FuriousRabbit wrote: ↑Sun Feb 26, 2023 2:40 am Hey! No redacting. How are we supposed to de-anonymize you?

I don't want to chance it given my opposition here...
Any news on the test server?

captainsnarf wrote: ↑Wed Feb 22, 2023 11:36 pm Landlords *is* NFO also. I was wrong. It's weird it doesn't respond to ping like HoC and Omni do, but doing net traces it is definitely NFO.

Framerate is limited by your netspeed. Omni caps the netspeed at 13600. That means 13.6Kb/s * 32 players = 435.2Kb/s bandwidth requirements. The max netspeed the game supports is 20000, so 640Kb/s. Any reasonable network should be able to handle this game. When we were testing CEONSS dedicated linux server I ran a network monitor and bandwidth usage was pretty low.

Another factor is the server tick rate. 13600 = 13.6Kb/s when the tick rate is 30. Increase the tick rate and you increase the bandwidth requirements.

Everything in the game that goes over the network has a network priority. These are all sorted by priority each tick before being sent out the network. If there's not enough bandwidth or cpu time to process everything, lower items in the priority get dropped. This is why you might see missing tank turrets or link gun beams when the server is overloaded. A detailed description of UT2004 netcode can be found here:

https://docs.google.com/document/d/1KGL ... q6LPY/edit#


The server is NOT multithreaded.

My guess is that any lag is network related. I take back my comment that it might not be on node as any modern network infrastructure should easily handle a 20 year old game. While the bandwidth might be easily accommodated, it's latency that causes lag. There's an interesting comment in that link:

Unlike replicated variables, replicated function calls are sent to the remote machine immediately when they are called, and they are always replicated regardless of bandwidth.

And later in the doc, it seems like most player movement is replicated on the server as a function call (I think nowadays this would be called a remote procecdure call (RPC)). So I wonder if high framerates and high netspeeds can indeed be causing lag. If the server is saturated with those calls, it still has to process them and decide which to drop, if any. Of course, that document seems like it was written in 1999, so I'm not sure how accurate it is regarding ut2004.

I don't think tank turrets should ever disappear. That should be a client problem. Sure they might be pointing in the wrong direction (and in my experience usually are), but shouldn't rely on the server for existence. Maybe the mods, or even the turret code, are not quite correct?

As an aside, it's interesting the way Godot implements loops. There's a physics loop, usually running at a fixed 60Hz, and then a rendering loop which can run at whatever framerate you want. It's also interesting that way ut2004 makes the server fully authoritative (which is why the RPC have to be immediate). Were I to give it a try, I would make the clients somewhat authoritative, and the server doing something more like validation.

I don't think tank turrets should ever disappear. That should be a client problem. Sure they might be pointing in the wrong direction (and in my experience usually are), but shouldn't rely on the server for existence. Maybe the mods, or even the turret code, are not quite correct?

It's not the mods. Turrets disappearing and link beams not rendering happens on stock UT2004.

With a tick rate of 30, the game has to process all script code in 32ms, per tick. If there are 32 players you get 1ms per player. That's not a lot of time even for modern hardware. Any loops happening per tick are problematic. If it were multi-threaded it would be easier.

Anonymous. wrote: ↑Sat Feb 25, 2023 7:24 amApart from the third hop (probably throttles icmp) it looks ok. In-game ping settled at 48 with an empty server just now. Think I get ~60 with more players

Sorry, unrelated to the main topic but if anyone else has spectrum, after getting a new IP I now get forcibly routed through Albany→NYC instead of Rochester→Chicago (also forcibly)... guess I'll have to spoof my old router's MAC to get a Rochester/Chicago IP. It would make too much sense if routing wasn't static and based on what IP you happen to get.
Edit: got a Rochester/Chicago IP second try... everything else is the same apart from my public-facing IP

Im Late to this topic. don't get on the forum much. but I just reloaded everything after my own crash. so...

I like this game and, in general, the group of players we have. I may seem a little dicked up at times... but it's a community! Even the malcontents are entertaining!
Not every match is even, but SOME of them are very, very close. Most nights we have one or two of those. Yes.. some players are DM and not building nodes.. and some, like me... end up dying before I cant get to the node.. but I keep at it. I think the players outnumber the DM shooters. Enyo may disagree

I'd give $50 a year for support. Probably more if the need were explained
Also... since i just did a fresh load from my old CDs.. I changed the server info in the system file, as per instructions... and I do see other servers, but not Omni. Is the server down at 8am CT? or did I miss something?