Note that mbuffer is the RAM FIFO, and it was empty all the time (as one could expect). Since mbuffer never blocked, I don't think it matters how good the pipe between them is. This is why I found it weird that I got delays at all, using a RAM FIFO.mknod mypipe p mbuffer -i mypipe -o /fatfs/output-file & ./writefat mypipe > listfileUntil 2.6.mumble, pipes only used a single page in memory. Since 2.6.mumble we're using up to 16 pages and flipping between consumer and producer, which should give much better pipe utilization for large writes.
Are these general guidelines for writing fast I/O, or are there good reasons to suspect that one of these cause occasional long blocks? Keep in mind that 3 MB/sec isn't fast at all. It's not like I care about a long average delay. It's the peaks.- use write, not fwrite!!! - use DIRECT_IO to bypass kernel caching - use the appropriate IO elevator
Besides, it's all nice when I write the application myself. But usually what we do is to use some prewritten software. In my case I could hack it (as I've already done for other reasons). But still this looks like a kernel problem to me.
Yes, the DMA is on for both computers. And at least on the laptop, there shouldn't be anything running (not even X).- verify that your disk drivers are tuned for whatever you want to do (is DMA on?) - what else is the system doing? is it idle? busy? is anything else interfering with the scheduling of your program?
Well, as it turns out, it's not so good for a rather mainstream multimedia recording task. At least not on my computers. I don't need optimal. I need reasonable.Linux is a general purpose OS, which means it's good for a lot of things and optimal for none.
It would be nice if some of you tried the program I sent, and let's see if you get the same results. Note that the real action begins when the partition you write to is getting full.
Regards,
Eli
--
Web: http://www.billauer.co.il
