gorgias1976 Wrote:

1959nikos Wrote:

gorgias1976 Wrote:maybe some driver with a high bandwith in his setting could be eating up all bandwith inside the server.

Is there a way each of us check this for himself?

Previously it was defined at the Multiplier.ini, so now it should be in it's related .json file

Quote:Yes, the advice I was provided from ISI was 256 up/down or at most 512 up/down for the client side. That is why I am surprised Andrew saw a benefit. The server has ample bandwidth and I usually run the pipe at 14 MB up/down, but limit the max user setting to 512 up/down. The explanation was, with a wide variance of connection speeds, narrowing the numbers should prove helpful. In no way do I doubt what James Andrew says though because I'm convinced it may be uncharted territories for ISI also. I'll check again with them to re- re- reconfirm.

Quote:Following-up on the topic, I'm discussing it with one of the rF2 engineers that handle network code, and will report in here soon as I have something resolved.

Quote:At VEC we have our server set to 17Mb/17Mb and we host 45 teams with a hand full of spectators, lots of driver swaps for 24 hours without a problem. rF2 is very clever about how it conserves bandwidth. The thing you have to look out for when hosting is although you get 50/10 domestically, you may only really get 7/2 internationally. Our older server for VEC had a 600/600Mb connection but only got those rates domestically. When testing I saw we could get about 50/50 to most countries but some only 24/24 so to play it safe we throttled the server to 17/17. I would sugest using a tool like speedtest.net and browse around the map to pick servers all over the world to see what sort of rates you get. If you're only really planning on a domestic audience then you are probably fine setting your server to 45/7 or something like that. I think a lot of times the dedi will act strange if you set the rate too high and the server doesn't throttle to stay within the limits. It seems a little counter intuitive that lowering the limits on the dedi would actually produce better results but it does in some cases.

Quote:Calculating a rate per car is tricky because the rate goes up exponentially.

Let's say each car transmits 2000bytes/sec (I'm just throwing out a random number here) to the server and you have three cars on the server. The server now has to send that 2kb*3 to each car (excluding sending a player's own data to himself).

So it isn't just <telemsize>*<drivercount> = <totalupstream>
So in that case it would only be 2000*3=6000kb/sec

But is's really more like <telemsize> * <drivercount> ^ 2 - <telemsize> * <drivercount> = <totalupstream>
So in reality it's 2000*3^2-2000*3=12,000kb/sec

But look when you add more drivers:
2000*20^2-2000*20=760,000kb/sec

So it grows fast.

The unknown is the exact size of the telemetry packets. Also, the server is very smart about how often it updates players. For example. Player A and B are on one side of the track and Player C is on the other. The server reduces the rate at which is reports the status of Player A and B to player C because it knows they are very far apart. You can see this in client side replays when selecting a car that is far away from your own. You will notice unessential stuff like gear changes is almost completely missing sometimes. The server also knows that A and B are close to each other so it will send the data for those two players rapidly. Sorry, I am probably not wording this very well. hahaha. Long story short, it's hard to take a calculator and determine how many cars you can get on a server with X amount of bandwidth. You could calculate a worst case scenario where you know how much bandwidth it would take for the server to not have to throttle at all. But that is about it.

Quote:Another thing to note is that the dedi will show the percentage of allocated bandwidth being used. You will notice the downstream is hardly used at all because it's only getting one copy of the telem from each car. It's the ustream that gets hammered because of the way it has to send copies of the telem from each driver to everyone on the server.

Quote:

Quote:Quote Originally Posted by Spinelli View Post
1. So for the guy running the room (not an actual server, just my regular PC that I'll be playing on at the same time) the upload speed is more important, but for the players joining, their download speed is more important? Is that correct?


2. Can a good ping make up for bad down/up speeds, and Vice-versa?

1: Correct

2: Not really. You need both.

bullwinkle Wrote:working for me

Axe Wrote:unfortunately, all todays attempts ended with "sever connection failed" message