[DemYaN]

Про задержку при отсылке, я тоже не понял.

Но вот размер пакета для теста лучше брать меньше среднестатистического в реальной сети. Все это справедливо, если железяка подвергается тестированию для ввода в реальную сеть. А кол-во соединений влияет на conntrack, да и на производительность того же роут-кеша.

[bitbucket]

что касается размеров пакетов, то проще протестить наихудший вариант (тем более он с какой-то вреоятностью возможен). про задержку я не понял.

Наихудший - это какой ? Пакеты в сети разные гуляют, в разных направлениях, и с разным размером. Все тесты генерируют поток одних пакетов определенной полосы, т.е. задержка между пакетами одинаковая. Это и есть статическая нагрузка.

А юзер же не качает постоянно что-то ? Нет, он то почту отправляет мегабайтами, то порнуху смотрит, то торрент качает, то в аське сидит. Это всегда разная нагрузка, и в разные стороны (от юзера, к юзеру).

Вот и хочется проверить, как будет вести себя рутер или канал, при такой загрузке. как будет шейпер влиять и т.д.

[desperado]

что касается размеров пакетов, то проще протестить наихудший вариант (тем более он с какой-то вреоятностью возможен). про задержку я не понял.

Наихудший - это какой ? Пакеты в сети разные гуляют, в разных направлениях, и с разным размером. Все тесты генерируют поток одних пакетов определенной полосы, т.е. задержка между пакетами одинаковая. Это и есть статическая нагрузка.

А юзер же не качает постоянно что-то ? Нет, он то почту отправляет мегабайтами, то порнуху смотрит, то торрент качает, то в аське сидит. Это всегда разная нагрузка, и в разные стороны (от юзера, к юзеру).

Вот и хочется проверить, как будет вести себя рутер или канал, при такой загрузке. как будет шейпер влиять и т.д.

наихудший - это 64 байта. любой другой будет создавать меньшую загрузку. при одинаковой полосе, конечно же. поэтому любые другие игрища с размером и частотой пакетов бессмыслены если этот тест пройден. В реальной жизни лучше взять на 20-30% меньше среднестатистического. Я обычно для теста беру 200-300 байт. (так мало потому, что VPN ходит короткими пакетами, дабы не было проблем с MTU).

[bitbucket]

наихудший - это 64 байта. любой другой будет создавать меньшую загрузку. при одинаковой полосе, конечно же. поэтому любые другие игрища с размером и частотой пакетов бессмыслены если этот тест пройден. В реальной жизни лучше взять на 20-30% меньше среднестатистического. Я обычно для теста беру 200-300 байт. (так мало потому, что VPN ходит короткими пакетами, дабы не было проблем с MTU).

Тест статический нагрузкой, пусть даже мелким пакетом - не показатель, так как пакеты идут с определенным интервалом, и оно не дает реальной картины работы рутера. Нужен как бы "вибростенд": разные нагрузки в разные направления с разными величинами как размер пакета, так и времени между ними.

[martin74]

Ммм... Т.е. если у меня интерфейс роутера загружен мелкими пакетами на 100 мбит, все работает ровно и нет потерь, то если пользователь пропустит через роутер крупных пакетов на 10 мбит - оно работать не будет? Или как?

[edo]

к слову - у меня раз было - мелкие пакеты проходили, крупные нет. что-то не то с atm vc было у провайдера

 

дополнение: я не тормоз, это не mtu ;). на крупных пакетах были существенные потери, на мелких нет.

Изменено 16 ноября, 2007 пользователем edo

[desperado]

Тест статический нагрузкой, пусть даже мелким пакетом - не показатель, так как пакеты идут с определенным интервалом, и оно не дает реальной картины работы рутера. Нужен как бы "вибростенд": разные нагрузки в разные направления с разными величинами как размер пакета, так и времени между ними.

извините, но это бред какой-то...

[bitbucket]

извините, но это бред какой-то...

Не бред.

 

Есть 2 xDSL модема (не самые дешевые), поставили их на линию. Проверили ping, iperf (64 байта udp, и 10 потоков tcp) - нужные характеристики выдают. Пустили в линию трафик пользователей. Появились потери пакетов. Сняли трафик запустили тесты - все работает, пустли трафик - не работает. Оказалось, модемы при нагрузке более 1Мбит теряли пакеты размером 1300-1400 байт, при том, что например, 1300 проходит, 1301 - нет, 1302 - проходит. При этом, если гонять iperf или ping - пакеты размером 1301 байт проходят.

 

Вот как такое ловить ? Для чего и спрашиваю тест, который имитирует реальную нагрузку.

[ingress]

для чего покупают резиновых баб...если есть настоящие :-D

[bitbucket]

для чего покупают резиновых баб...если есть настоящие :-D

