HDD access prioritization - is it possible under WindowsXP?

[Konrad Klar]

Problem is such: I start e.g. "Compile DVD..." in DVDLab. Even if it is not CPU/memory-hungry operation it lasts several minutes and HDD is accessed nearly continously. At this time other programs that makes any (even small) HDD access are chocked.

Is any program/solution for WindowsXP that can accord higher priority of HDD access for programs that does not use it much, and lower for other programs?
Are such solutions implemented in Vista?

[Konrad Klar]

No one responded to my question. Bad luck...
Some information I have found here:
http://msdn2.microsoft.com/en-us/library/bb188739.aspx

I/O Prioritization

Another interesting optimization in Windows Vista involves prioritization of the I/O requests to the disk. There have been a lot of great innovations in the performance optimization space for PCs in the last decade or so. Multithreading, memory enhancements, CPU cores, and such have all contributed to faster performance of PCs. However, one place where innovation has been neglected is in disk access prioritization.

The problem is that while processes and threads have priority levels, the I/O requests they make do not. As such, a lower priority thread could issue a series of I/O requests that effectively block I/O requests of higher priority tasks. Windows Vista addresses this by adding a series of I/O prioritization strategies, including hierarchical, idle, and bandwidth-preservation. Details of these strategies may be found elsewhere, and are beyond the scope of this paper. However, the bottom line is that responsiveness is considerably better for I/O-heavy applications running on Windows Vista.

[jeffy]

Dear Konrad,

Thank you for your follow-up. It was a very interesting note on the topic. I was not able to find out anything more about HDD prioritization. If I may suggest something, due to the really low price of the drives today, do your DVDLab related work on another physical drive. You ought to be able to reduce the choking this way.

Regards,
Jeffy

[burfadel]

I haven't used DVDlab, but the answer to your question is a fairly simply one! When you click 'Compile DVD', the programme actually makes and writes the DVD image to your hard drive, then you can burn that image to the DVD drive. Direct burning of a non-compiled image to the DVD, that is, burning on the fly, may result in errors on the burnt disk due to uneven and inconsistent burning.

The CPU usage is low because its not a cpu intensive operation. Its basically copying the information to be burnt into the DVD image, which can be up to 8 or so GB depending on what type of DVD you are trying to burn. Hard drives are mechanical, and the heads need to move over the platters. For consistent reading the hard drive can manage up to 80MB/s or more, but for random read writes the speed can slow to slower than a flash drive. Thats why in Windows Vista readyboost is beneficial even if the read/write speed of the drive is only 5MB/s.

The speed of the compilation can only be increased by defragging your drive using a good defragger, to reduce random read/writes (contiguous file)

[Konrad Klar]

Dear Konrad,

Thank you for your follow-up. It was a very interesting note on the topic. I was not able to find out anything more about HDD prioritization. If I may suggest something, due to the really low price of the drives today, do your DVDLab related work on another physical drive. You ought to be able to reduce the choking this way.

Regards,
Jeffy

Thanks for suggestion. Problem is not resticted to DVDLab only. I don't want separate CPU or core for each CPU hungry program and separate for others. CCE or Prime95 running on low priority does not cause chocking of other programs with higher priority just thanks to CPU usage prioritization.
Regardless on how much HDD and CPU I may have installed in my computer in some moment all of them may be fully utilized and problem of lacking prioritization comes back.
I would be glad if appropriate solution would be exist also for WindowsXP (currently I use it).

Regards.

[burfadel]

What other situations is this a problem? Just asking to work out whether its a solveable issue, or just the hard disk drive issue I said earlier. If you're moving 4 GB around on the same drive (that includes partitions), it reads, the heads have to move,write, heads have to move back, read, etc etc. If the output compilation creation is on a different drive (physical, not partition) to the source, and the files are contiguous (that is, not fragmented, or at least not to a great extent), then the reading and writing can be consistent. This would be just over a minute to compile a full DVD using a rate of 70mb/s, if you have the latest fastest drive you can take another 7 seconds off that maximum. Thats in the best case scenario.

If its on the same drive, and especially ifs its fragmented its not as simple as taking twice the time due to seeking etc. You would have to allow 3 or 4 times more time depending on the amount the programme copies in one go. That would make a full DVD about 4 or 5 minutes to compile! That sounds right for what you're saying.

Now remember if you load or use other programmes when you're doing this, they too may need to access the disk to load or do their thing (even the open file dialog). The hard drive heads have to move to accomplish this, plus taking into account the reading/writing its slows it down considerable.

The only setting that may improve your performance in that regard is a setting that I'm not sure exists in XP. A lot of information, guides etc are around that are wrong apparently, or just assume its the case because it was on 95/98/Me. I am referring to the setting IRQ8Priority. IRQ 8 is the Interrupt Request used by the 'High precision event timer', which is different to what the guides say but is a related thing. It may be different on your computer, the IRQ may be used by the RTC.

Another setting of note is IOPageLockLimit

I suggest you look those two up, as theirs different information depending on where you look!

[foxyshadis]

Now remember if you load or use other programmes when you're doing this, they too may need to access the disk to load or do their thing (even the open file dialog). The hard drive heads have to move to accomplish this, plus taking into account the reading/writing its slows it down considerable.

This is exactly what HDD I/O prioritization is supposed to minimize, the common situation where something is monopolizing the disk and attempting to do anything else on the used disks virtually grinds it to a halt, especially when the system drive is affected. It's also useful for more reliable capturing and burning - but as you point out, you have to queue up the write eventually, and if you never have enough spare disk buffer, something's going to give. It's only useful if a gap in reading/writing was opened later when it would otherwise force its way into the capture.

Sure, you can't speed up same-disk copies in any useful way, but you can minimize or eliminate the painful latency of trying to use the disk while it's busy. (Even if that slows the copy itself down.) Of course disk latency is orders of magnitude higher than CPUs, but thread quanta has a 20-120ms granularity anyway, and multithreading still manages to work seamlessly to the user.

Sadly, I've never heard of anything that implemented it on XP, but I can almost guarantee it would require a driver to work.

[Konrad Klar]

Sure, you can't speed up same-disk copies in any useful way, but you can minimize or eliminate the painful latency of trying to use the disk while it's busy. (Even if that slows the copy itself down.)

Exactly. I'm not searching for method of speeding up DVDLab. I'm searching for method of unchocking of programs that makes small HDD access while DVDLab (or similar HDD access-eater) is doing disk operations. Knowing and accepting that in this case DVDLab's disk oparations will be slowdowned.