Tcp-поток с низкой задержкой в ​​Linux - PullRequest
Новая
       19

Tcp-поток с низкой задержкой в ​​Linux

3 голосов
/ 01 октября 2010

У меня есть встроенное приложение, которое соответствует этому требованию: один исходящий сетевой поток TCP должен иметь абсолютный наивысший приоритет над всем остальным исходящим сетевым трафиком.Если есть какие-либо пакеты, ожидающие передачи в этом потоке, они должны быть следующими отправленными пакетами.Период.

Мой показатель успеха выглядит следующим образом: Измерьте задержку с высоким приоритетом при отсутствии фонового трафика.Добавьте фоновый трафик и измерьте снова.Разница в задержке должна заключаться во времени отправки одного пакета с низким приоритетом.При соединении со скоростью 100 Мбит / с mtu = 1500, это примерно 150 долларов США.Моя тестовая система имеет два linux-бокса, соединенных перекрестным кабелем.

Я перепробовал много, много вещей, и хотя я значительно улучшил задержку, я не достиг цели (в настоящее время я вижу добавочную задержку 5 мс сфоновый трафик).Я уже опубликовал другой, очень специфический вопрос, но подумал, что мне следует начать с общего вопроса.

Первый вопрос: возможно ли это в Linux?Второй вопрос: Если да, что мне нужно сделать?

  • tc?
  • Какой qdisc мне следует использовать?
  • Настроить параметры сети ядра?Какие из них?
  • Что еще мне не хватает?

Спасибо за вашу помощь!

Эрик

Обновление от 04.10.2010:Я настроил tcpdump как на стороне передачи, так и на стороне приема.Вот что я вижу на передающей стороне (где вещи кажутся перегруженными): 

0 us   Send SCP (low priority) packet, length 25208
200 us Send High priority packet, length 512

На приемной стороне я вижу: 

~ 100 us  Receive SCP packet, length 548
170 us    Receive SCP packet, length 548
180 us    Send SCP ack
240 us    Receive SCP packet, length 548
...  (Repeated a bunch of times)
2515 us   Receive high priority packet, length 512

Проблема, кажется, заключается вдлина пакета SCP (25208 байт).Это разбито на несколько пакетов на основе mtu (который я установил на 600 для этого теста).Тем не менее, это устраивает на более низком сетевом уровне, чем управление трафиком, и, таким образом, моя задержка определяется максимальным размером передаваемого пакета tcp, а не mtu!Arghhh ..

Кто-нибудь знает хороший способ установить максимальный размер пакета по умолчанию для TCP в Linux?

1 Ответ

1 голос
/ 01 октября 2010

Возможно, вы захотите проверить настройки драйвера NIC.Некоторые драйверы объединяют прерывания, которые заменяют более высокую пропускную способность для увеличения задержки.

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

Кроме того, я не знаю, буферизует ли NIC несколько выходных пакетов, но если это так,это усложнит реализацию желаемых приоритетов: если в NIC буферизировано несколько пакетов с низким приоритетом, ядро, вероятно, не сможет сказать NIC «забудь о том, что я тебе уже отправил, отправь этосначала пакет с высоким приоритетом ".

--- update ---

Если проблема в длинных сегментах TCP, я полагаю, что вы можете контролировать, какой максимальный размер сегмента объявляется уровнем TCP с помощью *Опция 1010 * на ip route.Например: 

ip route add default via 1.1.1.1 mtu 600

(обратите внимание, что вам нужно сделать это на стороне receive ).

...