rate-limit tcp vs. udp на c2950, WizART, 26-Июл-06, 11:30 [смотреть все]Не могу прояснить для себя колоссальную разницу для 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. Та же хрень...
|
- rate-limit tcp vs. udp на c2950, daff, 12:05 , 26-Июл-06 (1)
> police 20000000 65536 exceed-action drop наверно 65536 - мало, brust побольше на порядок нужно попробовать
- rate-limit tcp vs. udp на c2950, WizART, 12:32 , 26-Июл-06 (2)
Увы, для 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
- rate-limit tcp vs. udp на c2950, daff, 12:42 , 26-Июл-06 (3)
>Увы, для 2950 это максимум. Больше возможно только на Gigabit'ных портах: тогда можно попробовать замерить несколько tcp потоков одновременно
- rate-limit tcp vs. udp на c2950, WizART, 12:47 , 26-Июл-06 (4)
Была такая мысль. Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе той же цифры в 1,5Mbps.
- rate-limit tcp vs. udp на c2950, daff, 12:48 , 26-Июл-06 (5)
>Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе >той же цифры в 1,5Mbps. а если -p 100
- rate-limit tcp vs. udp на c2950, WizART, 17:52 , 26-Июл-06 (6)
Мой косяк, аднака... Пересобрал с обоих сторон 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 Что уже приемлимо. - rate-limit tcp vs. udp на c2950, WizART, 17:52 , 26-Июл-06 (7)
- rate-limit tcp vs. udp на c2950, WizART, 10:07 , 27-Июл-06 (8)
Хочу отметить еще один момент... Вдруг кому пригодится. Собрал стенд. Два сервера (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'а?
- rate-limit tcp vs. udp на c2950, daff, 11:12 , 27-Июл-06 (9)
ИМХО, все дело в brust-е, drop-ы уж слишком агрессивные получаются, а так как в отличии от 10FD и shaper-а нет задержки в очереди (пакеты не задерживаются а сразу убиваются) то tcp полохо, алгоритмы пологаются на задержки которых просто не происходит (в отличии от real-internet)можно кстати провести замеры с меньшим брустом хорошо бы еще потестить linux 2.6 там самый продвинутый модульный сongestion control в tcp (можно менять алгоритмы в run-time)
- rate-limit tcp vs. udp на c2950, WizART, 11:48 , 27-Июл-06 (10)
Потестил на 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 раза...
|