followup on benchmarks of an xfs embedded system (without rt section)

[Jason Newton]

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.

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.

[10:30:33.386036000] [6] min: 11ms max: 472ms avg: 14.1086799ms std:
8.1730857ms count = 6648 dropped: 16 transferred: 36.65G totaltime: 333166ms

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).

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...

-Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20120727/55ffae81/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iobench.cpp
Type: text/x-c++src
Size: 10070 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20120727/55ffae81/attachment-0001.cpp>