Here's my general rule when working with those variables:
Units are in Bytes, for per maximum packet payload size. Not MTU as it doesn't take into account for IP and UDP headers size.
Should be fine up to 1200 for today's commonly used internet services: ADSL, Cable, Fiber, Satellite, and Cellular connectivity.
However over 200 or 240 makes the game unusable for Dial-up 28.8K/56.6K modem users. While I do recommend at least 400 due to various classes in T3D that do rather large packUpdates
Units are in how many times per second to send update packets to each client. Can't realistically be above 32 (31.25 updates/sec).
Ideally this shouldn't be set above 10 unless on a very low latency connection and have plenty of bandwidth, such as LAN or just a local/single player game, to send at worst case ($Pref::Net::PacketRateToClient * $Pref::Net::PacketSize * $Pref::Server::MaxPlayers * AverageGhostedObjectsCount) bytes per second.
However for racing and other fast paced games ten times per second might not be fast enough update rate.
Units are in how many times per second to send control object move update packets to server.
This directly controls how often a client sends it's player controls state to the server and more often it sends it the less likely the server gets out of sync with the client player actions.
For any live action games this should never be below $Pref::Net::PacketRateToClient value and realistically can't be above 32 (really 31.25/sec) due to network updates also being driven by the same 32ms tick timing the rest of the game is driven by.
As for what to do to provide the user with the ability to configure those settings you can use sliders for each variable and a dropdown to provide configuration presets for whatever internet connection the user has. Tribes 2 did it a similar way:
- Tribes 2 network settings
- T2SetupNet.png (184.43 KiB) Viewed 1199 times