Effective upstream

Started by
17 comments, last by hplus0603 15 years, 10 months ago
Hello. I'm planning on creating a real-time P2P game, so clients' network upstream is important. I need some fairly obscure information to know whether my idea is feasible. What is the typical proportion of the advertised upstream that can be used in practice at maximum capacity on a home connection? How much does it vary between locations and connections? I only need rough figures, and ones from experience will do. Thanks.
Advertisement
Didn't we answer this the other day?

There are cable connections that will only get you 20 kbps. There are other connections that will give you 768 kbps. In general, you can expect to send 1 byte for every 10 bps, so on a 128 kbps uplink, you can expect to send 12.8 kilobyte per second, assuming you don't go wild with packet overhead.

You should know that for P2P, the uplink needs grow by N, whereas for client/server, the uplink needs don't grow with the number of players.

Btw: Xbox Live! titles need to be designed for an actual up speed of 8 kilobytes per second or less, all header overhead included -- and on Live!, there's actually more headers than on the regular internet, because of the tunneling protocol they use.
enum Bool { True, False, FileNotFound };
Cheers.
Quote:Original post by hplus0603
Didn't we answer this the other day?

Wasn't aware it came up. Of course I searched the forums, my terms must not have hit the mark.
EDIT- I read the topic, dunno how I missed it, but it doesn't contain the info I'm after anyway.
Quote:Original post by hplus0603
In general, you can expect to send 1 byte for every 10 bps, so on a 128 kbps uplink, you can expect to send 12.8 kilobyte per second, assuming you don't go wild with packet overhead.

Only 80%? Ouch. From possibly unreliable tests available on the internet it seems I get around 98% of the advertised upstream for my connection, looks like they get a whole lot worse.

I don't understand the last part of your sentence: does greater packet overhead reduce the actual upstream rates?
Quote:Original post by hplus0603
You should know that for P2P, the uplink needs grow by N, whereas for client/server, the uplink needs don't grow with the number of players.

Yep, I'm aware of that. But as you know the upstream needed by the server grows by N^2 in client/server, which is why I chose P2P; I want the common man to be able to host (of course I mean in terms of control here) large servers. And the accessibility will help alot for early popularity.
upstream is a real downer for internet gaming. hosting large (how large?) action games on a broadband is unrealistic, even with p2p.

From experience, you need on average 1.1 kBps per channel (including headers) just to send your player state to another box at a reasonable rate (we use 15fps, 1/2 of 30fps or 1/4 of 60fps). That's easy to work out actually if you know roughly the size of the data you want to send.

So with p2p, 16 player games are already an impossible stretch for the recommended upstream. There is a lot of throttling involved (decrease rate, culling of objects, ...), but the worse case scenario wont do. You will have to decrease the rate to a really poor level.

the XBox Live overhead is substantial (cant recall the exact number). That means you will have less margin for your actual data. And then you may have voice comms to consider too, and that will really hit your upstream (again, around 1.5kBps per connection).

Everything is better with Metal.

Quote:Original post by Baiame
Quote:Original post by hplus0603
In general, you can expect to send 1 byte for every 10 bps, so on a 128 kbps uplink, you can expect to send 12.8 kilobyte per second, assuming you don't go wild with packet overhead.


I don't understand the last part of your sentence: does greater packet overhead reduce the actual upstream rates?


The network speed will be measured in terms of how many bits of network traffic there is, which includes Ethernet, IP, and TCP or UDP overhead. If you only send 1 byte of your application's data per packet then you'll see that overhead consuming over 90% of your bandwidth and your application will appear to hit an upstream limit at something far smaller than you would expect. The upstream rate will appear different depending on whether you measure at the application level, the OS level, or the physical level.

Also, on some networks the bps measurement includes stop bits and parity bits, though I don't know how relevant that is these days.
Thanks.
Quote:Original post by oliii
upstream is a real downer for internet gaming. hosting large (how large?) action games on a broadband is unrealistic, even with p2p.

From experience, you need on average 1.1 kBps per channel (including headers) just to send your player state to another box at a reasonable rate (we use 15fps, 1/2 of 30fps or 1/4 of 60fps). That's easy to work out actually if you know roughly the size of the data you want to send.

I'm not sending states, I'm sending inputs. I think I can get 32 clients each with at least 128 kbps upstream interacting in real-time. But it depends on whether crappy stitch-up connections are common (or, how crappy they are). Of course the network update rate is low at about 12.8 Hz, and the input data is very nearly prohibitively small, but it still may be possible.
Quote:Original post by Kylotan
The network speed will be measured in terms of how many bits of network traffic there is, which includes Ethernet, IP, and TCP or UDP overhead. If you only send 1 byte of your application's data per packet then you'll see that overhead consuming over 90% of your bandwidth and your application will appear to hit an upstream limit at something far smaller than you would expect. The upstream rate will appear different depending on whether you measure at the application level, the OS level, or the physical level.

