Just as crazy -- random network packet corruptions that get past the simple checksumming.
I've seen multiple vendors with buggy implementations. In what way are they buggy? In the cases I've seen, packets are corrupted by the driver and then have a hardware checksum applied to the corrupt data...so they go through the network just fine. (In one case, for example, two 64 byte blocks of data were swapped within a large packet.)
When you turn on TCP offloading, you're swapping the well-proven OS network stack for a who-the-hell-knows-how-much-testing-really-went on network device stack.
There may or may not be a noticeable performance penalty when you turn off TDP offloading features, so you should profile performance before and after.
Not if you do that over SCP / SSL / TLS that said... (and the bottleneck is the network, not the symmetric encryption used once the public/private symmetric key exchange has been made).
So, yeah, everytime I copy big files I'm using scp (small files too actually but it's just out of convenience).
This is actually pretty interesting! How well does encryption handle bit corruption in encrypted data? I would guess it would depend if signature is used and the chaining mode used.