Just to give an update: Found this thread http://live-devel.live.narkive.com/nTWRunPX/slow-connection-problem-with-rtp-over-rtsp-tcp from 7 years ago and increased send buffer size in liveMedia/GenericMediaServer.cpp to 50MB. This seemed helped at the beginning but server slowed down again after sending ~16MB which corresponds to server’s tcp maximum wmem. After increasing sender’s tcp wmem to a larger value it can now send up to 100MB with maximum speed which I need. It is probably not the right way but only way I was able to make it work. Better solution is appreciated. Thanks On Jan 14, 2017, at 5:08 PM, Arslan, Engin <en...@illinois.edu<mailto:en...@illinois.edu>> wrote:
Hi Ross, Thanks for the reply. I checked the link and agree that TCP performance can be affected badly when rtt is high and buffer size is small or loss rate is high. However, I set the buffer sizes to high enough values as: sudo sysctl -w net.core.wmem_max=16777216 sudo sysctl -w net.ipv4.tcp_wmem='4096 16384 16777216' sudo sysctl -w net.core.rmem_max=25165824 sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 25165824’ Since I'm testing on local network with ethernet connection, loss rate should not be problem for TCP performance. I can actually get 100 Mbps throughput when using TCP with iperf or simple client-server communication when RTT is 100ms. So I guess it is not that TCP cannot obtain enough throughput. I’m certainly not claim this issue is specific to openRTSP. I’m just trying to understand the behavior and possible ways to alleviate. I am guessing some rtsp streaming specific reason(s) hold TCP back from reaching full speed but not sure what and why. Any ideas/suggestions appreciated. Thanks Engin On Jan 14, 2017, at 3:49 PM, Ross Finlayson <finlay...@live555.com<mailto:finlay...@live555.com>> wrote: This has nothing to do with our software; it’s an inevitable property of TCP connections. You realize, I hope, that the bitrate of a TCP connection is inversely proportional to the connection’s RTT (round-trip-time); e.g., see https://www.switch.ch/network/tools/tcp_throughput/ It’s also important to understand that - with our software - you are streaming datagrams, which means that - even if you’re encapsulating them within a TCP connection - you have to be prepared for the possibility of some of these datagrams being lost. It’s important to understand the difference between transmitting a stream - which occurs at a fixed data rate, regardless of what kind of network you happen to have underneath you - and downloading a file (i.e, the World-Wide Web), which occurs over TCP connections whose speed automatically matches the speed of the underlying network. We’re doing the former; not the latter. Streaming over TCP is generally a bad idea; it’s something that you should do only as a last resort, if you have a firewall - between your back-end server and proxy server - that blocks UDP packets. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com<mailto:live-devel@lists.live555.com> http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
