I can tell you exactly what’s happening.
If you’re burning at 12x, then you’re pumping about 15 Mbytes per second into the burner. The IDE interface on most motherboards, even good ones, can’t do more than one thing at a time. It doesn’t multiplex the way SCSI interfaces do (and I doubt your friends have SCSI, though they might).
Your 120Gbyte drive may be able to supply about 30 to 50 Mbytes per second, but NOT while the burner is drawing it’s 15Mbytes per second. While the burner is drawing data, your IDE can’t supply data. This is simply the nature of IDE controllers.
Right now a small chorus is chiming in from the fields saying, “But his burner is on the second channel”. Well, very few IDE controllers have the ability to operate both channels simultaneously, so it actually won’t matter (unless you happen to have one that can).
Now, if you’re loading up IE during the burn, IE hits a few dozen DLL’s, which involve directory lookup. Since you’re burning, your disc cache is probably busy, so they’ll be disc reads, not cache reads, at first. All of this starves the data pump trying to make it’s way to your burner.
If you load IE before you start the burn, you’ll have little trouble - depending on what you browse and the speed of your Internet connection. A high speed connection might bring in gobs of material that must be written to the local browser cache, which will interrupt your data throughput some - probably not enough to cause much trouble though.
On the other hand, some popular P2P download software uses a flush for every batch of data it receives, which churns the hard disk, and causes the drive heads to thrash around quite a lot. This will have more effect on the ability of the drive to provide data to the burn than raw reading of data. For this kind of problem, it helps to put the receive directory on another drive from that which provides data to the burn. That way, the “switch” between the various download chunks and the source of the data for the burn is electronic, rather than physical (movement of the HD head). Same goes for browser cache, the temporary files and maybe even the paging file.
Also, you’ll do better if your source material is on the inner region of a hard disc than the outer region. On HD’s, the outer region of the drive reads data nearly half the speed of the inner tracks. This fact can be used to place the paging file on a second (or third) drive, where it gets the most speed, and perhaps the source material for your burn (though not on the same drive, perhaps).
Some people think that once a program is loaded, disc action is over. That’s not true. In all 32 bit windows, executables are NOT loaded into RAM upon execution. They are mapped as virtual memory. Execution actually begins BEFORE the program is loaded into memory. It is a page fault (the natural and normal action of virtual memory) that causes a page of the executable to load into RAM.
I point this out because when you run applications, then let them sit dormant for a bit, the program code may be “flushed” from RAM - meaning that upon execution of that code once again, a page fault will cause a reload of that virtual memory space. Cache flushing is virtually gauranteed during a burn, because you’re doing to run through more data than any cache will hold.
To this end, you’ll have a better time using Firefox than IE for browsing while burning, because it’s smaller.
For that matter, any application that uses CPU power with little disc activity will probably cause the burn little hassle, while anything that hits the disc for significant data will interrupt the burn (and the burn will be interrupting that application, too).
