Я устраняю проблему потери UDP-пакетов в гигабитном коммутаторе с промежуточным хранением данных и хочу наглядно представить, что происходит внутри коммутатора, чтобы лучше понять суть проблемы.
Сценарий прост - два пульсирующих потока данных проходят через 2 порта внутри коммутатора и оба хотят покинуть его через третий порт (общий для обоих). Поэтому коммутатору нужно некоторое время удерживать некоторые данные в буфере пакетов.
Проблема в следующем: исходя из моих простых расчетов, буферы должны быть достаточно большими, чтобы справиться с рассматриваемым мной случаем. Один поток данных отправляет пакеты по 25 кБ (разделенные на 1514 пакетов по КБ) каждые 1,56 мс, другой отправляет пакеты по 60 кБ каждую 1 мс. Теперь даже коммутатор Soho, такой как Netgear GS105E, имеет буфер размером 128 кБ. Так что простая математика (25+60 < 128) говорит, что это должно работать, даже если потоки приходят на вход одновременно (при условии отсутствия другого существенного трафика).
Реальные тесты показывают, что на некоторых коммутаторах теряется много пакетов из обоих потоков (кажется, это связано с размером буфера, но не только с ним). В моей симуляции я не могу добиться переполнения буфера при установке его на 128 кБ.
Я записал эту анимацию для буфера размером 24 кБ, где есть переполнение. Однако вы можете легко увидеть, что увеличение буфера всего на несколько байт решит проблему, и все пакеты будут проходить.
Я сделал несколько упрощений в этой симуляции. Все пакеты имеют одинаковое QoS (то же самое и в реальном случае). Поэтому я исключил очереди QoS из симуляции и рассматриваю весь трафик как одинаково важный. Далее я исключил управление памятью буфера. Я могу себе представить, что это важная часть проблемы, но я был бы удивлен, если бы мое упрощение с идеальным распределением было бы более чем на 10% неверным по сравнению с реальным случаем. Я также притворяюсь, что коммутатор знает длину кадра, когда получает свои первые байты, так что он резервирует всю необходимую память в начале. Поскольку я не смог найти никакой документации о размере входящих/исходящих очередей портов, я предполагаю, что все они помещены в общий буфер пакетов и могут занять столько части буфера, сколько необходимо (хотя я думаю, что виновник может быть где-то здесь). Я установил задержку обработки каждого пакета на 512 нс (задержка распространения пакета 64 Б).
Я не уверен, играет ли это роль, но потоки состоят из фрагментированных UDP-пакетов (т. е. пакет в 25 кБ — это один пакет UDP, фрагментированный на 17 IP-фрагментов). Второй поток создает пакет в виде 2 или 3 пакетов UDP по 20 кБ, каждый из которых фрагментирован на 14 IP-фрагментов.
Команды Iperf 3.7 для репликации потоков, похожих на реальные:
iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000
Есть ли у вас идеи, что еще я забыл учесть, что могло привести к тому, что симуляция будет так далека от реальности? Спасибо за помощь!
Исходный код анимации находится по адресуhttps://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21.
Вот моя таблица результатов реальных экспериментов. Поток данных один фиксированный - 128 Мбит/с в пакетах UDP по 25 кБ каждые 1,56 мс. Я менял параметры второго потока, пытаясь найти предел, при котором пакеты первого потока начнут теряться коммутатором. Я менял параметр -l(length), указывающий размер пакета UDP, и -bпараметр (bandwidth), указывающий, какую полосу пропускания должны генерировать эти пакеты. --pacing-timerвсегда был установлен на 1000 для второго потока. Вы можете видеть, что D-Link и Netgear GS105 вообще не справляются с пакетами по 60 кБ. GS108 справляется намного лучше, чем GS105, при этом у него почти такой же чип коммутатора (то же «семейство», просто другое количество портов и немного больший буфер).
| Выключатель | Размер буфера [кБ] | Максимальный трафик 1,5 КБ пик | Максимальный трафик 20kB burst | Максимальный трафик 60kB burst |
|---|---|---|---|---|
| Gigablox Rugged (VSC7512) | 220 | 825 Мбит/с | 825 Мбит/с | 825 Мбит/с |
| Гигаблокс (RTL8367N-VB-CG) | 250 | 730 Мбит/с | 750 Мбит/с | 790 Мбит/с |
| D-Link DIS-100G-5W (QCA8337N-AL3C) | 128 | 110 Мбит/с | 1 Мбит/с | каждый всплеск теряет пакеты |
| Zyxel XGS 1210-12 (RTL9302B) | 1500 | 800 Мбит/с | 830 Мбит/с | 830 Мбит/с |
| Netgear GS310-TP (RTL8380M) | 520 | 830 Мбит/с | 830 Мбит/с | 835 Мбит/с |
| Netgear GS308T (RTL8380M) | 520 | 830 Мбит/с | 835 Мбит/с | 835 Мбит/с |
| Netgear GS108 v3 (BCM53118) | 192 | 630 Мбит/с | 660 Мбит/с | 710 Мбит/с |
| Netgear GS105E (BCM53114) | 128 | 120 Мбит/с | 1 Мбит/с | каждый всплеск теряет пакеты |
| Ренкфорс RF-4270245 | ? | 740 Мбит/с | 760 Мбит/с | 800 Мбит/с |
| Микротик RB260GS (AR8327) | 128 | 835 Мбит/с | 835 Мбит/с | 835 Мбит/с |
| Можжевельник EX2300 | 4ГБ? | 800 Мбит/с | 830 Мбит/с | 830 Мбит/с |
(Этот вопрос был перенесен изhttps://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switchгде он был отмечен как не соответствующий теме).