I did some testing based on the ideas I gathered here. All tests are run on the same machine (386-40) and are run for a meaningful length of time. I run each test a few times and take the best number.
Sending a real file one packet at a time with UDP checksums: 166KB/sec
Sending a real file one packet at a time wo/ UDP checksums: 200KB/sec
So turning off UDP checksums improves the speed by 20%.
Now do the same test, but just send packets as fast as you can without checking for reply packets from the server. (This tests how fast you can read a file and shove it down the Ethernet.)
Sending a real file as fast as possible with UDP checksums: 260KB/sec
Sending a real file as fast as possible w UDP checksums: 338KB/sec
Not waiting for the server to ack each individual packet makes a big difference. It's over 50% faster. Here the difference between UDP checksums and no UDP checksums is slightly more pronounced .. I don't understand why, but it's a 30% difference.
And finally, just for grins, see what the affect of file reading is by not sending real data. In this test I just send dummy data to avoid the file read.
With UDP checksums: 492KB/sec
Wo/ UDP checksums: 649KB/sec
Wow, eh? Too bad sending dummy data doesn't accomplish anything. The difference between UDP checksums here and no UDP checksums is 30% again, so I'm going to assume in the first test something was flawed and it should have been a 30% difference there too, not a 20% difference.
Note that a 10Mb/sec Ethernet works out to 1220KB/sec if everything is perfect. File transfer throughput suffers because of gaps between frames, frame headers, IP headers, etc. If the machine was fast enough the file xfer rate would be close to 1000KB/sec, including the TCP/IP overhead.
The only thing I could do differently would be to use a slightly larger packet size to cut down on some overhead. (I'm using a packet size of approximately 1100 bytes now.)
Anyway, this is getting too long. Contrary to what I was thinking, the waiting for the acks for each packet does take a while. So I implemented a simple mechanism to let the 386 'get ahead' of the server a little bit, while still keeping all of the error detection. Here are the new results:
With UDP checksums: 248KB/sec
Wo/ UDP checksums: 310KB/sec
So, compare 248KB/sec vs. 166KB/sec, or 310KB/sec vs. 200KB/sec. It's about 50% faster with no loss of error checking!
Lesson learned .. at least for a machine like the 386-40, the sliding window is worthwhile.
Sending a real file one packet at a time with UDP checksums: 166KB/sec
Sending a real file one packet at a time wo/ UDP checksums: 200KB/sec
So turning off UDP checksums improves the speed by 20%.
Now do the same test, but just send packets as fast as you can without checking for reply packets from the server. (This tests how fast you can read a file and shove it down the Ethernet.)
Sending a real file as fast as possible with UDP checksums: 260KB/sec
Sending a real file as fast as possible w UDP checksums: 338KB/sec
Not waiting for the server to ack each individual packet makes a big difference. It's over 50% faster. Here the difference between UDP checksums and no UDP checksums is slightly more pronounced .. I don't understand why, but it's a 30% difference.
And finally, just for grins, see what the affect of file reading is by not sending real data. In this test I just send dummy data to avoid the file read.
With UDP checksums: 492KB/sec
Wo/ UDP checksums: 649KB/sec
Wow, eh? Too bad sending dummy data doesn't accomplish anything. The difference between UDP checksums here and no UDP checksums is 30% again, so I'm going to assume in the first test something was flawed and it should have been a 30% difference there too, not a 20% difference.
Note that a 10Mb/sec Ethernet works out to 1220KB/sec if everything is perfect. File transfer throughput suffers because of gaps between frames, frame headers, IP headers, etc. If the machine was fast enough the file xfer rate would be close to 1000KB/sec, including the TCP/IP overhead.
The only thing I could do differently would be to use a slightly larger packet size to cut down on some overhead. (I'm using a packet size of approximately 1100 bytes now.)
Anyway, this is getting too long. Contrary to what I was thinking, the waiting for the acks for each packet does take a while. So I implemented a simple mechanism to let the 386 'get ahead' of the server a little bit, while still keeping all of the error detection. Here are the new results:
With UDP checksums: 248KB/sec
Wo/ UDP checksums: 310KB/sec
So, compare 248KB/sec vs. 166KB/sec, or 310KB/sec vs. 200KB/sec. It's about 50% faster with no loss of error checking!
Lesson learned .. at least for a machine like the 386-40, the sliding window is worthwhile.