On my server pps is set to 4, it's at that value because a while ago Scawen stated that 6 was only intended for LAN servers. Is this still the case or can it be increased to 6 on a WAN server with no detrimental effects?

Spies

6 isnt a crazy amount of packets at all for an internet connection, it's quite normal for broadband. On a LAN you should be able to use a whole lot more packets per second.

I always use 6 packets per second on my servers and it isnt causing any problems or whatsoever. In fact, I think most people use 6. Try it yourself and if it starts to lag, turn it down to 5 or 4.

Ok I'll see how it goes, thanks.

Not sure the average packet length LFS produces, but 4 - 6 PPS seems _very_ low when compared with the 72 or 77 packets per second used by QuakeWorld.
Most other fast paced shooters use reasonably high update rates.

Would increasing the limit to say, 12 or 15 updates per second generate that much more processor load or traffic for a properly hosted, dedicated server ?

The amount of packets LFS uses compared to QuakeWorld says nothing about smoothness. It's all about what data is in the packets and how these are used. LFS uses state of the art interpolation wich makes it one of the smoothest online games.
The fact that QuakeWorld sends 72 or 77 packets per second probably means that these are very small packets with little data. But they have to be quickly after one another because shooters cannot use interpolation much.

I've always wondered why LFS doesn't use variable packet timing. It's not a popular technique, but why send lots of packets if the data isn't changing? And why wait until the next packet timer to transfer an update when the data has changed? It doesn't make sense.

When I do multiplayer I send updates when the control state changes, and use a timing interval only as a safety net for missed packets.

LFS positional interpolation may be state of the art, but at only 4-6 updates per second its very common to see the cars jittering a little when the actual position comes in from the server and it doesn't match the clients prediction.

IIRC Quakeworld entities contain vector information, so they keep moving in the same direction and speed as provided by the last update from the server. And at one update every 13ms or ever less, player/entity movement is utterly rock-solid.

I don't see why increasing the allowable update rate for LFS would be a problem. The dedicated server app is pretty lightweight, and it should be the choice of the admin to set network parameters appropriate for the hardware/network connection it's running on.

96 bytes * pps = bytes/car/s.
Data to send: racing_cars * ((racing_cars - 1) + spectators)
20 racers 3 spectators = 20 * ((20 - 1) + 3) * (96 * pps) =

247.5 kB/s @ 6 pps.
495.0 kB/s @ 12 pps.
618.8 kB/s @ 15 pps.

Not counting possible Insim/UDP traffic at X bytes/s.

Any errors will be blamed on lack of sleep.

filur does that packet size include the UDP header?

I think (and am probably wrong) it's 65 bytes just for that isn't it?

Still... 600kB is no problem for many servers, including mine. My connection can easily push 1.2MB/s constantly and burst of 2MB/s (but not reliably). I don't see why an option would be bad. As long as all clients have a ping of 66ms or less it should be fine. Maybe we could get a test patch with the raised limit just to see what happens? I'm guessing most clients could cope with 10pps or higher easily.

I think my 32mbit server can handle it then

Quote from (SaM) :

LFS uses state of the art interpolation wich makes it one of the smoothest online games.
.

Pardon me but I would say it comes out short in the netcode department. Everyone I talked with said they wish it has such great netcode like rfactor and I agree so where do you see that state of the art interpolation again?

I've never had a problem with jerkiness of cars even at 4pps, had wheel to wheel racing without any issues.. now if the net code was as bad as you say, that wouldn't be possible.