Discussion:
ubuntu live555 tuning issue
Pete Pulliam
2014-09-29 04:08:36 UTC
Permalink
I have an implementation of an rtsp proxy server based not he
live555ProxyServer that ships with the live555 source. I'm having problems
tuning my hardware to efficiently stream one external to many players.

When running test players on the same machine as the proxy, which is
proxy'ing an external rtsp origin (rtsp://
wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov, if you must know
;) I can hit the proxy with 1000 test players, getting 0% packet loss, plus
perfect playback from an additional player on a cell phone using T-Mobile's
network. The single-threaded proxy is using about 30% of the CPU at
that point. That would be fantastic, but that's for 1000 players on
localhost + one external. If, instead, I run a similar test with 20 test
players on a different machine on the same subnet plus the cellphone, I get
about 1.3% packet loss in the test players and horrible looking video on
the cell phone. With 40 external players I'm up to about 8% packet loss
and un-viewable video on the phone.

This all implies that I have a problem with the network stack or the
networking hardware serving the machines. (Correct me if I'm wrong)

uname -a:

Linux xxxx.xxxx.xxxx.net 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24
16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

​It's a 1 gig NIC.​

​Here are the tuning things I have tried so far:

sysctl -w net.core.rmem_max=8388608

sysctl -w net.core.wmem_max=8388608

sysctl -w net.core.rmem_default=65536

sysctl -w net.core.wmem_default=65536

sysctl -w net.ipv4.tcp_rmem='4096 87380 8388608'

sysctl -w net.ipv4.tcp_wmem='4096 65536 8388608'

sysctl -w net.ipv4.tcp_mem='8388608 8388608 8388608'

sysctl -w net.ipv4.route.flush=1


ulimit -n 65536

I'm approaching my wits end (not representative of a loss of humor), and
would appreciate any advice.
​
​Pete
--
The information in this message may be confidential. It is intended solely
for
the addressee(s). If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by
you
in reliance on it, is prohibited and may be unlawful. Please immediately
contact the sender if you have received this message in error.
Pete Pulliam
2014-10-02 21:47:37 UTC
Permalink
More data points, more refined confusion, about an ubuntu live555 tuning
problem.

When serving from port 8554 (non-priveliged), we are getting 800
connections comfortably (Great!)

When serving from port 554 (privileged), we are sucking at less than 100
connections, even with extreme tuning (Terrible!)

No, we can't actually avoid using port 554.

This is true for two different versions of Ubuntu linux, and has been
tested on six different pieces of hardware in three different pops. I've
looked for iptables rules.

The test framework uses openRTSP with the last client started returning
quality metrics, with one or more VLC clients also playing for visual
confirmation.

"My Code" refers to a live proxy implementation.

Here is a simplified view of the test graph:

*My Code* (based on April edition of live555)

root, port 8554, udp -> GREAT! (tested at 800+ players)

root, port 554, udp -> terrible

root, port 554, rtsp over TCP -> GREAT! (tested at 1000+ players)

root, port 554, udp, players all on localhost -> GREAT! (tested at 1000+
players)


*Stock April live555 proxy*
non-privileged, port 8554 -> GREAT!
root, port 554 -> terrible

*Stock September live555 proxy*
non-privileged, port 8554 -> GREAT!
root, port 554 -> terrible


Comments will be greatly appreciated.

Thanks,


Pete
--
The information in this message may be confidential. It is intended solely
for
the addressee(s). If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by
you
in reliance on it, is prohibited and may be unlawful. Please immediately
contact the sender if you have received this message in error.
Jeff Shanab
2014-10-03 00:44:58 UTC
Permalink
f i r e w a l l ???

Wireshark may help here. If it is a sea of red then that may indicate
issues.


Also check the measurements. Are all users getting the same? ie 1000 at 1
Post by Pete Pulliam
More data points, more refined confusion, about an ubuntu live555 tuning
problem.
When serving from port 8554 (non-priveliged), we are getting 800
connections comfortably (Great!)
When serving from port 554 (privileged), we are sucking at less than 100
connections, even with extreme tuning (Terrible!)
No, we can't actually avoid using port 554.
This is true for two different versions of Ubuntu linux, and has been
tested on six different pieces of hardware in three different pops. I've
looked for iptables rules.
The test framework uses openRTSP with the last client started returning
quality metrics, with one or more VLC clients also playing for visual
confirmation.
"My Code" refers to a live proxy implementation.
*My Code* (based on April edition of live555)
root, port 8554, udp -> GREAT! (tested at 800+ players)
root, port 554, udp -> terrible
root, port 554, rtsp over TCP -> GREAT! (tested at 1000+ players)
root, port 554, udp, players all on localhost -> GREAT! (tested at 1000+
players)
*Stock April live555 proxy*
non-privileged, port 8554 -> GREAT!
root, port 554 -> terrible
*Stock September live555 proxy*
non-privileged, port 8554 -> GREAT!
root, port 554 -> terrible
Comments will be greatly appreciated.
Thanks,
Pete
The information in this message may be confidential. It is intended
solely for
the addressee(s). If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by
you
in reliance on it, is prohibited and may be unlawful. Please immediately
contact the sender if you have received this message in error.
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel
Ross Finlayson
2014-10-05 07:39:46 UTC
Permalink
My Code (based on April edition of live555)
You should upgrade to the latest version of the code. Old versions of the code are not supported.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

Continue reading on narkive:
Loading...