Faster is not always better

[Congdm]

A few weeks ago, my hard disk crashed so I have to using my old 10 GB backup hard disk. Using hard disk benchmarking software, I got some information about it speed: Running at UDMA-66, Read sequential speed 16 MB/s, Read cache speed 66 MB/s. File copying, file decompressing were slow but I noticed no GUI or applications delay, latency or lag.

Last week, I bought a dirt cheap 40 GB ATA Hard disk. This disk run at UDMA-100, Read sequential speed 50 MB/s, Read cache 80 MB/s. I use a PCI ATA RAID card, 815 mainboard with 512 PC133 SDRAM, so I guess 80 MB/s is the maximum I can get from my system.

This hard disk of course performs better than the old hard disk in file copying but GUI and applications are lagging when file copying happens.

I think the main reason is: The DMA channel is working at maximum capacity, it steals a lot of memory access time from CPU so the latency of the other applications is worse. Am I wrong?

[Combuster]

I quickly looked up the i815, it seems to have a memory bandwidth of 400MB/s. Your harddrive will still not be stealing more than 20% of it and the cache should provide enough for the rest of it.

However at 50MB/s assuming 64-sector transfers you end up with 1500 harddisk interrupts per second and an equal number of resulting context switches and driver invocations. That also interferes with your scheduling, and the interrupts are likely to happen in a different task's context than the process that is waiting for the data to be read.

[turdus]

I think the main reason is: The DMA channel is working at maximum capacity, it steals a lot of memory access time from CPU so the latency of the other applications is worse. Am I wrong?

Wrong, the whole idea of DMA is not to use CPU. When a device is working, cpu can handle different things, as soon as it finishes, it will interrupt the cpu to process the data from device, and no memory access for that buffer is made by the cpu before that. I'd assume parsing the data is more time consuming than the freq of interrupts on your new fast device, that's why apps lag (so the ISR takes more time to complete than the controller to locate and load a sector into memory. Meaning the ISR haven't finished by the time the next interrupt would fire, causing accumulation, which makes the kernel to increase priority of overloaded task, that ultimately leads to inresponsible system). But I'm just guessing.

[JamesM]

No; while the dma engine is using memory, the CPU cannot. That is his point. This would affect io bound applications such as gui stuff more than compute bound.

[Congdm]

Combuster, you are so right! There is no way the DMA Busmaster can steal all the memory bandwidth. I rechecked everything and found the culprit.

I forgot that I had compressed the NTFS partition... I create 2 new folders that aren't compressed, and then copy file between 2 folders. Now, the web browser doesn't lag anymore. The reason that the slow hard disk doesn't cause lag is it only feeds 16 MB to the CPU each second to decompress.

But what make I puzzled is why Windows NT need to decompress in order to copy compressed file inside a compressed partition? So ineficient.

[bluemoon]

That's the philosophy of windows - If you think about how they handle installation - they feel good when the same file copied THREE times around(*), decompress during copy sound comfortable.

1) copy the installation source file to temp
2) extract the temp file into yet another temp
3) copy the extracted file to destination (instead of move)


The equally bad design goes for IE download - it download to temp, and copy to destination even they are on the same drive.