The online racing simulator
Why limit to such a low packets per second? (Server Hosting)
I understand that when the multiplayer of LFS was coded it was common to have extremely slow internet speed


But time has passed and the average internet speed must have gone up like 1000 times


It makes me wonder, why is it still limited to only 6 packets per second?


At home for example I have 10mbps of upload speed, which is nothing special nowadays, and still it would be able to handle 47 guests with 40 cars on track with ease (and let's be honest I would never get that much people to join a random in-home server)


For some reason it allows up to 12 packets per second in a local server, which my 10mbps internet would still handle ~33 cars

I imagine that a gigabit dedicated link would be able to host several servers at 60+ packets per second

I participated on the development of the multiplayer mod for BeamNG and during the development we did some tests, we could easily surpass 100 packets per second without issues


So what's the limiting factor here? Why local is allowed to use 12 and online only 6?
Physics Engine doesn't need that many packets to keep in sync. So the real question is ... Why more if that's all you need?
Gotta admit when we used a vpn to play LFS with 12 pps, the game looked unbelievably smooth. Not sure how it'll look on a big server and how more demanding it'll be for the rest of the players too, but you can definitely see and feel the difference.
Quote from DarkKostas :Gotta admit when we used a vpn to play LFS with 12 pps, the game looked unbelievably smooth. Not sure how it'll look on a big server and how more demanding it'll be for the rest of the players too, but you can definitely see and feel the difference.

Ye I don't know why we use more packets/sec. Me was told becourse it was to stressfull on server.
But on my server I can hardly see cpu at stress Shrug it stays on 800mhz when server is full (47 peeps)
Comparing this to my Wreckfest server 24 guys online server cpu is arround 20% use at 3,4mHz bandwith is arround 12gbit. But must say that game is smooth as **** online.
This is something I would also like to see, especially recently while I've been broadcasting races. Even if a higher rate is still not the default, it would be nice for us to have a choice to turn up the packet rate to more than we can currently.
#6 - Racon
If I understand it correctly, more packets would also mean more physics processing, as each packet causes some recalculations to account for ping.
Quote from Dygear :Physics Engine doesn't need that many packets to keep in sync. So the real question is ... Why more if that's all you need?

Look how spiky and choppy the car movement looks with 3~6 packets per second in LFS





Now compare it to what 30~100+ packets per second looks like in BeamMP:






To me it's very clear that 6 packets per second is NOT all we need Wink
Problem is in LFS cars start flying when they hit each sometimes with a small touch. Hits are often very unrealistic. I understand with high latency (other side world) this problem will always be there. But still think with more dedication to connection this problem can easily be solved. I also understood Scawen will be looking at this, together with more protection.
One of the reasons why I don't race online:
Quote from Specht77 :Look how spiky and choppy the car movement looks with 3~6 packets per second in LFS.

Scawen, pls fix. Big grin
Quote from Racon :If I understand it correctly, more packets would also mean more physics processing, as each packet causes some recalculations to account for ping.

AFAICT, when a new packet turns up, it just corrects the initial conditions for the next physics loop.

More pps should mean that the prediction error wouldn't get so large, but I don't see how it would cause more physics processing.

It could potentially even reduce the distance to other cars where physics calculations could be turned off (assuming this is already a thing), as less prediction would be needed.



Edit:
Servers' connection speeds and bandwidth limits have increased a *lot* since the current pps settings were done. There's a lot of room for improvement.

I was talking to Pete about this a couple of months ago (along with other broadcasting stuff) and did some calculations - there should be plenty of bandwidth headroom to increase both pps *and* max number of cars on track a decent amount with no issues as far as we're concerned.
Quote from Degats :AFAICT, when a new packet turns up, it just corrects the initial conditions for the next physics loop.

More pps should mean that the prediction error wouldn't get so large, but I don't see how it would cause more physics processing.

It could potentially even reduce the distance to other cars where physics calculations could be turned off (assuming this is already a thing), as less prediction would be needed.



Edit:
Servers' connection speeds and bandwidth limits have increased a *lot* since the current pps settings were done. There's a lot of room for improvement.

I was talking to Pete about this a couple of months ago (along with other broadcasting stuff) and did some calculations - there should be plenty of bandwidth headroom to increase both pps *and* max number of cars on track a decent amount with no issues as far as we're concerned.

I Asked this earlier in previous update or update before.
Made Scawen talk to Victor, but Victor says the it would take to much cpu use Shrug

I think most pc's have more power just like the bandwidth.

Thinking LFS can improve a lot.
Quote from Degats :It could potentially even reduce the distance to other cars where physics calculations could be turned off (assuming this is already a thing)

This is exactly what we did during the development of the multiplayer mod for BeamMP, sadly I don't have any recording with higher pps, but look how the car in front looks with 40 packets per second with ZERO physics calculations (notice how the car movement is a little bit jittery, that's because between each packet received the car had zero speed until the next position update was received)



