UT2004 related discussions
User avatar
Posts: 80
Joined: Mon 1. Aug 2011, 08:18
Description: UT 2004 cunt player
Location: United Kingdom


Postby smalltown » Sat 10. Sep 2016, 17:50

Just a suggestion if the netspeed can be increased to 10000 or 12000 (currently at 9400). I want to see if the there is any change in the channels and packets received/sent, if there is still some packet losses when playing...btw whats RPC?
:firedevil: :firedevil: STOMBOTOWN :firedevil: :firedevil: :machinegun: :cool2cool: :yoman:

User avatar
Posts: 1060
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece


Postby Pegasus » Sat 10. Sep 2016, 19:17

While I must admit that Netspeed is an aspect of the game I'm still not satisfactorily well versed in even after many years of looking under UT's hood, here's some insight my current understanding allows me to (relatively safely) provide on the subject that might help with your (and others') concerns.

Netspeed: the amount of data the client/server states it prefers (or can afford) to transmit per sec (in bytes).

1. Transmitted data flows in packets, whose size can only be of binary orders of magnitude, e.g. 64, 128, 256, 512, etc. As long as it's below 1024 bytes and no stringent MTU settings are in place for a user's (cable/xDSL) con, data/sec won't be broken up into multiple packages.
2. Actual size of unidirectional data/sec is derived by (client-defined) Netspeed over server tickrate; 10000/30 = 333 bytes/s, 15000/30 = 500 bytes/s.
3. Actors' relevant data is NetPriorit-ized (objects' not?) by importance, but whatever exceeds per-sec budget just won't go through, so higher tickrates can negatively impact user XP in heavy-channel (ONS) maps - say, through invisible turrets/projectiles/weaponfire/emitters - esp. during late-game where everyone's around each other.
4. This amount of data must be contained in a valid packet size; both 333 bytes and 500 bytes can, therefore, only fit in a 512 byte packet.
5. Longer packet size streams are more prone to network anomalies such as jitter, delay or dropping, worsening user XP. Generally, a 64 byte stream will be more fluid n' resilient to a 512 byte one.
6. For reasons I still don't understand, max client-side FPS in UT is also determined via Netspeed / 64; e.g. 10000 -> 156fps. Note that max isn't what you'll always get, since CPU/GPU/RAM load also comes into play.
7. Because of (6), ideal Netspeed can be estimated via user's max acceptable FPS tolerance; e.g. for 120fps *64 = 7680 bytes.
8. Such a transmission per sec size, i.e. Netspeed, saves on server BW while also ensuring fluid downstream, thus making for good user XP.

Source: mostly GreatEmerald's post in this 6-year-old BU msg. board thread. Edit: this even older thread might also be of some extra help. Lastly, a (legacy UT) analysis of the gameplay impact that Netspeed and tickrate settings can have by TNSe that's also relevant to this game may be found here.

PS: In an IT context, RPC usually stands for Remote Procedure Call, whereby a CPU call is executed on another host across the network.

User avatar
Posts: 2324
Joined: Mon 23. Aug 2010, 15:35

Re: Netspeed

Postby Cat1981England » Sat 10. Sep 2016, 20:20

What Peg said^

Increasing the netspeed will result in ping spikes, packet loss, and horrible fps jumps if we go higher then 10001 (as the capper doesn't seem to work very well). The current tick rate means that 99/100 shots will register and the netspeed is sufficient for the maps we have/the total number of players that could be on the server and therefor the amount of data sent to each client every tick.
The Universal Declaration of Human Rights, Article 1:

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

Return to “General”

Who is online

Users browsing this forum: CommonCrawl [Bot] and 0 guests