utsav
damn busy...
most of us using optical drives and hard drives sometime or the other have to bear the problem of the transfer mode being changed from UDMA to pio.It is very irritating because the cpu usage shoots up to almost 100% and no multi tasking is possible.
So have no fear because UTSAV is here.
I will give a step by step tutorial to change the transfer mode to UDMA from pio without reinstalling windows.
There are also some registry hacks so use them at your own risk.
to open registry editor goto start then click on run and type in 'regedit' except the quotes. press enter.
For optimum transfer efficiency, the IDE channels should be using UDMA (Ultra Direct Memory Access) and not PIO Mode (Programmed Input/Output). But Windows frequently decides on many systems to use the latter.
So what’s the diff between the major transfer mode groupings? It’s most importantly about what hardware in your system is providing the grunt for data transfers:
Mode
Explanation
PIO
Programmed Input / Output
The CPU manages the transfer of data between system memory and the storage device. Supports bus speeds up to 16MB/sec, if your processor can keep up. Nothing built this century should be using PIO.
DMA
Direct Memory Access
The bus-mastering system controller (a.k.a. DMA controller) is programmed to manage the transfer, freeing the CPU to do other stuff while the DMA controller does its thing. It’ll also support bus speeds up to about 16MB/sec.
UDMA
Ultra Direct Memory Access
A modern (I think 64-bit?) version of the DMA method. It’s the current standard for high speed storage devices with bus speeds up to 100MB/sec.
A maddeningly understated problem arises with how Windows locks down what it thinks is the best transfer mode for each of your IDE devices. After the initial hardware detection, XP keeps a running tally of the number of times a drive fails access attempts. When this cummulative number reaches six, it reduces the compatibility mode and tries again. At first XP will try downgrading within the same transfer method, eg: from UDMA Mode 4 to UDMA Mode 3, but when these sublevels run out it will assume DMA is no longer available and permanently fail back to PIO Mode, because the transfer mode tweaking is one way (downwards)
SYMPTOMS:
When should you be sus that PIO Mode has become your permanent transfer method on one or all of your IDE devices?
Symptom
Explanation
PIO Mode is specified in the Device Manager and refuses to switch back to UDMA Mode.
(IF YOU DON’T HAVE THIS SYMPTOM, DON’T BOTHER WITH MY FIX, DINGLEBERRY)
Well yeah, that’s a giveaway. There are settings in the Device Manager’s IDE/ATAPI Configuration that are supposed to let you select between “PIO” (why!) and “DMA if available.” “PIO” is automatically specified here after a transfer mode failback. You can’t change it back to “DMA if available” though: according to the system, DMA is now not available so the “Current Transfer Mode” will permanently & infuriatingly say “PIO”.
Explorer.exe locks up and/or crashes during file transfers. Desktop icons & Taskbar crash & vanish for ½ min. Some Sys Tray icons don’t reappear.
I frequently move files from an incoming drive to an archive drive prior to burning, as this performs a quick defrag of the highly segmented files that have been downloading. With large files this incapacitates Explorer for six or seven minutes at a time (based on a 200MB file) if PIO is engaged. Even refreshing the views of other apps is a supreme test of patience with non-CPU intensive programs bowing before the lumbering efforts of Explorer, redrawing the screen line by painstaking line.
All tasks (not just Explorer) accessing the drives seem highly CPU intensive.
Explorer is a good example again, using 90-95% of my main CPU during file transfers instead of 3-5%. Nero tends to use about the same instead of about 10-15% during DVD burns. MediaPlayer frequently hit 99% when trying to play back video files situated on a PIO drive. (Also, before killing the Windoze “Prefetch” - more on that issue which can also trigger a failback later - certain file types the cursor touched in Explorer stayed file-locked for about 30-60 seconds before they could be moved / deleted / renamed. The Prefetch and PIO issues seem to inflame each other.)
Buffer under-run failures during burns, or the buffer continually runs dry on burnproof drives.
When the hard drives fail to PIO mode, my 25MB/sec drive is reduced to 2½MB/sec and my 16MB/sec drive is reduced to 1½MB/sec. (Nero was used to benchmark the drives.) Since DVD 1x spin is 1.3MB/sec this was causing all sorts of malarkey during burns, with burning programs locking up, or the resultant disc being damaged. It was taking 1½ hours to burn 4.7GB and another hour to verify, and heaven help me if I wanted to use the PC for anything else in the meantime! 1x spin burn should only take 54 minutes to write and 12 mins to verify on my system, and the PC can do most other things besides videos and high-end computer games at the same time.
Severely reduced video-DVD playback quality.
choppy images and seeking almost impossible
Go to..
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0]
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1]
Notes: These keys are called SCSI solely for historic reasons; SCSI Port 0 is actually IDE1 and SCSI Port 1 is IDE2.
Modify..
DMAEnabled = 1 (DWORD value) note(select decimal)
Notes: This is usually set to zero after a PIO failback. Some systems may change your “1” to a “3” after a reboot - it seems to depend on how heavy your computer is already with DMA-enabled hardware. One of my machines’ drives default to DMA3 and doesn’t seem to act any differently,
Go to..
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002]
Notes: 0001 is the key for IDE2 and 0002 is the key for IDE1, go figure. The string associated to MatchingDeviceId will tell you for sure what you’re looking at (ie: “primary_ide_channel” or “secondary_ide_channel”. If you don’t know what those basic nuts & bolts terms are, I really really really think you should stop what you’re doing RIGHT NOW.) Also, you don’t need to remember that entire long-winded numbered key, 4D36-etc… I just scan the fourth octet of the first dozen Class keys for “6A” (as underlined in the blue text above).
Delete..
MasterIdDataCheckSum
SlaveIdDataCheckSum
Notes: If you don’t see a checksums associated with a particular slot, then there’s no device detected. If you can’t work out which slot goes with which drive, well, that gives me misgivings about you messing about in RegEdit, but it doesn’t matter if you simply delete all the checksums in the 0001 and 0002 keys (there can be a max of two devices for IDE1, two for IDE2). At the next login, WinXP will notice something is up when the detected devices don’t match the checksum flags and the device’s capabilities will be re-examined.
Delete..
MasterDeviceDetectionTimeout
SlaveDeviceDetectionTimeout
Notes: Delete these keys if present, if you have a device that is not detecting or doesn’t already have a checksum associated with it. If there’s a timeout=1 flag, Windoze doesn’t bother detecting for a device in that slot at login. Again, this is just a detection flag, so it doesn’t matter if you delete them willy-nilly; if there truly is no device there, the timeout key will simply be recreated at next login. If you still have access to a hard drive that has a timeout flag like this, chances are it’s running in the crippled “Dos Compatibility Mode” where XP is basically fudging your connection to it in real time. I think you are told this under Device Manager > Disk Drives > (appropriate device) > General Properties tab, and also with a warning message at login. If it is a newly installed device, you may have also forgotten to assign a partition and/or drive letter to it using the Microsoft Management Console: Start > right-click My Computer > Manage > Storage folder > Disk Management console. Not recommended for n00bs! Very dangerous!
Create..
ResetErrorCountersOnSuccess = 1 (DWORD value)
Notes: If this flag is present, the running tally of device access failures is reset to zero after every successful access. (I mentioned earlier that a transfer mode downgrade is triggered after a sixth cummulative failure.) Hopefully, this will lengthen the time before your next PIO failback as you’ll need six consecutive failures to trigger it.
ADDENDUM – Microsoft finally released a "patch" for the failback behaviour. However, after minimal scrutiny all this atapi.sys upgrade really does is change the trigger requirement of six cummulative fails to six consecutive, which is what we've been doing for ages with this reseterrorcounters flag anyway. *sigh*
/
Reboot..
Notes: After you’ve rebooted, go back into the IDE settings and see if DMA is available now. If the Current Transfer Mode is still PIO, then I wash my hands of you.
I am attaching a screenshot of the registry editor which might help you.I am giving the link.
*www.thinkdigit.com/forum/attachment.php?attachmentid=842&stc=1&d=1178949891
please rate my tutorial if its of any good to you.
So have no fear because UTSAV is here.
I will give a step by step tutorial to change the transfer mode to UDMA from pio without reinstalling windows.
There are also some registry hacks so use them at your own risk.
to open registry editor goto start then click on run and type in 'regedit' except the quotes. press enter.
For optimum transfer efficiency, the IDE channels should be using UDMA (Ultra Direct Memory Access) and not PIO Mode (Programmed Input/Output). But Windows frequently decides on many systems to use the latter.
So what’s the diff between the major transfer mode groupings? It’s most importantly about what hardware in your system is providing the grunt for data transfers:
Mode
Explanation
PIO
Programmed Input / Output
The CPU manages the transfer of data between system memory and the storage device. Supports bus speeds up to 16MB/sec, if your processor can keep up. Nothing built this century should be using PIO.
DMA
Direct Memory Access
The bus-mastering system controller (a.k.a. DMA controller) is programmed to manage the transfer, freeing the CPU to do other stuff while the DMA controller does its thing. It’ll also support bus speeds up to about 16MB/sec.
UDMA
Ultra Direct Memory Access
A modern (I think 64-bit?) version of the DMA method. It’s the current standard for high speed storage devices with bus speeds up to 100MB/sec.
A maddeningly understated problem arises with how Windows locks down what it thinks is the best transfer mode for each of your IDE devices. After the initial hardware detection, XP keeps a running tally of the number of times a drive fails access attempts. When this cummulative number reaches six, it reduces the compatibility mode and tries again. At first XP will try downgrading within the same transfer method, eg: from UDMA Mode 4 to UDMA Mode 3, but when these sublevels run out it will assume DMA is no longer available and permanently fail back to PIO Mode, because the transfer mode tweaking is one way (downwards)
SYMPTOMS:
When should you be sus that PIO Mode has become your permanent transfer method on one or all of your IDE devices?
Symptom
Explanation
PIO Mode is specified in the Device Manager and refuses to switch back to UDMA Mode.
(IF YOU DON’T HAVE THIS SYMPTOM, DON’T BOTHER WITH MY FIX, DINGLEBERRY)
Well yeah, that’s a giveaway. There are settings in the Device Manager’s IDE/ATAPI Configuration that are supposed to let you select between “PIO” (why!) and “DMA if available.” “PIO” is automatically specified here after a transfer mode failback. You can’t change it back to “DMA if available” though: according to the system, DMA is now not available so the “Current Transfer Mode” will permanently & infuriatingly say “PIO”.
Explorer.exe locks up and/or crashes during file transfers. Desktop icons & Taskbar crash & vanish for ½ min. Some Sys Tray icons don’t reappear.
I frequently move files from an incoming drive to an archive drive prior to burning, as this performs a quick defrag of the highly segmented files that have been downloading. With large files this incapacitates Explorer for six or seven minutes at a time (based on a 200MB file) if PIO is engaged. Even refreshing the views of other apps is a supreme test of patience with non-CPU intensive programs bowing before the lumbering efforts of Explorer, redrawing the screen line by painstaking line.
All tasks (not just Explorer) accessing the drives seem highly CPU intensive.
Explorer is a good example again, using 90-95% of my main CPU during file transfers instead of 3-5%. Nero tends to use about the same instead of about 10-15% during DVD burns. MediaPlayer frequently hit 99% when trying to play back video files situated on a PIO drive. (Also, before killing the Windoze “Prefetch” - more on that issue which can also trigger a failback later - certain file types the cursor touched in Explorer stayed file-locked for about 30-60 seconds before they could be moved / deleted / renamed. The Prefetch and PIO issues seem to inflame each other.)
Buffer under-run failures during burns, or the buffer continually runs dry on burnproof drives.
When the hard drives fail to PIO mode, my 25MB/sec drive is reduced to 2½MB/sec and my 16MB/sec drive is reduced to 1½MB/sec. (Nero was used to benchmark the drives.) Since DVD 1x spin is 1.3MB/sec this was causing all sorts of malarkey during burns, with burning programs locking up, or the resultant disc being damaged. It was taking 1½ hours to burn 4.7GB and another hour to verify, and heaven help me if I wanted to use the PC for anything else in the meantime! 1x spin burn should only take 54 minutes to write and 12 mins to verify on my system, and the PC can do most other things besides videos and high-end computer games at the same time.
Severely reduced video-DVD playback quality.
choppy images and seeking almost impossible
Go to..
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0]
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1]
Notes: These keys are called SCSI solely for historic reasons; SCSI Port 0 is actually IDE1 and SCSI Port 1 is IDE2.
Modify..
DMAEnabled = 1 (DWORD value) note(select decimal)
Notes: This is usually set to zero after a PIO failback. Some systems may change your “1” to a “3” after a reboot - it seems to depend on how heavy your computer is already with DMA-enabled hardware. One of my machines’ drives default to DMA3 and doesn’t seem to act any differently,
Go to..
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0002]
Notes: 0001 is the key for IDE2 and 0002 is the key for IDE1, go figure. The string associated to MatchingDeviceId will tell you for sure what you’re looking at (ie: “primary_ide_channel” or “secondary_ide_channel”. If you don’t know what those basic nuts & bolts terms are, I really really really think you should stop what you’re doing RIGHT NOW.) Also, you don’t need to remember that entire long-winded numbered key, 4D36-etc… I just scan the fourth octet of the first dozen Class keys for “6A” (as underlined in the blue text above).
Delete..
MasterIdDataCheckSum
SlaveIdDataCheckSum
Notes: If you don’t see a checksums associated with a particular slot, then there’s no device detected. If you can’t work out which slot goes with which drive, well, that gives me misgivings about you messing about in RegEdit, but it doesn’t matter if you simply delete all the checksums in the 0001 and 0002 keys (there can be a max of two devices for IDE1, two for IDE2). At the next login, WinXP will notice something is up when the detected devices don’t match the checksum flags and the device’s capabilities will be re-examined.
Delete..
MasterDeviceDetectionTimeout
SlaveDeviceDetectionTimeout
Notes: Delete these keys if present, if you have a device that is not detecting or doesn’t already have a checksum associated with it. If there’s a timeout=1 flag, Windoze doesn’t bother detecting for a device in that slot at login. Again, this is just a detection flag, so it doesn’t matter if you delete them willy-nilly; if there truly is no device there, the timeout key will simply be recreated at next login. If you still have access to a hard drive that has a timeout flag like this, chances are it’s running in the crippled “Dos Compatibility Mode” where XP is basically fudging your connection to it in real time. I think you are told this under Device Manager > Disk Drives > (appropriate device) > General Properties tab, and also with a warning message at login. If it is a newly installed device, you may have also forgotten to assign a partition and/or drive letter to it using the Microsoft Management Console: Start > right-click My Computer > Manage > Storage folder > Disk Management console. Not recommended for n00bs! Very dangerous!
Create..
ResetErrorCountersOnSuccess = 1 (DWORD value)
Notes: If this flag is present, the running tally of device access failures is reset to zero after every successful access. (I mentioned earlier that a transfer mode downgrade is triggered after a sixth cummulative failure.) Hopefully, this will lengthen the time before your next PIO failback as you’ll need six consecutive failures to trigger it.
ADDENDUM – Microsoft finally released a "patch" for the failback behaviour. However, after minimal scrutiny all this atapi.sys upgrade really does is change the trigger requirement of six cummulative fails to six consecutive, which is what we've been doing for ages with this reseterrorcounters flag anyway. *sigh*
/Reboot..
Notes: After you’ve rebooted, go back into the IDE settings and see if DMA is available now. If the Current Transfer Mode is still PIO, then I wash my hands of you.
I am attaching a screenshot of the registry editor which might help you.I am giving the link.
*www.thinkdigit.com/forum/attachment.php?attachmentid=842&stc=1&d=1178949891
please rate my tutorial if its of any good to you.
