Возможно, это связано с тем, что одна из машин использует плохо настроенное окно TCP (netperf, очевидно, называет это размером сокета Recv). Во время трехстороннего рукопожатия TCP, которое открывает TCP-соединение, каждый хост сообщает, какой размер TCP-окна он может обработать при получении, так что другой хост знает, сколько данных нужно поместить в полет, прежде чем ждать подтверждения TCP.
8 КБ (8 192 байта = 65 536 бит) не позволяют вводить в полет достаточное количество данных при скорости сети 100 000 000 бит / с и приблизительном RTT (время прохождения сигнала == время пинга) в 1 мс.
Чтобы рассчитать правильное окно TCP для использования, вам нужно рассчитать ваш «Bandwidth * Delay Product» (BDP). Пингуйте одну машину от другой и запишите время пинга. В моей загруженной сети GigE сейчас около 1 мс. Я думаю, что это немного выше для GigE, но давайте продолжим, так как один конец вашей ссылки - просто 100BASE-TX.
100 000 000 бит в секунду * 0,001 секунды (1 мс) RTT = 100 000 бит
100 000 бит / 8 бит на байт = 12 500 байт
12 500 байт / 1024 байт на КибиБайт = 12,2 КБ
Таким образом, ваше окно приема TCP на медленной машине должно быть как минимум на 50% больше, чем оно есть (12,2 вместо 8 КиБ).
Опять же, если вы используете современную ОС, такую как Windows 8.x, этот ответ не должен применяться, потому что ваши хосты должны иметь автоматическую настройку окна TCP, поэтому первоначально сообщаемые значения могут быть ненадежными. Если вы используете древнюю ОС, такую как Windows XP, или если автоматическая настройка окна TCP отключена или по какой-то причине не работает, то это применимо.