Curiouser and curiouser

I decided I had to figure out what was going on with my Windows-to-OSX network slowness. This time I did nc dest 2222 < /dev/random at the source machine and nc -l -p 2222 > /dev/null at the destination. Ethereal told me something quite interesting. The TCP conversation runs thus, repeated ad infinitum:
1. Windows → OSX: 1460 bytes data
2. Windows → OSX: 1460 bytes data
3. Windows ← OSX: ack for packet 3
4. Windows → OSX: 1460 bytes data
5. Windows → OSX: 1460 bytes data
6. Windows ← OSX: ack for packet 5
7. Windows → OSX: 1460 bytes data
8. Windows → OSX: 892 bytes data + push
0.2 second delay
9. Windows ← OSX: ack for packet 8
So, Windows sends 8192 bytes and then requests a push. Nothing wrong with that, it makes sure the data got delivered before continuing - but why does it take a fifth of a second for OSX to send the achnowledgement?

Let's try things in the opposite direction. This time we get 8.5MB/sec (70% utilization). That's more like it! Looking at the Ethereal trace, things are quite different:
1. OSX → Windows: 1448 bytes data
2. OSX → Windows: 1448 bytes data
3. OSX → Windows: 1448 bytes data
4. OSX → Windows: 1448 bytes data
5. OSX → Windows: 1448 bytes data
6. OSX ← Windows: ack for packet 2
7. OSX ← Windows: ack for packet 4
8. OSX ← Windows: ack for packet 6
9. OSX → Windows: 952 bytes data + push
There are no major delays here. As before, there's a push every 8192 bytes. This was measured at the OSX end, I expect Windows would have a different opinion about the order of the packets, but that's irrelevant.

I smell a bug here. Either it's in the OSX port of netcat, or it's in the OSX TCP implementation. Given that SSH performs no better than netcat, I'm inclined to believe the latter.




This work is licensed under a Creative Commons License.