Calendar

[Smither]

I was actually thinking more of "What can you do?" than "How fast?"

[Mad Penguin]

As in "how many things can you do at the same time?" ??

[Smither]

No, just how fast you can get an application to run for how much effort and how you would go about it. I keep thinking back to that psychologist who wanted a super low latency program and you said about running programs without being in a Gnome or X-term or KDE or whatever session.

[Mark Greaves (PCNetSpec)]

Surely dd isn't the best way to copy "files"... won't it also be copying empty blocks?

[Mad Penguin]

How fast you can copy files will be 99% dependant on your disk(s) unless you have a 'really' old machine.

Pretty much all computers in recent history are capable of DMA transfers. Essentially the cpu sends track , sector, byte count & memory location info to the disk controller, then goes off to do something else. The disk controller transfers the required information to the requested location, then sends an interrupt to the CPU to tell the computer the transfer is complete.

Note than in this scenario running a GUI etc is unlikely to have much impact on the time taken to copy files unless it's eating all the CPU .. it's all going to come down to your basic IO speed. (Something 'dd' is very good at measuring !)

GUI's only slow things down when your program produces output .. for example;

find / -ls

Will hammer your machine, not because of the disk IO, but because the work the machine is doing displaying the results and making your terminal scroll.

Try;

find / > /dev/null

And watch the difference.

Another good low-level test is;

hdparm -tT /dev/sda

Output from my workstation as an example;

#

hdparm -tT /dev/sda

/dev/sda:
Timing cached reads:   7632 MB in  2.00 seconds = 3817.41 MB/sec
Timing buffered disk reads:  336 MB in  3.00 seconds = 111.99 MB/sec

[Mark Greaves (PCNetSpec)]

Ahh... got ya... you were using dd to measure throughput, I thought you were suggesting it as a method