Given a web-server with an sd-card (storing 720p (7.2 Mbit/s) videos and 800 Mbit/s read-speed) and a wireless interface with 1200 Mbit/s transmission speed. I have to know how many clients can stream movies from the SD card through a HTTP request. Without considering the TCP header and data loss, I get 800 Mbit/s / 7.2 MBit/s = 111. So 111 streams are possible at the same time.

Is this theoretically correct? How does it change considering TCP and HTTP headers? Is it viable in practice considering weak WLAN signal etc.?

  • People get confused about Wi-Fi because of broadcast television or radio, both of which are unidirectional. Networking is bidirectional, and the medium is shared. The Wi-Fi bandwidth is theoretical under ideal conditions (a combination of data transfer in both directions between the WAP and all the STAs), and you are doing very well to get even half of that in one direction to one STA. – Ron Maupin Feb 4 '19 at 18:36

Is this theoretically correct?

Yes, given your simplistic assumptions.

How does it change considering TCP and HTTP headers?

Using TCP will drastically reduce your throughput. Remember that WiFi is half duplex, meaning a station can't transmit and receive at the same time. So the sender has to stop sending data in order to receive ACKs from the receiver. With lots of clients, this can be a significant amount of time.

Is it viable in practice considering weak WLAN signal etc.?

Absolutely not. There are several factors that will make this impractical for anything but a just a few streams:

  1. 1200 Mbits can be achieved only under ideal conditions. You need excellent signal strength and your receivers have to have the right MiMo configuration. If you have a station that has less than ideal signal, or not enough spacial receivers, your data rate will be much lower. When that happens, everyone else has to wait for the slow client to finish receiving. It's like driving a very fast car, but you're stuck behind a slow truck -- you can't go any faster than the truck in front of you.
  2. Wi-Fi is a very unreliable medium. That means there will be lots of retransmissions. That will greatly slow down your data rate.
  3. You don't mention how spread out your stations are, but access points practically can serve only 15-20 clients. If your receivers are all in the same area that will cause problems.
  4. You also have to contend with the 802.11 overhead. Management traffic, beacons, etc all will take up airtime and slow down your transmission rate.

There are probably more factors that I'm not thinking of at the moment. I'm sure others will point them out as well.


I have to know how many clients can stream movies from the SD card through a HTTP request.

You don't want to know.

Using WiFi for such a setup (assuming that you have many WiFi clients to serve) will be cumbersome to start with, because Wifi does not lend itself for one-to-many simultaneous data flows (see both Ron's answer and comment).

It's already difficult when the sender is on the wired part of the network, and needs to serve multiple Wifi clients, but it gets hilarious when both sender and even just one receiver are on the same shared medium (same radio interface of the same AccessPoint) - achievable throughput is crippled to less than 25% of the nominal rate, because "airtime" is wasted for the sender to send data to the AP, then the AP to ACK that, then for the AP to send to the receiver and the receiver to ACK to the AP. The effect may be not quite be as bad on modern multiband APs where sender and receiver are not on the same frequency band or radio channel.

In short: when serving many (video) clients simultaneously with a continuous data stream, restrict the WiFi part of the overall network to the absolute minimum: Camera or Video server ("sender/source") to its nearest AP (if it needs to be wireless, prefer wired by all means), and serve the clients from other APs. Size the AP-to-client ratio accordingly.

Consider adding a "stream replicating server" in the wired part of the network, taking only a single unicast stream from the source, then handling the stream replication to the many unicast clients with its CPU/GPU and NIC power (we'll forego the options of transcoding and multicasting for today).

On top of that, there's the question of video codec and software used, and how sensitive they are to an ill-formed data stream (packet loss and out-of-order delivery). Packet loss and retransmissions is what you will get in WiFi networks.

There was that case of a ~10-11Mbit/s HD stream (over HTTP), from a surveillance camera to a server, encoded with MPEG2. Occasionally, video quality suffered somewhat, but was generally acceptable; but a constant/sustained 10+ Mbit/s stream was considered a waste of costly bandwidth for the WAN. Therefore, the customer wanted to save some bandwidth and use a more bandwidth efficient MPEG-4 codec.

Curiously, on the same network, from the same camera streaming the same scene at the same resolution to the same server, the 2.5-3Mbit/s MPEG-4 encoded stream would just not work at all. Eventually, it turned out that an utterly wrong QoS configuration on the camera's switch port had impacted all video streams with massive out-of-order delivery effects and quite some packet loss when the WAN link was just a bit saturated. The given software's MPEG-2 implementation had been able to cope with it, but the MPEG-4 codecs in the same software didn't. Correcting the QoS config made things work again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.