Did a recent WinXP update break CD/DVD read speeds? SP2/SP3
- by quack quixote
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.
