Какова фактическая точка времени SOF_TIMESTAMPING_RX_SOFTWARE, созданная для данных байтового потока TCP? ⇐ Linux

[Anonymous]

Я учусь использовать параметр SO_TIMESTAMPING для получения временных меток для измерения задержки моего приложения, которое использует TCP для передачи данных. Сетевая карта моего тестового сервера поддерживает SOF_TIMESTAMPING_SOFTWARE, поэтому мне удалось использовать опцию сокета SO_TIMESTAMPING с SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_SOFTWARE и Recvmsg, чтобы получить временные метки. Поначалу казалось, что все работает нормально.
Однако, когда я выполнил приведенный ниже тест, я обнаружил, что временная метка на самом деле не соответствует времени, когда байты были получены сетевым адаптером.
TEST

• TCP-сервер принимает входящие клиентские соединения и записывает 20 Б данных 20 раз, переходя в режим ожидания 1 раз. секунду после каждой записи. TCP_NODELAY установлен для сокета сервера.
• TCP-клиент спит в течение 20 секунд после подключения к серверу (т. е. пока сервер не завершит запись), а затем вызывает Recvmsg с размером буфера 20 байт, поэтому он вызовет Recvmsg 20 раз и получит 20 временных меток RX.

Поскольку сервер включает TCP_NODELAY , я ожидаю, что каждая запись сервера немедленно сгенерирует пакет с полезной нагрузкой TCP 20B, а клиент получит этот пакет и отметит его время всякий раз, когда пакет прибудет, даже если клиент спит и еще не вызывает Recvmsg . Используя tcpdump на стороне клиента, выходные данные показывают, что пакеты действительно принимаются один за другим, каждую секунду.
Однако мой тест показывает, что все 20 Recvmsg вызовы имеют одинаковую временную метку приема, то есть время последнего пакета.
Вывод (индекс чтения, временная метка приема, полезная нагрузка с временной меткой отправки):

Код: Выделить всё

# all RX timestamp is 1729223045.596191883, and the last packet was sent at 1729223045.596149
# server and client's sysclock is almost synced, network RTT < 100us

0 1729223045.596191883 1729223026.594545...
1 1729223045.596191883 1729223027.594635...
2 1729223045.596191883 1729223028.594719...
3 1729223045.596191883 1729223029.594802...
4 1729223045.596191883 1729223030.594888...
5 1729223045.596191883 1729223031.594971...
6 1729223045.596191883 1729223032.595056...
7 1729223045.596191883 1729223033.595140...
8 1729223045.596191883 1729223034.595223...
9 1729223045.596191883 1729223035.595306...
10 1729223045.596191883 1729223036.595391...
11 1729223045.596191883 1729223037.595475...
12 1729223045.596191883 1729223038.595559...
13 1729223045.596191883 1729223039.595647...
14 1729223045.596191883 1729223040.595731...
15 1729223045.596191883 1729223041.595813...
16 1729223045.596191883 1729223042.595899...
17 1729223045.596191883 1729223043.595981...
18 1729223045.596191883 1729223044.596067...
19 1729223045.596191883 1729223045.596149...

Я использую ядро ​​4.14.252-195.483.amzn2.x86_64.
Я прочитал документацию ядра по меткам времени
Оно описывает SOF_TIMESTAMPING_RX_SOFTWARE как:

Запрашивать временные метки приема, когда данные поступают в ядро. Эти временные метки генерируются сразу после того, как драйвер устройства передает пакет в стек приема ядра.

Не следует ли «передавать ядру» каждый 20-байтовый пакет? сразу после того, как он прибудет на сетевой адаптер?
Если я изменю клиентский код на получение всех данных без сна, временные метки приема будут нормальными.

Подробнее здесь: https://stackoverflow.com/questions/791 ... r-tcp-byte