Minimum Recommended Server Specs for rFactor 2

So, just to clarify, rFactor 2 bandwidth requirements are 10 times more than rFactor 1?
I know all the team is busy, but if you can, please verify this requirements.
I am on a team that has 30+ participants per race but I am afraid that we cannot afford a server with that upload speed in south america (23 megabits per second), so I am worried that maybe we could not make the switch to rFactor 2 when it is released.
We have set the upload bandwidth to 2mbits/s in the rFactor1 server and we race without problems...

 

Because every client needs to talk to every other client VIA the server. 10 people talking to 10 other people all at the same time through the server's In and Out. 30 people talking to 30 other people all at the same time through the server. It's exponential.

 

I was kind of hoping you might notice that my figures are quite close to the quoted ones (based on actual tests, not calculated, as Tim stated before and again after my posts) and have a closer look at what's going on, instead of continuing to 'see' a mistake I've made (yet still come up with figures much much closer than yours).

But, here goes.

The data rate per client increases exponentially with the number of clients.

If the data rate per client (DRPC) for 1 connected client is x, then for:
2 clients, DRPC = x * 2[SUP]2[/SUP]
3 clients, DRPC = x * 3[SUP]2[/SUP]
etc.

10 clients, DRPC = x * 10[SUP]2[/SUP].

From the first post, DRPC for 10 connected clients is 96kbps. To bring that back to a theoretical DRPC for 1 connected client (to multiply back out for higher numbers) you need to divide 96 by 10[SUP]2[/SUP], as I've done, resulting in 0.96. (the value of x above)

To then extrapolate for 30 connected clients, as above, DRPC = 0.96 * 30[SUP]2[/SUP] = 864kbps per client.

To calculate total bandwidth you obviously need to calculate that by the number of clients, so 864 * 30 = 25920kbps.

What you were doing was calculating the DRPC linearly, so that the total bandwidth increased in a n[SUP]2[/SUP] fashion with the number of clients. Actually the DRPC needs to increase at n[SUP]2[/SUP], making the total bandwidth increase at n[SUP]3[/SUP] since the DRPC is, by definition, also sent to each client.

It's easy to approach it the wrong way, and then can be difficult to change how you're looking at it. But perhaps when your figures are quite different from the quoted ones, you might want to have a good think about it before continuing to assume everyone else is wrong

---

Back on topic a bit more, the bandwidth seems a substantial increase on rF1, but the extra variability with weather etc was always going to have a fair sort of effect (plus, I think the limited data rF1 sent out created some issues so probably needed some expansion already). Extra functionality has to come from somewhere; it's a bit like shum wanting fully animated or at least 3D crowds - apparently ignoring the fact you need enough power to do it in realtime. Server companies still offering rF1 level bandwidth 6 years later probably aren't a good option.

 

Hehe. Nice aproach: to believe in corectness of formula just because it gives similar result.


Here is your main mistake

Theoretically, traffic from server to single client (Tim said: per client) should be linear function of numebr of cars. Single client should get as much data as there are cars on track (-1) - it should be clear and intuitive.
After that overall data traffic transferred from server to ALL clients should be quadratic.

That makes a question: why Tim gave us "per client" numbers which look like exponential function of cars number.

BTW: It is nothing new. rF1 traffic (as well as other games with the same communication approach) is calculated in the same way. Of course probably rF2 is transferring more data which is expected. But way to calculate server traffic must be the same.

If client gets amount of data which is equal to power 2 of number of cars... there is definitely something wrong with net code.

 

I did my own calculations and get results for 40 clients. For that is 122-125 Mbits connection needed for server. I taked for basic that one car generated data is not constant and that grows % for clients and results was that if there is 40 clients then 1 driver generates 76,4 Kbits of data. I have 100 Mbits connection for my server and if my calculations are correct then my server can handle 38 clients ber race. Maybe 39 but 40 drivers noway. Thing is. Many people dont have home that good connection to take that data in. If there is 40 clients then one driver need 3 Mbits download speed at home and soone. Thats alot.

 

Yeah... looks like you said. But it must be something wrong, because there is no reason to affect data generated by single car by number of clients connected.

 

Could the Host in the future be able to select what information is needed to send to Clients for loosen the upload speeds a bit?

By this i mean of setting the Server so that it uses only basic models on track condition (no track evolution), Basic tyre physics etc...would that lighten the amount of data needed to send for Clients by any way?

 

Looks like there is no reason but something is generating more data for one car if there is more cars. This looks little wierd and maybe this is mistake and some data is generated multiple times or something. I think we get answers when beta comes out. Then we get that data ourself and can do more exact calculations.

 

And that makes you wonder why the data sent to each client, or required per client, would increase exponentially with the number of clients. I don't know, you obviously don't know, and as I already said I think the figures given are a little sketchy (if it was, 10 cars require this, 20 cars require that, ... then ok... but ranges of cars makes you wonder how many there were exactly, etc). Perhaps Tim can shed some light?

