Не могу прояснить для себя колоссальную разницу для TCP и UDP в тестах на пропускную способность через интерфейс с поднятым CAR.
Коммутатор: WS-2950-24. IOS: c2950-i6q4l2-mz.121-6.EA2.bin. Поддержка CAR не заявлена официально, но присутствует.Делаю:
access-list 123 permit ip any any
class-map match-all class-policy-any
match access-group 123
policy-map Client-policy-test
class class-policy-any
police 1000000 65536 exceed-action drop
int fa0/1
service-policy input Client-policy-testТестирую bandwidth с помощью iperf (клиент на порту fa0/1).
Получаю по UDP показатели примерно в 1Mbps, на TCP - около 975Kbps. Это есть вполне приемлимо.Меняю:
policy-map Client-policy-test
class class-policy-any
police 20000000 65536 exceed-action drop
Снова прогоняю тест.
Получаю странный результат.
UDP - около 20Mbps, TCP - 1,5Mbps.Я так понимаю принцип rate-limiting'а: тупой сброс пакетов при превышении выставленной полосы.
Но с чего такая низкая скорость по TCP? Ретрансмиты? Но насколько я понимаю, во-первых, TCP должен адаптироваться и уменьшить размер окна. Во-вторых, куда девается 80% (!!!) полосы канала!?Кто занимался этим вопросом... подсобите, плиз...
Спасибо!P.S. Тестировал другим инструментом: ttcp на WinXP и на FreeBSD. Результат не зависит от OS. Та же хрень...
> police 20000000 65536 exceed-action drop
наверно 65536 - мало, brust побольше на порядок нужно попробовать
Увы, для 2950 это максимум. Больше возможно только на Gigabit'ных портах:
Switch(config-pmap-c)#police 20000000 ?
131072 128K burst bytes (valid for only Gigabit ports)
16384 16K burst bytes
262144 256K burst bytes (valid for only Gigabit ports)
32768 32K burst bytes
4096 4K burst bytes
524288 512K burst bytes (valid for only Gigabit ports)
65536 64K burst bytes
8192 8K burst bytes
>Увы, для 2950 это максимум. Больше возможно только на Gigabit'ных портах:
тогда можно попробовать замерить несколько tcp потоков одновременно
Была такая мысль.
Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе той же цифры в 1,5Mbps.
>Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе
>той же цифры в 1,5Mbps.
а если -p 100
Мой косяк, аднака...
Пересобрал с обоих сторон iperf с поддержкой pthreads.
При 'policy 10000000 65535' на порту пустил 'iperf -c ... -P 20 -t 120'
Получил на сервере:
[ 7] 0.0-120.2 sec 7.20 MBytes 502 Kbits/sec
[ 8] 0.0-120.5 sec 7.34 MBytes 511 Kbits/sec
[ 12] 0.0-120.5 sec 7.75 MBytes 540 Kbits/sec
[ 13] 0.0-120.5 sec 7.52 MBytes 524 Kbits/sec
[ 6] 0.0-121.4 sec 7.16 MBytes 495 Kbits/sec
[ 9] 0.0-121.4 sec 8.21 MBytes 567 Kbits/sec
[ 10] 0.0-121.4 sec 7.55 MBytes 522 Kbits/sec
[ 11] 0.0-121.4 sec 7.08 MBytes 489 Kbits/sec
[ 16] 0.0-123.1 sec 7.94 MBytes 541 Kbits/sec
[ 15] 0.0-123.5 sec 7.96 MBytes 541 Kbits/sec
[ 18] 0.0-123.5 sec 7.27 MBytes 494 Kbits/sec
[ 20] 0.0-123.5 sec 7.34 MBytes 499 Kbits/sec
[ 21] 0.0-123.5 sec 7.47 MBytes 507 Kbits/sec
[ 19] 0.0-123.9 sec 8.02 MBytes 543 Kbits/sec
[ 14] 0.0-124.3 sec 7.24 MBytes 489 Kbits/sec
[ 17] 0.0-124.7 sec 7.38 MBytes 496 Kbits/sec
[SUM] 0.0-124.7 sec 120 MBytes 8.10 Mbits/sec
Что уже приемлимо.
daff'у respect!
Хочу отметить еще один момент... Вдруг кому пригодится.
Собрал стенд. Два сервера (FreeBSD 6.1 и FreeBSD 4.10) на одном коммутаторе. Оба порта работают на 100FD.
Тестируем iperf'ом с одним тредом. Получаем bandwidth порядка 90Mbps.Ставим на один из портов (скажем 1ый) 'policy 10000000 65535'.
Тестируем iperf'ом с одним тредом (клиент на 1ом порту). Получаем bandwidth порядка 1,5Mbps в сторону сервера.Убираем policy. Переводим один из портов в режим 10FD (скажем 2ой). Ожидаем производительность TCP порядка 10Mbps...
Тестируем iperf'ом с одним тредом (клиент на 1ом порту). Получаем bandwidth порядка тех же 1,5Mbps в сторону сервера.
В случае тестирования iperf'ом '-P 15' мы получим в обоих случаях bandwidth порядка 8,5Mbps.Отсюда делаем вывод о том, что на схемах Fast Sender Slow Receiver на хостах начинает работать Congestion Avoidance механизм. И производительность TCP-сессии ограничивается именно его алгоритмами, Cisco Policing тут абсолютно не причем.
Остается вопрос: почему за время в 120 секунд алгоритмы не привели скорость передачи на sender'е в соответсвии с возможностями receiver'а?
ИМХО, все дело в brust-е, drop-ы уж слишком агрессивные получаются, а так как в отличии от 10FD и shaper-а нет задержки в очереди (пакеты не задерживаются а сразу убиваются) то tcp полохо, алгоритмы пологаются на задержки которых просто не происходит (в отличии от real-internet)можно кстати провести замеры с меньшим брустом
хорошо бы еще потестить linux 2.6 там самый продвинутый модульный сongestion control в tcp (можно менять алгоритмы в run-time)
Потестил на FTP.10FD на порту сервера:
ftp> put cs-as5300
local: cs-as5300 remote: cs-as5300
229 Entering Extended Passive Mode (|||65051|)
150 Opening BINARY mode data connection for 'cs-as5300'.
32% |*********** | 30816 KB 1.11 MB/s 00:57 ETA^C
send aborted. Waiting for remote to finish abort.
226 Transfer complete.
31784960 bytes sent in 00:27 (1.11 MB/s)Policing на порту клиента:
ftp> put cs-as5300
local: cs-as5300 remote: cs-as5300
229 Entering Extended Passive Mode (|||65037|)
150 Opening BINARY mode data connection for 'cs-as5300'.
100% |*************************************| 96159 KB 593.69 KB/s 00:00 ETA
226 Transfer complete.
98466849 bytes sent in 02:41 (593.60 KB/s)Перестал понимать происходящее окончательно! :)
FTP data вроде задействует одну сессию - т.е. тот же самый single thread iperf. Однако на FTP производительность около 9Mbps... на iperf - 1,5Mbps.
Опять же разница между policing'ом и 10FD почти в 2 раза...
попробуте netperf