RB493AH тестирование производительности с анализатором

Переключатель 1 подключается к портам 2–9, поэтому производительность будет составлять 50% от данных. Нужно проверить соединение между портом 1 и портами (2–9), чтобы увидеть реальную производительность.

Привет, конфигурация RB493 довольно простая.

[admin@MikroTik] > ip address print
Флаги: X — отключён, I — недействителен, D — динамический  
АДРЕС            СЕТЬ           ИНТЕРФЕЙС  
0   2.2.2.1/24    2.2.2.0       ether3  
1   1.1.1.1/24    1.1.1.0       ether1  

[admin@MikroTik] > ip route print
Флаги: X — отключён, A — активен, D — динамический, C — подключён, S — статический, r — rip, b — bgp, o — ospf, m — mme, B — blackhole, U — недоступен, P — запрещён  
АДРЕС НАЗНАЧЕНИЯ  ПРЕДПОЧТИТЕЛЬНЫЙ ИСТОЧНИК  ШЛЮЗ               ДИСТАНЦИЯ  
0 ADS  0.0.0.0/0                         192.168.1.1           0  
1 ADC  1.1.1.0/24         1.1.1.1          ether1                  0  
2 ADC  2.2.2.0/24         2.2.2.1          ether3                  0  
3 ADC  192.168.1.0/24     192.168.1.10     ether9                  0  

Фаервол включён, Conntrack отключён.

Тестеры настроены следующим образом:  
Tester-1-IP-1.1.1.2 <—> Port 1-493AH-Port-2 <----> Tester-2-Loop-2.2.2.2  
То есть тестер с IP 1.1.1.2 отправляет трафик по RFC2544 на 2.2.2.2, который затем возвращает его обратно на 1.1.1.2.

Я провёл новые тесты, так как предыдущий был на основе автоопределения скорости порта 1. Теперь скорость порта была зафиксирована на 100 Мбит/с в полном дуплексе. Результаты с включённым дуплексом значительно лучше прошлых:

64 байта ----> 38 Мбит/с  
128 байт —> 75,6 Мбит/с  
512 байт —> 96,2 Мбит/с  
1518 байт —> 98,7 Мбит/с  

Что касается частоты кадров:  
64 байта —> 74 405 fps  
128 байт —> 73 910 fps  
512 байт —> 23 496 fps  
1518 байт —> 8 127 fps  

Все вышеуказанные тесты проводились с порогом потери кадров 10%, то есть после 10% тест считался проваленным.  
Если выбрать порог потери кадров 1%, результаты следующие:  
64 байта —> 0  
128 байт —> 65 Мбит/с  
512 байт —> 96,2 Мбит/с  
1518 байт —> 98,6 Мбит/с  

Частота кадров:  
64 байта —> 0  
128 байт —> 63 371 fps  
512 байт —> 23 496 fps  
1518 байт —> 8 127 fps  

+++++++++++++++++++++++++++++++++++  

Наконец, я провёл ещё один тест с максимальной потерей кадров 5%, результаты:  
64 байта —> 38,1 Мбит/с  
128 байт —> 75,6 Мбит/с  
512 байт —> 96,2 Мбит/с  
1518 байт —> 98,6 Мбит/с  

Частота кадров:  
64 байта —> 74 405 fps  
128 байт —> 73 910 fps  
512 байт —> 23 496 fps  
1518 байт —> 8 127 fps  

Вопрос: как были достигнуты 52,38 Мбит/с и 102 300 fps (как указано в pdf-файле с routerboard.com) для пакетов по 64 байта, и на каком конкретно порте был получен такой пропуск? Мои результаты для порта 1. Они скорее соответствуют показателям из pdf, где Conntrack включён (39,68 Мбит/с и 77 500 fps), чего в моём случае нет, так как Conntrack отключён:  

[admin@MikroTik] > ip firewall export
jan/02/1970 05:08:44 by RouterOS 5.15  
software id = SLXJ-AEI1  
/ip firewall connection tracking set enabled=no generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s  
/ip firewall service-port set ftp disabled=no ports=21  
set tftp disabled=no ports=69  
set irc disabled=no ports=6667  
set h323 disabled=no  
set sip disabled=no ports=5060,5061 sip-direct-media=yes  
set pptp disabled=no  

Спасибо,  
Kolpano.

Увеличение скорости, однако, можно объяснить использованием более новой версии RouterOS. И если я правильно понял, вы суммируете пакеты, которые передаются роутером (отправляются через один из интерфейсов), то это верно. Также, если вы зайдёте на http://routerboard.com/RB493AH и прокрутите страницу вниз, увидите реальные результаты на этой странице. PDF, на который вы ссылаетесь, содержит более старые данные. В наших тестах трафик генерируется отдельно для каждого потока с допуском в 1%.

Ты должен считать только пакеты, покидающие роутер — именно они успешно приняты, обработаны и отправлены дальше. Это тестовые условия и настройки, которые заданы, поэтому допуск установлен на уровне 1% в нашей тестовой конфигурации, и мы создаём два независимых потока — по одному в каждом направлении.

Вывод: RB работает быстрее с новыми версиями (так как результаты с routerboard.com могут быть устаревшими), или же результаты лучше при более высоком проценте допуска (что для меня более-менее очевидно). Возможно, что тестовое оборудование MT выполняет более точные тестовые итерации, а в сочетании с многопоточным режимом это позволяет отправлять именно то количество пакетов, которое не будет потеряно. Наверное, поэтому настройка с допуском в 1% у них не дает сбоев.