Hi,<br><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 6:56 PM, Felipe Contreras <span dir="ltr"><<a href="mailto:felipe.contreras@gmail.com">felipe.contreras@gmail.com</a>></span> wrote:<br><br>..snip..<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> My claim was that GStreamer was bad for small buffers; the smaller, the worst. That IMO is a fact. Now, how small, and and how bad GStreamer is depends on your system, my guess was that ARM was<br> specially worst compared to x86. I think the numbers show that.<br></blockquote><div><br>In the uncountable times I've been profiling the VoIP (and video) call on arm I found a perfect match with Felipe's finding: the smaller the buffers, the higher the overhead on the system. In the pipelines of telepathy-stream-engine, where imho there's plenty of unneeded elements (for instance, we don't need resampling/converting the audio buffers, but there are always at least two audio converters and one resampler) the change of CPU load between 60ms to 20ms packetisaztion is about 20% (try with Skype to believe), mostly located into the kernel, but also inside the udpsink/udpsrc and rtpbin. Maybe I could add a few diagrams to Felipe's once I retrieve my data, but I've some interesting considerations in the meanwhile..<br> <br>Now, in a perfect world the overhead generated from GStreamer when handling audio data should be O(n) wrt the amount of data, and O(1) wrt its packetisation. Since we know that (de)payloading is an expensive operation, I could still understand an algorithm which degrades with O(n) with the number of buffers, but Felipe's diagrams are clearly showing that the degradation is O(e^n) which grows faster than any polynomial function and, as they teach at the university, is bad (and Felipe's fiagram don't have neither payloaders nor rtp elements).<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> My "overly dramatic" graphs show the raw data for the most minimal example I could find, so it doesn't matter what you do, you'll get _at least_ that performance hit. On real use-cases (in the graph after 2^7), IMO the performance lost is already bad, but you have to<br> multiply that by the amount of different elements and thread contexts that are used.</blockquote><div><br>Just to confirm this, I'd like to publish a mean stream-engine audio pipeline and the CPU growth with different packetisations. Again, I hope to be able and take a few pictures from the laptop @ work.<br> <br>As it appears the most of the CPU growth is in the kernel (which doesn't seem to happen on x86) I believe something weird is going on with fast futexes on ARM. That is: the less mutexes, the less exponential CPU growth.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">However, the empirical experience is already there, ask<br> anyone in Nokia, I just wanted to show raw numbers.<br> <div class="im"><br></div></blockquote><div><br>:)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> > It sounds like when you mean size, you really mean duration and thus the<br> > amount of buffers per second.<br> ><br> > GStreamer is not designed to pass around 1 sample per buffer (that would<br> > be typically 48000 buffers per second), you can do it but it will incur<br> > a higher overhead that increases with the amount of elements in the<br> > pipeline.<br></div></blockquote><div><br>see my comments above: do you really think O(e^n) is a reasonable growth?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"> ><br> > GStreamer is however designed for more realistic buffer durations of<br> > 10ms (that's 100 buffers per second). The overhead that GStreamer causes<br> > in these types of pipelines depends on a lot of things, but in well<br> > designed pipelines you typically see overhead values of around 1% or<br> > less (callgrind and kcachegrind are good tools to measure this).<br></div></blockquote><div><br>The growth Felipe is showing happens as well with stream-engine pipelines, and a similar one has been measured with quite simpler ones, like the examples on:<br> <br><a href="http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-gstrtpbin.html">http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-gstrtpbin.html</a><br> <br>modified for audio-only and e.g. using g711 alaw. You can even test it with g729 on any architectures now ;) <br><br>..snip..<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div> ><br> > As a datapoint: On my desktop I can push around 700000 buffers per<br> > second, and that's then using 100% CPU (and also 100% gstreamer<br> > overhead). (gst-launch fakesrc num-buffers=7000000 silent=1 ! fakesink<br> > silent=1 takes about 10 seconds).<br> <br><br></div></blockquote><div><br>It appears ARM is not as much optimised as x86 wrt fast futexes (no references here :\, I have to dig more..) this meaning that GStreamer is not well optimised for that architecture. It would be interesting to propose an alternative way for read/write conflicts than bare mutexes.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> </div>On my laptop:<br> % gst-launch fakesrc num-buffers=7000000 silent=1 ! fakesink silent=1<br> 22s<br> <br> % gst-launch fakesrc num-buffers=7000000 silent=1 ! queue ! fakesink silent=1<br> 45s<br> <br> On my N900:<br> % gst-launch-0.10 fakesrc num-buffers=7000000 silent=1 ! fakesink silent=1<br> 4m 26s<br> <br> % gst-launch-0.10 fakesrc num-buffers=7000000 silent=1 ! queue !<br> fakesink silent=1<br> 16m 11s<br></blockquote><div><br>This is more or less an experimental confirmation of my statements above on ARM vs x86.<br><br>Regards<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> Cheers.<br> <br> --<br> <font color="#888888">Felipe Contreras<br> </font><div><div></div><div class="h5"><br> ------------------------------------------------------------------------------<br> Beautiful is writing same markup. Internet Explorer 9 supports<br> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.<br> Spend less time writing and rewriting code and more time creating great<br> experiences on the web. Be a part of the beta today.<br> <a href="http://p.sf.net/sfu/beautyoftheweb" target="_blank">http://p.sf.net/sfu/beautyoftheweb</a><br> _______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br> </div></div></blockquote></div><br>