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 x2 characteristic, where x is number of cars on track. But it looks like rF2 generate something like x3

As I said, working it out isn't really possible. You have more cars means more data between cars, but you also have more cars having more effect on the track and this information needing to be relayed. The first post contains actual reading results, it's as accurate as it can be really up to the number of cars listed. We'll be able to get higher readings during the open test I'm sure.

1. Any car generates some changes for its own. I suspect client sends only those changes - after that it means it will not affect exponent of the server traffic function.
Then we get function
y = (x+surface_changes)2

2. In worse case, server might send to clients whole surface state. I said in worse (in opposite to sending changes). But even if, the data traffic will be only greater by such amount of data and not depending on car quantity. It's quite intuitive I think.

then we get function
y = x2 + surface_state

I really cannot imagine how we may get something like exponent 3.
But there is nothing left than wait for release... and then for fixes I believe.

MaXyM, I guess you could calculate a worst case scenario which would assume that all clients are receiving the most detailed updates possible. You should then be able to come up with a basic calculation. Then you would know that in the worst case you will need X amount of bandwidth. But could probably get away with less do to the throttling that rF is capable of. Again, only speaking of experience with hosting in rF1. But I can't believe rF2 will be much different. Who knows, we may even have options to disable live track and weather to reduce the bandwidth requirements even more.

@Noel
rF1 (as well as other games with the same client-server model) matches what I said: server traffic is quadratic function of competing clients. Throttling is a feature which makes traffic lower in some situations (let's say in most). But with throttling or not function doesn't change exponent.

That's why I'm still surprised about rF2 traffic measurements. it is not about numbers in overall. SInce there are more features - I would not problem even with 100kBps sent by single car. The same with 23Mbps needed - if features requires such traffic, it must be.

But how numbers grow in relation to cars number- this is what I'm talking about. It simply cannot be exponent 3 function if everything is done correctly.

I know that South Americans are a minority of the customers of rFactor and that it is very difficult to adapt the engine to send less data and that our low bandwidth is our fault and not ISI's fault, I know that it is not worthwhile to remove features to the other customers because of a minority that cannot find or pay for high bandwidth servers in their countries.
Knowing all that I will anyway ask ISI for a favor: please consider an option to remove features and reduce the bandwidth requirements, something like 10 megabits per second upload for 30 cars is affordable in South America, asking more than that the prices spike up and most teams will not be able to pay for a server in their country, needing to use a distant server and having much latency.
Though that latency can be tolerated, is not very nice really, it complicates things, causes accidents, etc.
Maybe livetrack, marbles, drying path of the cars, etc. could be disabled and save those bytes to reduce bandwidth to acceptable levels in our region.
This would be a feature useful for two years only.
I know its hard, I know that it is anoying, so, if it is not implemented I will understand and will not have hard feelings.
I am afraid though that maybe people here will stay with rFactor 1 instead of using a distant server if thats not implemented.
So, you have my wish and my fingers crossed! :-)
Thanks a lot for listening and.... KEEP UP THE SUPERB WORK! rFactor 2 seems to be shaping up to be a piece of art and not a simulation program.