форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение		[Проследить за развитием треда]

"rate-limit tcp vs. udp на c2950"

Сообщение от WizART (??) on 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. Та же хрень...

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

1. "rate-limit tcp vs. udp на c2950"

Сообщение от daff (??) on 26-Июл-06, 12:05

> police 20000000 65536 exceed-action drop наверно 65536 - мало, brust побольше на порядок нужно попробовать

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	2. "rate-limit tcp vs. udp на c2950"
	Сообщение от WizART (??) on 26-Июл-06, 12:32
	Увы, для 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
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	3. "rate-limit tcp vs. udp на c2950"
	Сообщение от daff (??) on 26-Июл-06, 12:42
	>Увы, для 2950 это максимум. Больше возможно только на Gigabit'ных портах: тогда можно попробовать замерить несколько tcp потоков одновременно
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	4. "rate-limit tcp vs. udp на c2950"
	Сообщение от WizART (??) on 26-Июл-06, 12:47
	Была такая мысль. Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе той же цифры в 1,5Mbps.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	5. "rate-limit tcp vs. udp на c2950"
	Сообщение от daff (??) on 26-Июл-06, 12:48
	>Пускал клиента с ключиком '-p 3'. Результат - сумма колеблется в районе >той же цифры в 1,5Mbps. а если -p 100
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	6. "rate-limit tcp vs. udp на c2950"
	Сообщение от WizART (??) on 26-Июл-06, 17:52
	Мой косяк, аднака... Пересобрал с обоих сторон 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 Что уже приемлимо.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	7. "rate-limit tcp vs. udp на c2950"
	Сообщение от WizART (??) on 26-Июл-06, 17:52
	daff'у respect!
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "rate-limit tcp vs. udp на c2950"

Сообщение от WizART (??) on 27-Июл-06, 10:07

Хочу отметить еще один момент... Вдруг кому пригодится. Собрал стенд. Два сервера (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'а?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	9. "rate-limit tcp vs. udp на c2950"
	Сообщение от daff (??) on 27-Июл-06, 11:12
	ИМХО, все дело в brust-е, drop-ы уж слишком агрессивные получаются, а так как в отличии от 10FD и shaper-а нет задержки в очереди (пакеты не задерживаются а сразу убиваются) то tcp полохо, алгоритмы пологаются на задержки которых просто не происходит (в отличии от real-internet) можно кстати провести замеры с меньшим брустом хорошо бы еще потестить linux 2.6 там самый продвинутый модульный сongestion control в tcp (можно менять алгоритмы в run-time)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	10. "rate-limit tcp vs. udp на c2950"
	Сообщение от WizART (??) on 27-Июл-06, 11:48
	Потестил на 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 раза...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	11. "rate-limit tcp vs. udp на c2950"
	Сообщение от daff (??) on 27-Июл-06, 15:32
	попробуте netperf
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]