[chasg]

Hi All,

As I sit here with my G5 moving a couple of hundred gigs from one disk to another (internal SATA to external firewire 800) and me unable to really do anything else, I find myself wonder why copying always takes so much of the CPU procesing power. It doesn't matter how big the copy is, the graphs always show extended spikes when OSX is doing copies.

What's up with that, how hard can it be to move bits and record where they're going?

Just buggin' me.

Chas

[ghporter]

For one thing, the CPU has to translate and buffer the data from the source's buffer to the destination's buffer. Those in and out buffers are not likely to be the same size, and remember that to go to the external drive, the data has to be formated differently from the way it would be if it was just going to another internal drive, so there's the translation.

[Thinine]

I've never noticed my large Firewire 400 transfers taking an inordinate amount of CPU. Or large network transfers.

[msuper69]

Originally Posted by ghporter

For one thing, the CPU has to translate and buffer the data from the source's buffer to the destination's buffer. Those in and out buffers are not likely to be the same size, and remember that to go to the external drive, the data has to be formated differently from the way it would be if it was just going to another internal drive, so there's the translation.

How do you figure it works that way?

Unless things have changed in the last 10 years or so, the CPU only executes the instruction that tells the disk controller where the data to transfer is located and how many bytes to transfer. The CPU does not take part in the actual data transfer.

Nothing has to be translated. What do you mean?

[ghporter]

The CPU still has to mediate between the two systems. An external firewire drive has to go through the firewire controller, and the CPU does have to make sure that the process runs, that the buffers don't over or underflow, and that the data outgoing to the firewire controller is properly formed.

I'm not saying that this in itself is what's causing the huge CPU usage, but any data movement from an internal source to an external destination is going to be at least somewhat slower than an equivalent transfer between internal devices.

[Since EBCDIC]

Oh, I am *so* glad someone's mentioned this.

Whenever I copy digital pictures from an SD card (mounted via PCMCIA) my G4 1.5 GHz Al PB comes screaming to a halt. Virtually nothing happens in the Finder GUI during the copy.

My workaround is to clean up the camera just as I join the kids for breakfast. 1 GB 'o pix takes 7 minutes, and I can work normally after the eats are done.

Still, I don't recall this happening before some recent version of Tiger, say three or five months (perhaps).

[wataru]

I find that copying large amounts of data over USB makes my system slow to a crawl. FireWire, on the other hand, doesn't seem to be too big a hit.

[wuzup101]

Hum, I've never noticed much of a slowdown while burning DVDs over firewire or transfering large video files to my external HDD via usb2.0. They probably are there, I just never seemed to notice.

[walkerjs]

I would gather that the slow down isn't because the copy is CPU bound, but rather because it's I/O bound. There are probably plenty of GUI actions that require quite a bit of bandwidth on the data bus which there is plenty of when not copying. When a copy is taking it all up you feel it by slowdowns or outright freezes. I've noted that there are times when CPU is taken up nearly 100% by something (usually firefox back before I went to Safari) and there is no perceptible slowdown of GUI functions even though the CPU is probably glowing red hot.

Burning CDs and DVDs don't slow down the GUI as much because they have a fixed speed at which data can be written, and this probably doesn't take up nearly as much bandwidth because the system has to feed out data at a steady stream, but during a copy from one fast device to another it's pushing as much through as it can sacrificing your other work.

[Millennium]

Copying uses as many free CPU cycles as it can, so that barring I/O issues the copy can take place as quickly as possible. However, last I checked, copying was not a particularly high-priority task. If almost any other application needs those cycles, the OS will take them from the copy and give them to the app that needs them.

You can test this for yourself, in fact. Start up a CPU-intensive task, such as playing a movie, and watch its CPU usage. While you're doing that, start a large file copy; something that's likely to take a few minutes so you can get a good look over time. The copy is likely to use whatever's available, but it shouldn't take cycles away from the movie, and so there shouldn't be much if any actual slowdown.

Bottom line: yes, the copy takes up many CPU cycles if you're not doing anything else, but since you're not doing anything else that isn't a problem. If you need those cycles for something else, you'll get them.

[JKT]

Another thing to consider - have the drives been indexed by Spotlight yet? If that is going on at the same time, you are going to see excessive CPU usage. Either exclude the drive from being spotlit if you are constantly changing the data on it, or make sure it is indexed fully.