Исследование QUdpSocket REQ

Исследую различные протоколы обмена, в данном случае UDP через QUdpSocket.
Две программы клиент и сервер, ничем особо не выделяются, стандартные как в примерах.
Клиент выполняет запрос к серверу, передавая X байт. Получив от клиента сообщение, сервер отвечает Y байт.
Получив ответ сервера, клиент сразу делает новый запрос и так далее. Модель Request-Reply.

Каждый раз я ограничиваю клиента, заставляя его делать C циклов. Засекается время выполнения всех С циклов, это значение Тобщ. Наконец Тобщ/С = Т1 - время выполнения одного полного запроса.

Ок, я запускал клиента и сервера на двух отдельных машинах, соединенных DLink 100мб/с персональным хабом. Адресация простая, никаких DHCP, никаких левых сообщений в канале.

Три линии на графике обозначают три варианта отправок, когда X=Y=500байт, X=5/Y=500, X=500/Y=5;
Тут я нашел интересные вещи:
во-первых, усиливая в два раза загрузку канала (отвечая 500 на 500) мы получаем не в два раза большее время работы, а процентов на 10. Здесь кроется интересная возможность для оптимизации собственного протокола, основанного на UDP, когда вместо "дай" ты можешь дешево посылать в запросе какую то дополнительную информацию.

во-вторых, здесь плохо видно, но желтая линия всегда ниже красной, потом покажу на большой выборке отдельный график. (Особенно это видно для больших пакетов)

Ну и самое странное.
На рисунке представлен график зависимости T1 от C! Нас интересует всплеск. Что это? Почему то при выполнении 10 итераций и при выполнении 100 итераций средняя скорость одного запроса примерно одинакова. Это вроде логично. Но при 30-50 итерациях, происходит какое-то замедление.

Клиент запускался с помощью баша с различными параметрами С. Таким образом и был составлен этот график. Каждая точка - это усредненный показатель по результатам 10 испытаний.

ЧЯДНТ? Есть ли какие-то особенности UDP протокола или IP протокола или моего хаба,когда при большом количестве ПОСЛЕДОВАТЕЛЬНЫХ запросов туда-сюда происходят какие-нибудь манипуляции или что это вообще?