I think the physical level is what I'm interested in. Have any figures?

EDIT- The discussion on it is my fault for not specifying a platform (PC), but I'm really not interested in Xbox Live.
I think 75-80% of the advertised up speed is a good safe bet. If you try to go more than that, you risk hitting a lower than advertised upstream cap, or a cap due to a busy network @ peak hours, or the user using other internet connected applications at the same time (e.g. chat, etc.).

There are no "figures" to show, because when an ISP calls their service "128 kbps upstream", you just have their word to take for it. Depending on the ISP, your location, and time of day, it could actually mean 128 kbps, or 100 kbps or 140 kbps. Take it as you will.

Of course, it all depends on how safe you wanna play. I'm sure 90% is also a good number, just not as safe as 80%, etc.

Just to clarify, I was talking about the physical layer, which means raw bits per second. You will need to take into account the overhead of your packets (which includes IP, UDP or TCP layers).

Edit: From my own personal experience, my IPS plan (Rogers Lite) says "128 kbps upstream" and my up speed is indeed usually 16 kbytes/sec +/- 0.5 kbyte/sec on average.
Thanks.
Quote:Original post by shurcool
I think 75-80% of the advertised up speed is a good safe bet. If you try to go more than that, you risk hitting a lower than advertised upstream cap, or a cap due to a busy network @ peak hours, or the user using other internet connected applications at the same time (e.g. chat, etc.).

Hmm, you got me thinking about what causes I should worry about. I guess if players are shut out by upstream caps more than around 6% less than advertised, I'm not worried; if they're running other internet applications, they shouldn't be, so I don't care. The network traffic one is a concern though. How much does one's effective upstream often drop in high traffic?
Quote:Original post by shurcool
There are no "figures" to show, because when an ISP calls their service "128 kbps upstream", you just have their word to take for it. Depending on the ISP, your location, and time of day, it could actually mean 128 kbps, or 100 kbps or 140 kbps. Take it as you will.

Of course, but I couldn't exactly request mounds of statistical data!
Quote:Original post by shurcool
Just to clarify, I was talking about the physical layer, which means raw bits per second. You will need to take into account the overhead of your packets (which includes IP, UDP or TCP layers).

Yep, that's what I wanted, cheers. Incidentally, because of the game's P2P nature the packet overhead is actually considerably larger than the useful information.
Quote:Original post by shurcool
Edit: From my own personal experience, my IPS plan (Rogers Lite) says "128 kbps upstream" and my up speed is indeed usually 16 kbytes/sec +/- 0.5 kbyte/sec on average.

Still hoping most people are with decent ISPs. What got me worried in the first place was the connection at a friend's house I stayed at recently, he was only getting around 55% of the advertised downstream, and that was from BT, presumably the largest provider in the country.
What I meant by packet overhead was that the advertised bit rates are typically physical layer. On top of that, you will need at least the IP header (20 bytes) and the UDP header (8 bytes) or TCP header (20+ bytes). If you're unlucky, then your ISP also counts physical framing header size, which is 5 bytes for every 48 on ATM.

So, if each update message is 32 bytes, and you send it with UDP, over ATM (which is what's used by most DSL connections these days AFAICT), then your actual IP packet size will be 32+28 == 60 bytes, which fits in two ATM cells, which end up using 106 bytes on the wire. 106 bytes equals 848 bits, the way your upstream might be measured. Compare that to the 256 bits of payload, and weep.

If you're sending larger packets, say 1000 bytes per packet over TCP, then the overhead for TCP/IP is 40 bytes; 1040 bytes fit in 22 cells, which means 1166 bytes on the wire. The utilization in that case is almost 86% (8000 bits payload, 9328 bits on the wire).
enum Bool { True, False, FileNotFound };
Quote:Original post by Baiame
Still hoping most people are with decent ISPs. What got me worried in the first place was the connection at a friend's house I stayed at recently, he was only getting around 55% of the advertised downstream, and that was from BT, presumably the largest provider in the country.

Advertised downstream is a whole different beast. Usually it refers to the cap on the download speed, in other words the maximum downstream you will ever see; your top dl speed.

It's quite likely you might never see that high of a speed if the network is quite saturated with other users using up a lot of of the bandwith. So if your down cap is 5mbps, you might get 3-4mpbs on average, and 4-5mbps during nights/off-peak hours. This HUGELY depends on and varies from one ISP to another, of course.

Also, if your plan is a low-speed one, it's a lot more likely you'll always be limited by the artifical cap when downloading, rather than the network's overall saturation, i.e. you'd be getting your advertised low speed, hehe.

But since the upstream is usually a low number compared to downstream, I think it's much more common to be limited by your plan's up cap rather than a busy network when you are uploading.

What I'm trying to say, your friend getting 55% of his advertised downstream is not all that unusual (especially if he has a 5mbps or higher plan, I would imagine). What I would look at instead is his upstream performance.

This topic is closed to new replies.

Advertisement