Later on development speed information was also added in the packets so you wouldn't need to be running always above 60pps to look smooth, and that's how it turned out as smooth as the videos I posted some messages above


Quote from Degats :Servers' connection speeds and bandwidth limits have increased a *lot* since the current pps settings were done. There's a lot of room for improvement.

That's my point. When I started playing LFS S1 in ~2003 I had a 786mhz single core AMD Duron CPU with a 28.8kbps bandwidth

Today I have a 9 years old 4600mhz quad-core hyper threaded CPU with a 120,000.0kbps bandwidth

Also keep in mind that nowadays it's possible to get CPUs that are ~40% better in single thread and 400+% better in multithread than mine and also it's not that uncommon to see homes with 1,000,000.0kbps bandwidth...



Quote from RC-Maus :but Victor says the it would take to much cpu use Shrug

To be honest that sounds like a bs excuse... And even if it was true, why not leave it to us choose what our CPUs are able to handle?
Quote from Degats :AFAICT, when a new packet turns up, it just corrects the initial conditions for the next physics loop.

More pps should mean that the prediction error wouldn't get so large, but I don't see how it would cause more physics processing.

You client has been processing the car's physics all the while the packet is being sent, then when the packet it received, it goes back to the time point where the packet was sent and reprocesses the data from that point up to 'now'. There's overlap - some of the frames have been processed with stale data, then reprocessed with fresh data after the packet.

Essentially, for each second each car requires 1 second's worth of physics processing, plus half* as much as the total pings of all packets received for that car in that second. Ie, a ping of 50ms and 4 packets/sec will require an extra 100ms of 'overlap' processing per second, so 1.1 seconds of processing per second for that car. 40 packets/sec as mentioned above would be 200% - quite an increase.

*I'm assuming ping is including the return journey, hence halving here for average of one direction.
Quote from Specht77 :This is exactly what we did during the development of the multiplayer mod for BeamMP, sadly I don't have any recording with higher pps, but look how the car in front looks with 40 packets per second with ZERO physics calculations (notice how the car movement is a little bit jittery, that's because between each packet received the car had zero speed until the next position update was received)

Later on development speed information was also added in the packets so you wouldn't need to be running always above 60pps to look smooth, and that's how it turned out as smooth as the videos I posted some messages above


That's my point. When I started playing LFS S1 in ~2003 I had a 786mhz single core AMD Duron CPU with a 28.8kbps bandwidth

Today I have a 9 years old 4600mhz quad-core hyper threaded CPU with a 120,000.0kbps bandwidth

Also keep in mind that nowadays it's possible to get CPUs that are ~40% better in single thread and 400+% better in multithread than mine and also it's not that uncommon to see homes with 1,000,000.0kbps bandwidth...


To be honest that sounds like a bs excuse... And even if it was true, why not leave it to us choose what our CPUs are able to handle?

Sweet! Didn't know there was an actual and working MP mod for BeamNG. Definitely gonna try that later on. Looks pretty decent as well.

I'm wondering, is the damage also somehow synced? For example if the physics is calculated in a different way on the client PC and on a few other people their PC, do they see the same? For example when a wheel breaks off the car on someone their PC, but not on the client driving that car, would that cause weird things? Or is that not possible and synced to match up with other people later?

edit: Cool project bit far from smooth and good working, despite the higher PPS.

Why limit to such a low packets per second? (Server Hosting)
(15 posts, started )
FGED GREDG RDFGDR GSFDG