Сам то понял что написал ? Или "окошком ошибся" ?

[DemYaN]

для чего покупают резиновых баб...если есть настоящие :-D

Сам то понял что написал ? Или "окошком ошибся" ?

насколько я понял и еcли я не ошибся :), человек имел виду: почему бы не использовать для теста существующий трафик отзеркаленый через span или mirror порт?

[bitbucket]

насколько я понял и еcли я не ошибся :), человек имел виду: почему бы не использовать для теста существующий трафик отзеркаленый через span или mirror порт?

А как ошибки искать ?

[ingress]

для чего покупают резиновых баб...если есть настоящие :-D

Сам то понял что написал ? Или "окошком ошибся" ?

насколько я понял и еcли я не ошибся :), человек имел виду: почему бы не использовать для теста существующий трафик отзеркаленый через span или mirror порт?

да, примерно так ;)

я вообще к тому что от тестов на живых людях не уйти

а железки которые имитируют реальный профиль пользовательского трафика при большой загрузке стоят килобаксы, так к слову :)

про кривые момеды - очень частный случай. такой косяк мог вылезти и на стенде с синтетическими тестами .

Изменено 17 ноября, 2007 пользователем ingress

[bitbucket]

я вообще к тому что от тестов на живых людях не уйти

Д я уж понял - все проверяется на юзерах, как на подопытных животных, а это плохо.

 

а железки которые имитируют реальный профиль пользовательского трафика при большой загрузке стоят килобаксы, так к слову :)

Да ну ? К примеру, ixia меряет только войс, и то приблизительно.

 

про кривые момеды - очень частный случай. такой косяк мог вылезти и на стенде с синтетическими тестами .

На сденде все работало, в реальных условиях - нет. Модемы - не из дешевых. Да и проверять на стенде все размеры пакетов от 64 до 1500, да еще с различным паттерном внутри нужна специальная программа, которую я и ищу.

 

ЗЫ: видимо привется писать самому...

[desperado]

извините, но это бред какой-то...

Не бред.

 

Есть 2 xDSL модема (не самые дешевые), поставили их на линию. Проверили ping, iperf (64 байта udp, и 10 потоков tcp) - нужные характеристики выдают. Пустили в линию трафик пользователей. Появились потери пакетов. Сняли трафик запустили тесты - все работает, пустли трафик - не работает. Оказалось, модемы при нагрузке более 1Мбит теряли пакеты размером 1300-1400 байт, при том, что например, 1300 проходит, 1301 - нет, 1302 - проходит. При этом, если гонять iperf или ping - пакеты размером 1301 байт проходят.

 

Вот как такое ловить ? Для чего и спрашиваю тест, который имитирует реальную нагрузку.

бред! и результаты теста тоже бред! глюк скорее всего к размеру пакетов никакого отношения не имеет. написать програмульку которая генерит пакеты рандомного размера дело одного часа. осталось убедиться в том что это необходимо.

[Roman Ivanov]

что касается размеров пакетов, то проще протестить наихудший вариант (тем более он с какой-то вреоятностью возможен). про задержку я не понял.

Наихудший - это какой ? Пакеты в сети разные гуляют, в разных направлениях, и с разным размером. Все тесты генерируют поток одних пакетов определенной полосы, т.е. задержка между пакетами одинаковая. Это и есть статическая нагрузка.

А юзер же не качает постоянно что-то ? Нет, он то почту отправляет мегабайтами, то порнуху смотрит, то торрент качает, то в аське сидит. Это всегда разная нагрузка, и в разные стороны (от юзера, к юзеру).

Вот и хочется проверить, как будет вести себя рутер или канал, при такой загрузке. как будет шейпер влиять и т.д.

наихудший - это 64 байта. любой другой будет создавать меньшую загрузку. при одинаковой полосе, конечно же. поэтому любые другие игрища с размером и частотой пакетов бессмыслены если этот тест пройден. В реальной жизни лучше взять на 20-30% меньше среднестатистического. Я обычно для теста беру 200-300 байт. (так мало потому, что VPN ходит короткими пакетами, дабы не было проблем с MTU).

Пакет пакету рознь.

Есть рутер, Linux, 2x e1000 + NAPI.

 

При пакете в 64 байта ->100kpps, все ок.

При пакете в 100- байт ->100kpps, все ок.

При пакете в 200-300 байт не более 60kpps и CPU load 100%.

 

Долго искал - так и не нашел почему.

 

Поэтому тестить - на разных пакетах.

[Ivan Rostovikov]

Вот и у меня тоже самое.

3-й месяц бьюсь непойму почему ksoftirqd жрет все процессорное время ?

[nuclearcat]

NAPI включен?

смотреть cat /proc/interrupts

какая версия ядра?

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

какой pps на интерфейсах?

[Ivan Rostovikov]

