I previously posted on my latencies and that I would update my simulation program a bit more (to cap it to my actual framerate rather than going as fast as throughput allows.<br><br>I've updated the simulation and it turns out it drops just as often as before, despite operating at 60fps rather than ~150fps. I get an ocational dropping of 8 frames which means 400+ms delay in the write calls. Then things are just fine for a while, until I miss 8 again. I multithreaded the stream write calls since that's what I do currently in the real program but I disabled openmp and the numbers are all the same with or without. iotop reports 330-350mB/s of write activity and htop reports 70-92% cpu usage.<br>
<br>[10:30:33.386036000] [6] min: 11ms max: 472ms avg: 14.1086799ms std: 8.1730857ms count = 6648 dropped: 16 transferred: 36.65G totaltime: 333166ms<br><br>I've attached my benchmark program but I use alot of boost c++ with a little internal set of libraries... so you can see what I"m doing but it likely won't compile for you. I'll also mention that boost is a very low overhead (if any) over all the normal system calls one would use (verified by reading sourcecode in use).<br>
<br>So I'll end on the same question: any ideas on how to squash out that occational 400+ms latency? Dropping down cpu usage? Should I just record to the raid directly without a filesystem? I guess that could be an interesting test to run tomorrow...<br>
<br>-Jason<br>