Jump to content

cutandpaste

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by cutandpaste

  1. Well, sorta. It was kinda asked, and rather dismissed in that thread. Nobody made any mention of any of the buffering techniques that I proposed above. The author's prediction that the HDD would be going nuts would be largely mitigated if imgburn were using a more efficient buffering system, which it doesn't seem that he had considered at that time. Therefore, I feel it bears asking again. My method reduces necessary hard drive seeks during a dual-image burn from a single HDD from thousands to dozens, and in doing so will allow far more parallel throughput from disk.
  2. First, thanks for the excellent software. Would there be any future possibility of improving the buffer routines to enable recording ISOs to multiple burners from a single hard disk? I often find myself with a directory full of ISOs which need burned, and while queue mode works quite well with a single burner, it falls short beyond that. It seems to me that my hard drive is plenty fast enough to feed at least a couple of different simultaneous burns, as long as the disk reads are somewhat linear. But firing up two instances of imgburn doesn't buffer things in a very kind way, and the disk is kept busy shuffling its head back and forth instead of actually reading data. The end result is that burning two things at once results in far slower times than burning them one at a time, along with a whole lot of buffer underruns. It'd be nice if this were improved. One way to accomplish this, I think, would be an option to always read data from disk in big (several hundreds of megabytes) chunks, along with some sort of locking mechanism to ensure that no more than one imgburn process is reading this chunk from the same hard drive at the same time. In this way, the disk contention is kept to a minimum and reads will be mostly linear. This would accomplish what I'm after, but would be more difficult to manage (I'd have to create one queue for each burner). Another (better) way would be to use the above large-read-ahead-with-locking technique, while simply being able to select multiple burners from within the queue screen. This would almost certainly be harder to implement, but far easier and more obvious to use. The only problem I can see with the latter option (other than the difficulty in implementing it) is that it might make it too obvious, and cause confusion and ire amongst users with slow systems, limited RAM, or slow/badly fragmented disks who don't understand why their burns take longer with two burners than with one. Forcing users to enable this feature in the config menu would go a long way toward solving this little issue, if you think it's a real concern. But for my own purposes, RAM is cheap and plentiful, while hard drives these days have silly-fast linear read speeds. I'd be very happy to give imgburn a gigabyte or two of RAM if it could cut my burn time in half, and I'm sure I'm not the only one...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.