I am trying to benchmark the performance of my HLS video server. My server is a pretty naive one at the moment: Just an NGINX file server. (HLS delivers video over HTTP by splitting it up into files called chunks.) Each file is ~256KB in size, and I need to download a file every 2 seconds. That's 1 mbit/s .

I have a pretty decent link to the internet from my AWS server. I have benched it at at least 2 gbps.

However, when I test streaming for trans-atlantic connections with ~150ms latency, I get very low bandwidth. I think this can be attributed to RTT and TCP windows. My main problem is that the bandwidth per connection is below 1mpbs which is desired quality of my video playback.

I do not want to invest in deploying multisite or CDNs at the moment, as I do not have many clients playing video.

I would just like my clients to achieve a bandwidth which is good enough to play the video. (My clients will be PCs,Androids,and iPhones).

This seems to me like a common enough problem. What do other people do here? Are CDNs my only hope? I don't have many concurrent clients, so CDNs sound like overkill to me.

2 Answers 2


Did some more research. It seems that for medium sized files, files that take no less and no more than several seconds to transfer. The initial congestion window is more important than the congestion window as far as TCP is concerned. In ubuntu, you can change the initcwnd value. The default is 10. I was able to get a 30% performance gain for my files by enlarging it to 25. Have a look here: http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/


You can set it as large as you like. You should set it to the bandwidth-delay product of your link.

RE your comments in this question at SO: Clients don't 'use' your send buffer at all. They have no idea how big it is and there is no sense in which they will not 'tolerate' a large one. The statement is nonsense.

  • Actually, I benchmarked it, and initcwmd platued at 30. With higer numbers, performance even started to go down (although with a much smaller co-efficient).
    – eshalev
    Commented Jan 27, 2015 at 12:49
  • @eshalev Very nice, but does that have anything to do with this answer?
    – user207421
    Commented Jan 28, 2015 at 6:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .