[Dyr]

Потестировали FreeBSD 8.0, неожиданно наткнулись на серьёзную багу.

Оказалось, что если сконфигурировать vlan-интерфейс с включенным (а так и есть по умолчанию) TXCSUM на родительском интерфейсе, то TCP пакеты через родительский интерфейс начинают чудовищно биться: в ответах сервера вместо правильного MAC-адреса получателя подставляются левые MAC-адреса, причём "левые" они только в старших двух октетах, остальные октеты правильные. В результате, естественно, TCP-коннект с сервером теряется напрочь, хотя ICMP-пакеты бегают без проблем.

На серверах с абсолютно идентичной платформой (Supermicro X7SBi), работающей под FreeBSD 7.x, с яндексовскими или интеловскими драйверами (6.9.6) таких проблем не наблюдали ни разу.

Bugreport отправили

[Laa]

Ктонить уже тестил свежий релиз фри?

 

И какие у кого сложились впечатления?

Пока юзаю одну 8.0-STABLE в качестве днс и фтп-сервера. Ну пока нареканий на таких задачах нет.

[bsdelnik]

Тестим на одной машинке в качестве natа, шейпера, нетфлоу. Пока нареканий нет, особой разницы с семеркой тоже не видно. Те же грабли, вид в профиль.

 

p.s. Кстати, у знакомых тоже были грабли с вланами на восмьерке...

[YuryD]

Грабли с mpd5 есть, отписал разработчику...

[KoT]

Грабли с mpd5 есть, отписал разработчику...

Расскажите поподробнее.

А то собирался обновлять сервер mpd 5.2 c 7.1 до 8.0 и mpd до 5.4 заодно.

На тестовом сервере вроде бы как всё хорошо.

[YuryD]

Грабли с mpd5 есть, отписал разработчику...

Расскажите поподробнее.

А то собирался обновлять сервер mpd 5.2 c 7.1 до 8.0 и mpd до 5.4 заодно.

На тестовом сервере вроде бы как всё хорошо.

Где-то с 200-го ng у клиента ошибка 629, в netstat -in появляются 2 ng с одним номером, в логах mpd - невозможно назначить Ip на данном ng - уже занят. Ошибка 629 - стабильна при первом коннекте, после реконнекта все ок

[bitbucket]

Поставили 8.0. Есть грабли с RADIX_MPATH и большими изменениями (удаление множества маршрутов) таблицы маршрутизации, например, когда падает один из bgp пиров. Система уходит в панику, такое впечатление, что где-то race с порядком удаления записи в дереве маршрутизации.

[Dyr]

"Багофича" dummynet с выставлением отрицательного значения delay в восьмёрке приводит к перезагрузке. :( Убирание delay оставляет старое поведение - когда при незаполненном pipe пакеты всё равно идут с задержкой эмулируемого канала.

[z18]

Убирание delay оставляет старое поведение - когда при незаполненном pipe пакеты всё равно идут с задержкой эмулируемого канала.

Эээ... а как они (пакеты) должны идти?

[make.kernel]

Ну есть у вас pipe 32 кбит и пакет размером 100 байт, если nodelay выключен считается за сколько мс пакет проползет через трубу и вносится задержка на это время, если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале.

[Slad]

В 8-ке есть бага с vlan-ами, поверх lagg из 2 em. Вместо .1q идет ISL.

Еще что не хорощо, то что дрова на em не ахти, в 7-ке яндексовые шустрее.

[z18]

Ну есть у вас pipe 32 кбит и пакет размером 100 байт, если nodelay выключен считается за сколько мс пакет проползет через трубу и вносится задержка на это время, если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале.

Любой каприз - за Ваши деньги ;)

Для простоты считаем, что "красивый/приятный" пинг это 1ms. Если pipe у нас есть в обе стороны, то пакет должен проходить трубу за 0.5ms

Если нам надо, чтобы пинг был красивым при пакете 1500 байт, нам надо:

1500 * 8 * 1000 * 2 = 24Mbit/s

Если при стандартном (с 56 байт данных):

(20 + 8 + 56) * 8 * 1000 * 2 = 1.344Mbit/s

Минимальный icmp пакет:

(20 + 8) * 8 * 1000 * 2 = 448Kbit/s

 

Резюмирую: если клиент купил 32kbit/s, то делая пинг чего-либо он кладет свой канал на полку.

 

P.S. в 8-ке появилась опция у трубы: burst - с её помощью можно сделать нечто похожее на то, что Вы описали.

 

[los labuh]

если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале.

net.inet.ip.dummynet.io_fast

есть в 6.4/7.2

 

[z18]

если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале.

net.inet.ip.dummynet.io_fast

есть в 6.4/7.2

в описанном примере это никак не поможет.

[los labuh]

в описанном примере это никак не поможет.

Почему ? При net.inet.ip.dummynet.io_fast=1 и пайпе, не упирающемся в лимит, пакеты идут мимо dummynet шедулера. Это разве не искомое отсутствие задержки ?

[z18]

в описанном примере это никак не поможет.

Почему ? При net.inet.ip.dummynet.io_fast=1 и пайпе, не упирающемся в лимит, пакеты идут мимо dummynet шедулера. Это разве не искомое отсутствие задержки ?

Чтобы труба 32kbit/s "не упиралась в лимит", пакет должен быть не больше 32бит, т.е. 4байт (при hz=1000).

[Dyr]

Кстати, у меня net.inet.ip.dummynet.io_fast на 7.x при моей конфигурации пайпов не работает:

net.inet.ip.dummynet.debug: 0
net.inet.ip.dummynet.pipe_byte_limit: 1048576
net.inet.ip.dummynet.pipe_slot_limit: 100
net.inet.ip.dummynet.io_pkt_drop: 25459795
net.inet.ip.dummynet.io_pkt_fast: 0
net.inet.ip.dummynet.io_pkt: 2473032139
net.inet.ip.dummynet.io_fast: 1
net.inet.ip.dummynet.tick_lost: 0
net.inet.ip.dummynet.tick_diff: 587933
net.inet.ip.dummynet.tick_adjustment: 1205824
net.inet.ip.dummynet.tick_delta_sum: -187
net.inet.ip.dummynet.tick_delta: -5
net.inet.ip.dummynet.red_max_pkt_size: 1500
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.max_chain_len: 16
net.inet.ip.dummynet.expire: 0
net.inet.ip.dummynet.search_steps: -1821937006
net.inet.ip.dummynet.searches: -1821935157
net.inet.ip.dummynet.extract_heap: 288
net.inet.ip.dummynet.ready_heap: 0
net.inet.ip.dummynet.hash_size: 1024

 

А по поводу пингов, исходное сообщение на sysadmins.ru я привёл, отрицательная задержка заметно помогала в снижении времени ответа.

Изменено 14 января, 2010 пользователем Dyr

[z18]

Кстати, у меня net.inet.ip.dummynet.io_fast на 7.x при моей конфигурации пайпов не работает:

 

А по поводу пингов, исходное сообщение на sysadmins.ru я привёл, отрицательная задержка заметно помогала в снижении времени ответа.

1) io_fast не дружит нормально с wf2q на 7.x

2) отрицательная задержка просто вызывает переполние целочисленной арифметики внутри dummynet'а, поэтому результаты могут быть занимательными.

 

[MaLblsH]

Ну картина примерно такая-же как у меня была, на 40 кппс входа и 30 кппс выхода (итого 70 кппс на карточке) получается 14292+ 6905+6350+6022+6569 итого 40к прерываний, чуть меньше 2-х пакетов на одно. Это на самом деле очень много, попробуйте вот такую штуку

border# cat /boot/loader.conf | grep igb
if_igb_load="YES"
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.num_queues=1   #это мне просто больше потоков не нужно
hw.igb.enable_aim=1
hw.igb.low_latency=1000
hw.igb.ave_latency=2000
hw.igb.bulk_latency=4000
hw.igb.rx_process_limit=100
hw.igb.fc_setting=0
border#

