Hi,<br><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 8:56 PM, Gruenke, Matt <span dir="ltr"><<a href="mailto:mgruenke@tycoint.com">mgruenke@tycoint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div link="blue" vlink="blue" lang="EN-US">
<div><div class="im"><p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">> </span></font>Felipe's diagrams are
clearly showing that the degradation is O(e^n)</p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
</div><p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Actually, that’s not clear to me, as
his plot was log(x), y. That’s why I asked about plotting
throughput vs number of elements or queues. Even using a linear x axis
would be more enlightening.</span></font></p></div></div></blockquote><div><br>right, I should have checked the scales and your email as well before highlighting an exponential growth. Still the point of the growing complexity wrt the number of buffers keeps, and also the difference in the curve between ARM and x86 is something which deserves more than one though. <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 link="blue" vlink="blue" lang="EN-US"><div>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">I also agree with Wim that the effects of
the queue are exaggerated in a trivial pipeline on an idle system. In
higher-load situations, you would tend to have fewer context switches, which
are probably the largest cost.</span></font></p></div></div></blockquote><div><br>I'd like to check whether similar effects are present even with elements like resamplers with the same caps on sink and source pads.<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 link="blue" vlink="blue" lang="EN-US"><div>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">I think a lockless queue wouldn’t
help with this scenario, since you’d still want to wake up a consumer
that’s waiting on an empty queue (which requires a lock + condition
variable). Where lockless helps is to scale throughput in higher load
scenarios.</span></font></p></div></div></blockquote><div><br>well, I was considering something more radical than removing locks only from the queue. I have to search a simple patch were I removed all of the locks from pad_push, getting measurable benefits (I'm not proposing it as a solution, but something to reflect about). For sure, I'll be talking just about fresh air until I'm able to provide a few diagrams, I know :P.<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 link="blue" vlink="blue" lang="EN-US"><div>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">If you could afford some latency, then
perhaps batching could be implemented by having the consumer block until the
queue either reaches some watermark or a timeout expires. When either of
these conditions is met, the consumer empties out the queue and goes back to
waiting.</span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p></div></div></blockquote><div><br>GStreamer VoIP latencies are already proven to be at the limit with many standard and industrial requirements, at least on ARM (to be fair, it's also because of pulse and its interfaces). I wouldn't suggest to go for solutions which involve bigger latencies.<br>
<br>Regards <br></div></div>