|Subject:||followup on benchmarks of an xfs embedded system (without rt section)|
|From:||Jason Newton <nevion@xxxxxxxxx>|
|Date:||Fri, 27 Jul 2012 03:35:40 -0700|
|Dkim-signature:||v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O/mQUOX/Ht1QLG2RwgtYNU3FIKmDdagafGvkAny34A8=; b=y6E7BVitBhCgcjnsg32pzq8Keft8aYfmJVaPHxva80yNNGFDeCuhFLhZROqHEZdznk /0GpbIuExv/3xiDchTswEMFBwja/rmkZNPRh7iXTm5V6Eyp3PCKm45l0PC2LI257eQSR wkZziyXUZPo3hyflxNOJF3Q8RVpD6jJOUbMGm7Z3KFh+26y1lxqHBza5FwXyQLObv31d 4cotytMlfiK30jm78eZ1WHab8eV2tL1raGgn7OZ2YfDWnwG0psXQSsaTpcvz6U62DHjn xKmvK9U83YmhohxlxBfeoWpYiem88uXIqr3In5sGh5Vc8MvaCWxmzHkdtGWaS6lyc4A1 T8Jg==|
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]  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...
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: realtime section bugs still around, Stan Hoeppner|
|Next by Date:||Re: [PATCH v5 1/4] xfs: Remove type argument from xfs_seek_data() and xfs_seek_hole()., Mark Tinguely|
|Previous by Thread:||realtime section bugs still around, Jason Newton|
|Next by Thread:||Re: followup on benchmarks of an xfs embedded system (without rt section), Dave Chinner|
|Indexes:||[Date] [Thread] [Top] [All Lists]|