On Wed, Aug 1, 2012 at 5:39 PM, Stan Hoeppner <span dir="ltr"><<a href="mailto:stan@hardwarefreak.com" target="_blank">stan@hardwarefreak.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 8/1/2012 12:55 AM, Jason Newton wrote:<br>
<br>
>> Just to figure out for sure what the bottlenecks are and whether they can<br>
> be dealt with rather than looking at it as opaque system and assuming<br>
> nothing can be done. Also as a learning experience.<br>
<br>
</div>Jason, have you considered something like this to solve your problems?<br>
<br>
RAM is cheap. Far cheaper than attacking this problem with any other<br>
hardware type. And you can't easily solve it by rewriting to use AIO,<br>
given the effort involved with that.<br>
<br>
You should be able to fit 32GB of RAM on the board. Create a 24GB RAM<br>
disk and use that for writing your 5.7MB frame files in real time. This<br>
eliminates any latency and stutter issues during capture. Treat the RAM<br>
disk as a FIFO, taking each new file and copying it out to SSD after<br>
it's been closed, then delete the original. This gives you in essence a<br>
very fast buffer. If my math is correct, 24,000MB / 300MB/s = roughly<br>
80 seconds of buffer at a 300MB/s streaming capture rate, 40 seconds at<br>
600MB/s.<br></blockquote><div> </div><div>The system has a single slot of SODIMM. We have an 8GB DDR3 stick in it. I've added a circular buffer for each frame and limit it to some number of frames (so far 2 seconds, I haven't had time to experiment with it yet). The serialization thread is now separate and consumes the circular buffer so we're effectively talking about the same thing sans files. This solves the problem but as I mentioned before... I do have a desire to seek out the sources of the latency and cpu usage... I'm not really sure of how to go about it 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">
<br>
This should be very easy to implement, and cheaper than all other<br>
alternatives. It should eliminate all possible latency issues, though<br>
it will increase CPU cycles due to the data movement to/from the RAM<br>
disk, though how much I can't guess at this point. 8GB RAM disk will<br>
give you 26 seconds of buffering at 300MB/s, and a 4GB RAM disk will<br>
give you 13 seconds of buffering. If 13 seconds is sufficient, you can<br>
implement this on a machine with only 8GB RAM, assuming you need no more<br>
than 4GB for kernel/user space/application.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Agreed that it's the easiest and cheapest solution. Average performance probably won't change but burst of cpu will as it compensates for the high latency writes in future cycles... this is undesirable but I think OK (the important stuff is at high priority on SCHED_RR, these serialization threads are high priority SCHED_OTHER). Again, I haven't had time to test it as I've been putting out other fires.<br>
<br>-Jason<br></div></div>