People are incorrect to state that rsync detects local file transfers and avoids checksumming.
rsync ALWAYS checksums EVERY BYTE it transfers.
The checksumming command line options only relate to whether checksums of files are used to determine which files to transfer or not, ie:
"-c, --checksum skip based on checksum, not mod-time & size"
What is worse, is the manpage also says this:
"Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking its whole-file checksum, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer "Does this file need to be updated?" check."
So rsync ALSO, ALWAYS, calculates a checksum of the whole file on the receiving side, even when -c/ --checksum option is OFF.
We have Dell R510/R710 servers here, plus our own custom built servers with fast RAID cards, and, for example, on a Dell R710 with dual 6-core CPUs, hyperthreading on, ie 24 cores - it is pitiful to see rsync bottlenecking our copies due to CPU load on several cores.
People forget that while CPUs and cores are multiplying like flies (12-core or 24-core machines are common now) CPUs are not, individually getting much faster. So it is easy for apps which are single-threaded or have a small number of threads to choke on CPU, while 20 cores are sitting idle and the 10-disk raid array plugs away at 1/10th of its maximum speed.
I got so fed up with this I went and modified the rsync sources to REALLY disable the checksumming on local file copies, and then it was blindingly fast. But the checksumming code is embeded deeply into rsync and the way I disabled it was an ugly hack that was not safe to use generally. So I've kept this ugly hack to myself.
Someone with a little bit more time should FIX RSYNC PROPERLY because its an unbelievable joke that rsync behaves this way on local file copies. In many situations, and rsync is the only option. But this local checksumming cripples it.