MB/s. This might require writing with large pieces, as extending a file may
become a bottleneck. Though NTFS applies an optimization to that.
liormessinger@gmail.com wrote:
Hi everyone,
I am facing a problem where Asynchronous I/O completion ports using it
might help me
but I'm still debating whether to start on this method of development.
I have to write a data (video) to a file, one frame at a
time. Currently I grab the frames on one thread, and perform all of
the file writes on a background thread. But - the writes still
slow down the whole machine.
Do you think that asynchronous I/O completion ports would help here?
if so, could you explain why? for me it seemed that they probably just
doing the same thing - doing the I/O operation on a different thread.
Or am I missing anything?
In a word, no. It's unlikely that using IO Completion ports would help
given that you have a single producer/single consumer model.
What generally does help, is to use FILE_FLAG_NO_BUFFERING, which requires
that you write disk-sector-aligned data, and do those writes using async
I/O (but not IO completion ports - they wouldn't help). If your data is
not naturally disk-sector blocked, then you'll prabably have to implement
a re-blocking scheme that copies parts of frames into large,
sector-aligned buffers (e.g. 64K or larger), starting writes on buffers as
they become full while simultaneously filling the next buffer with new
data.
You may simply be at the limit of your disk system as well, in which case
no amount of clever async programming is going to save you - you may
simply need a faster disk. How large are the frames and what's the frame
rate? For example, fuill resolution NTSC video requires 27Mb/s write
speeds - unless you have a fast RAID controller with multiple fast
SAS/SATA/SCSI drives, you won't get anywhere near that write speed for
more than a fraction of a second (long enough to fill up all the write
buffers on the disk(s)).
-cd