As you say, it seems logical that each player need only upload their own data once, and then every player's data (as appropriate) is sent out to all other drivers, giving something close to n[sup]2[/sup] for overall bandwidth, rather than DRPC. Either it's more complex or the slightly vague figures given were actually very very vague

Edit: I should also say I thought rF's bandwidth increased at a fair bit less than n[sup]2[/sup] by filtering out less necessary data as appropriate, which is what made it much better than other titles of the time (which still tended to send data for all other cars). For rF2 the big unknown is how the live data is sent; seems risky for each client to rely on current car positions to do its own live track condition changing, so if the server instead sends track changes in accordance with how each car is affecting the track at the moment you would expect a fair increase in data. In short: buggered if I know

 

Tim can you tell us what is the difference from the requirements of RF1.
Here in Argentina, we have a dedicated server with a 5Mbps connection and can hold sessions with 30 people without problems, in fact we usually have 3 rF servers without problems but not always in every 30 people.
We are surprised at the difference it would have regard to RF2.
It is practically impossible to have a connection here that speed, not to mention how expensive this would be at least to us.

Regards
Pablo Lorenti

PS:Sorry for my english, i use google translator to help.

 

Not ISI's fault if your country have such an ugly online service, I live in Italy and probably our average band sucks even more, so blame your country instead. Technology move on, not their fault if our countries are like third World. It could sound harsh but.. that's the way it is. ISI did their best on net code and you can't expect previous requirements on a NEW game with NEW physics , graphics etc.

 

fortunately i live in Portugal and we have a great internet service. our optic fiber goes up to 30Mbs of upload speed for home clients and more for companys and other prime clients.

 

I do not blame anyone, I'm saying is that surprises me.
In Argentina, household connections of 30Mbps, but down, 3Mbps upload only.
They are not symmetrical 30Mbps.

 

So today is a 1st Nov, when I can expect Q & A?

 

here in Portugal isnt simetrical as well. the upload is 25/30 and download domestically can go up to 200

 

I live in Poland and our league has 100Mbps, and two 50Mpbs connections. But even if we would make it, I still think there is something wrong with results given by Tim. He still haven't answered on this, so probably they investigate the situation (I believe)

For whom didn't followed discussion: server data traffic should have x[SUP]2[/SUP] characteristic, where x is number of cars on track. But it looks like rF2 generate something like x[SUP]3[/SUP]

 

If rF2 is anything like rF1 it is really hard to predict the bandwidth. rF1 only sent detailed data to a client for the cars that were closest to that client. There is no need to waste bandwidth giving full detail to a car that is out of view. The only downfall is client side replays do some funny things for the cars that weren't close to you. Things like going top speed in 1st gear, leaning to the side, RPMs not going up smoothly. But by scaling back they can have more clients. Maybe these specs are on the extreme side. But then again Tim said these are minimum specs. So who knows.

 

How many data is sent doesn't matter. It may be 2x or 10x comparing to rf1. Important is the function of growing data in relation to car numbers. In our model it should be quadratic one (modified by some factors of course).
Let's say, client(car) sends data to server, server gets data from all clients and send whole bunch back to all clients. At this point we talk about quadratic function.
Additional data like results, synchro, weather, track condition should not change the exponent. May change multiplier. if some data are related to single car (for example assuming surface change by single car is sent for any car separately), those data will grow with quadratic function also. So it doesn't change function characteristic at all.

That's math. I'm looking forward for some words from devteam or just beta tests.

with regards

 

How do you expect to calculate the bandwidth per car if the fidelity of the data sent to each client isn't static/fixed? If the amount of data sent to each client isn't static, then you will never be able to come up with a static calculation for it. That is probably why ISI chose to to a real world test and monitor the bandwidth used as sort of a guideline but not set in stone.

Here are two scenarios. First scenario you have two cars on the track and do 10 laps but make sure both cars are far enough from each other that they are out of sight. Then in the second test you have two cars on the track and do 10laps where one car is right on the tail of the other. The second test is going to consume more bandwidth then the first. At least this is how rF1 worked and it worked well.

 

Yes... but you still talking about some multiplier (factor) which doesn't change data traffic function characteristic.
Let's get it simpler.
Let;s say:
y = ax[SUP]2[/SUP] + c

where y is traffic and x is number of cars. Value of 'a' (which may be throttling factor you referred to) doesn't matter. y will grow always exponentially in relation to car number. It is very important because exponent 'says' how quickly will traffic grow with new cars connected.

So I'm not talking about calculation for static data but about function of growing data traffic due to cars number on track. Other factors like throttling don't change function exponent.

In practice, we can predict/know how many data is generated by single car.
if we have 10 cars connected, 10 cars send data to server, but server must re-send all data to all clients. thats why there is 10 * 10 = 10[SUP]2 [/SUP](there are some things I skipped intentionally but those doesn't matter at this point - are not important to describe our case)

Hope I helped you to understand that. I have some language limitations so maybe my explanations are not clear enough. Sorry for that.