>NAPI включен?

Вроде да.

e1000 при загрузке пишет, что мол "NAPI"

НО как проверить - незнаю.

cat /proc/interrupts

CPU0 CPU1

0: 87 0 IO-APIC-edge timer

1: 2 0 IO-APIC-edge i8042

6: 3 0 IO-APIC-edge floppy

7: 0 0 IO-APIC-edge parport0

9: 0 0 IO-APIC-fasteoi acpi

11: 0 0 IO-APIC-fasteoi ohci_hcd:usb1

12: 4 0 IO-APIC-edge i8042

14: 63 0 IO-APIC-edge ide0

16: 145402993 0 IO-APIC-fasteoi eth0

17: 34 219428013 IO-APIC-fasteoi eth1

18: 349393 76216 IO-APIC-fasteoi aic7xxx, aic7xxx

NMI: 0 0

LOC: 36276144 36276144

ERR: 0

MIS: 0

 

>какая версия ядра?

Недавно собрал 2.6.23.1 - чуть лучше стало. Но все равно фигово:

Это чуть больше суток работы, смотри сколько тиков набрал ksoftirqd !

top - 10:08:21 up 1 day, 16:20, 1 user, load average: 0.00, 0.00, 0.00

Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 66.1%id, 0.1%wa, 0.4%hi, 33.0%si, 0.0%st

Mem: 516660k total, 303864k used, 212796k free, 139756k buffers

Swap: 1365504k total, 0k used, 1365504k free, 46496k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

2443 quagga 20 0 2988 1356 536 S 2 0.3 56:04.40 ripd

1 root 20 0 1940 636 540 S 0 0.1 0:08.46 init

2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd

3 root RT -5 0 0 0 S 0 0.0 0:01.26 migration/0

4 root 15 -5 0 0 0 S 0 0.0 67:27.68 ksoftirqd/0

5 root RT -5 0 0 0 S 0 0.0 0:04.80 migration/1

6 root 15 -5 0 0 0 S 0 0.0 197:50.52 ksoftirqd/1

 

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

tsc

 

>какой pps на интерфейсах?

Пока 10000-15000 все терпимо. Как поднимется до 20000-25000 - Все. клеим ласты. загрузка под 100%%. И все он - ksoftirqd/1

 

Debian Etch, ядро пересобрал руками

# uname -r

2.6.23.1-custom

Xeon 2.4

HP Proliant 350 G3

СЕтевухи Broadcom и интел PCI32

[desperado]

а таблица маршрутизации большая?

 

PCI32 ф топку. а разве на пролианте такое может быть?

[Ivan Rostovikov]

eth0:

Tigon3 [partno(TBD) rev 1002 PHY(5703)] (PCI:33MHz:32-bit) 10/100/1000Base-T

 

eth1:

Intel PRO/1000 MT Desktop Adapter 32-bit PCI BUS RUNS AT 33 or 66 MHZ

 

ф топку. согласен но по расчетам должно проходить.

 

400-600 маршрутов. Не смертельно насколько я понимаю.

[ingress]

простите а

 

18: 349393 76216 IO-APIC-fasteoi aic7xxx, aic7xxx

 

на той же PCI32 висит? ну и где там должно хватать?

[Ivan Rostovikov]

Дык он чаще простаивает. Дисковых операций мало

[desperado]

я бы начал с нормальной сетевухи.

там кроме PCI32/33 вообще есть что-нибудь? что за пролеант такой без единой гигабитной сетевухи? уже сто лет как на серверных мателрях 2 гигабитных сетевухи на борту норма.

 

простите а

 

18: 349393 76216 IO-APIC-fasteoi aic7xxx, aic7xxx

 

на той же PCI32 висит? ну и где там должно хватать?

это пофиг. количество вызовов на 3 порядка меньше...

 

400-600 маршрутов. Не смертельно насколько я понимаю.

не смертельно, но если трафик постоянно идет по всем или по большинству то вполне заметно....

[Kirya]

я бы начал с нормальной сетевухи.

там кроме PCI32/33 вообще есть что-нибудь? что за пролеант такой без единой гигабитной сетевухи? уже сто лет как на серверных мателрях 2 гигабитных сетевухи на борту норма.

Все-таки мне что-то подсказывает что с Интелем что-то не то.

Уж больно цифры твои коррелируют с max bandwidth pci32-33mhz.

 

400-600 маршрутов. Не смертельно насколько я понимаю.

не смертельно, но если трафик постоянно идет по всем или по большинству то вполне заметно....

Я уже тут писал где-то, что на машинке с full view и max 1500 pptp kernel mode туннелей начинались чудеса, и мне пришлось выносить quagg-у на отдельную машинку. Но у меня events начинал беситься.

Изменено 21 ноября, 2007 пользователем Kirya