From: Stan Hoeppner <stan@hardwarefreak.com>
To: Jason Newton <nevion@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: realtime section bugs still around
Date: Wed, 01 Aug 2012 19:39:16 -0500 [thread overview]
Message-ID: <5019CC34.5050003@hardwarefreak.com> (raw)
In-Reply-To: <CAGou9Mj=8xcF4YwaSQYp0_BbJW_Ms1sasDDRNxL1oh0oR7zupw@mail.gmail.com>
On 8/1/2012 12:55 AM, Jason Newton wrote:
>> Just to figure out for sure what the bottlenecks are and whether they can
> be dealt with rather than looking at it as opaque system and assuming
> nothing can be done. Also as a learning experience.
Jason, have you considered something like this to solve your problems?
RAM is cheap. Far cheaper than attacking this problem with any other
hardware type. And you can't easily solve it by rewriting to use AIO,
given the effort involved with that.
You should be able to fit 32GB of RAM on the board. Create a 24GB RAM
disk and use that for writing your 5.7MB frame files in real time. This
eliminates any latency and stutter issues during capture. Treat the RAM
disk as a FIFO, taking each new file and copying it out to SSD after
it's been closed, then delete the original. This gives you in essence a
very fast buffer. If my math is correct, 24,000MB / 300MB/s = roughly
80 seconds of buffer at a 300MB/s streaming capture rate, 40 seconds at
600MB/s.
This should be very easy to implement, and cheaper than all other
alternatives. It should eliminate all possible latency issues, though
it will increase CPU cycles due to the data movement to/from the RAM
disk, though how much I can't guess at this point. 8GB RAM disk will
give you 26 seconds of buffering at 300MB/s, and a 4GB RAM disk will
give you 13 seconds of buffering. If 13 seconds is sufficient, you can
implement this on a machine with only 8GB RAM, assuming you need no more
than 4GB for kernel/user space/application.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-08-02 0:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 8:14 realtime section bugs still around Jason Newton
2012-07-27 9:56 ` Stan Hoeppner
2012-07-30 3:03 ` Dave Chinner
[not found] ` <CAGou9MheeBWxajd65szNfDB2L+VVoZ7SypEdUKj7np3L0H8fHA@mail.gmail.com>
2012-07-31 23:01 ` Jason Newton
2012-07-31 23:46 ` Stan Hoeppner
[not found] ` <CAGou9MhneejOuhX4c8G06c3Zh7dxF-OtZ+=mT-7fho_u1Q3zWw@mail.gmail.com>
2012-08-01 3:55 ` Stan Hoeppner
2012-08-01 5:55 ` Jason Newton
2012-08-02 0:39 ` Stan Hoeppner [this message]
2012-08-02 2:38 ` Jason Newton
2012-08-02 10:39 ` Stan Hoeppner
2012-08-03 11:28 ` Stan Hoeppner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5019CC34.5050003@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=nevion@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox