I have two systems with fresh installations of Windows XP Pro SP3 (SP3 slipstreamed into the installer; fully updated after install). One's a refurbished 2.4GHz Pentium4 system; the other is a new 1.6GHz Atom330 build. Both have brand-new dual-layer CD/DVD burners (one's a LiteOn IDE, the other an LG SATA).

Both take a really looooong time to read a single-layer DVD in Windows with Cygwin tools.

Specifically, 40 minutes or more. I burn backup data to single-layer DVD+/-R and use MD5 hashes for data verification (made with the standard md5sum tool in Unix or Cygwin). The hashes are burned to disc with the data files, and I use this command to verify:

$ cd /path/to/disc/mountpoint ; time md5sum -c < md5.txt

Here's how long that takes to run on a full single-layer DVD+/-R disc:

  • Old system (WinXP SP2, 1.8GHz Athlon 2500+, last summer): ~10 minutes
  • Old system (Ubuntu 9.04, 1.8GHz Athlon 2500+): ~10 minutes
  • Old system (Debian 5, dual 550MHz P3): ~10 minutes
  • New Pentium4 system (running Ubuntu 9.04): ~5 minutes
  • New Pentium4 system (running WinXP SP3, file copy from Win Explorer): ~6 minutes
  • New Atom330 system (running WinXP SP3, file copy from Win Explorer): ~6 minutes

Now the weird stuff:

  • Old system (WinXP SP2, 1.8GHz Athlon 2500+, today): ~25 minutes
  • New Pentium4 system (running WinXP SP3, read from Cygwin): ~40-50 minutes (?!!)
  • New Atom330 system (running WinXP SP3, read from Cygwin): ~40 minutes
    (can do it in ~30 minutes ...if i have another program spin up the drive first)

Since both systems will copy files in 6 minutes using Windows Explorer, I know it's not a hardware problem. Windows just never spins up the drive during the Cygwin read, so it stays super-slow the whole time.

  • Other programs like EAC and DVD Decrypter seem to spin up the disc just fine during their processing.
  • DMA is enabled on both systems. (Can confirm in Windows' Device Manager on the Atom330, not on the P4.)
  • Nero's DriveSpeed tool doesn't seem to have any effect.
  • Copy times are comparable from commandline with Windows' xcopy. Copying with Cygwin's cp looks more like the problem state -- it will spin up the drive for a short time, never reaches full speed, and lets it spin back down again for most of the copy.

What I need is to get full read speeds from Cygwin. Is this a known issue with SP3 or some other recent Windows update? Any other ideas?

Update: More testing; Windows will spin up the drive when data is copied with Windows tools, but not when read in place or copied with Cygwin tools. It doesn't make sense to me that Windows spins up the drive for copying, but not for other reads. Might be more of a Cygwin problem?

Update 2: GUI activity is sluggish during the problem state -- during the Cygwin verifies, there's a slight but noticable delay when dragging windows or icons around on the desktop, switching windows, Alt-Tabbing through open applications, opening new windows, etc. It reminds me of the delay when opening a Windows Explorer window on My Computer just after inserting a DVD.

I've tried updating Cygwin (from 1.5.x to 1.7.x), but no change in the problem behavior.

I've also noticed this issue occurs on WinXP SP2, but it's not exactly the same -- some spin-up occurs, so the read happens in ~25-30 minutes instead of 40+. The SP2 system used to run the verifies in ~10 minutes, and when it first changed (not sure exactly when, maybe in late November or early December 2009) I thought it was dying hardware. This is why I suspect an official update of breaking this functionality; this has worked for years on that SP2 box.


You say DMA is enabled on both systems, but you don't specify where its enabled. If you mean its enabled in the bios that doesn't mean that windows is necessarily using it. Windows could revert to PIO mode after multiple failed burns or failed disk reads etc.

Can you confirm that windows is actually using DMA mode by checking the Advanced Settings tab of each IDE channel in Device Manager (Under IDE ATA/ATAPI controllers, on my Server 2008 machine). You should also be able to set it back to DMA mode from the same tab if it is in PIO mode.

  • confirmed for the SATA/AHCI system. the P4 doesn't actually offer an Advanced tab for the IDE channels -- it uses a Promise PCI IDE seen as a SCSI/RAID card by Windows, not as an IDE/ATAPI card, and there isn't actually a device for its channels in Windows. since DMA is confirmed on the one and well-hidden on the other, and performance is nearly identical, i'm guessing DMA ain't the problem. Jan 12 '10 at 18:49
  • confirmed on the P4 as well, when i attach the drive to the motherboard's IDE interface. Jan 12 '10 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.