Попробовали вчера для четырёхпортовой ET с драйвером от Intel igb-1.7.3 (OS 7.2 amd64) и при перезагрузке igb3 ругается:

could not setup received structures

В связи с чем такое может выкидывать ???

Мы правда, почитав на счёт параметра hw.igb.num_queues, определили его равным 0, вроде как при этом количество потоков определяется автоматически, может конечно и напутали тут что. Экспериментировать просто времени не было.

[MaLblsH]

Попробовали на другой машине, FreeBSD 7.2 amd64 опять теже параметры:

# cat /boot/loader.conf
if_igb_load="YES"
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.num_queues=0 #1
hw.igb.enable_aim=1
hw.igb.low_latency=1000
hw.igb.ave_latency=2000
hw.igb.bulk_latency=4000
hw.igb.rx_process_limit=100
hw.igb.fc_setting=0

сетевуха (такая же как на машине в предыдущем посте) : Intel Network Card PRO/1000 Gigabit ET Quad Port

но с разными версиями драйверов от Intel.

На версии 1.7.3 (как и в предыдущем посте) система не завелась, выкатила поток ошибок одинакового содержания:

GET BUF: dmamap load failure - 12

и в конце опять:

igb0: could not setup received structures
igb0: could not setup received structures
igb1: could not setup received structures
igb1: could not setup received structures
igb2: could not setup received structures
igb2: could not setup received structures

после чего система висла.

Пробовал изменить параметр:

hw.igb.rxd=4096
hw.igb.txd=4096

на

hw.igb.rxd=2048 #4096
hw.igb.txd=2048 #4096

результат тот же самый.

 

Поставил дрова от Intel последней версии (1.8.4):

поставил начальные параметры, опять вылетела ошибка, только на этот раз такая:

panic: RX ring pkt initialization failed!

после чего система ушла в ребут.

Опять поменял

hw.igb.rxd=4096
hw.igb.txd=4096

на

hw.igb.rxd=2048 #4096
hw.igb.txd=2048 #4096

и.. система нормально загрузилась с нужными паарметрами.

# sysctl -a | grep igb.1
dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.8.4
dev.igb.1.%driver: igb
dev.igb.1.%location: slot=0 function=1
dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10e8 subvendor=0x8086 subdevice=0xa02b class=0x020000
dev.igb.1.%parent: pci3
dev.igb.1.debug: -1
dev.igb.1.stats: -1
dev.igb.1.flow_control: 0
dev.igb.1.enable_aim: 1
dev.igb.1.low_latency: 1000
dev.igb.1.ave_latency: 2000
dev.igb.1.bulk_latency: 4000
dev.igb.1.rx_processing_limit: 100

 

Осталось только неясно, почему не получилось так же с драйверами 1.7.3 и почему не завелось с размером в 4096 ? :(

[TiFFolk]

hw.igb.txd=4096 заводится отлично, а вот RX больше 2048 ставть нельзя...

На 1.7.4 с

hw.igb.rxd=4096

hw.igb.txd=4096

Работает.

[bsdelnik]

В рассылке freebsd net очень ругают дрова под эти сетевушки, ссылаясь на сырость кода.

[TiFFolk]

В рассылке freebsd net очень ругают дрова под эти сетевушки, ссылаясь на сырость кода.

И что говорят делать?

[TiFFolk]

Если кому 1.7.4 надо:

http://clip2net.com/page/m17268/3504491

[MaLblsH]

hw.igb.txd=4096 заводится отлично, а вот RX больше 2048 ставть нельзя...

На 1.7.4 с

hw.igb.rxd=4096

hw.igb.txd=4096

Работает.

У меня к сожалению с 1.7.4 и такими размерами не завелось.

Пишет все те же самые ошибками :(

 

На 1.8.4 при hw.igb.rxd=2048, а hw.igb.txd=4096 всё хорошо запустилось, спасибо.

Будем дальше копать.