Dyr Опубликовано 21 декабря, 2009 · Жалоба Потестировали FreeBSD 8.0, неожиданно наткнулись на серьёзную багу. Оказалось, что если сконфигурировать vlan-интерфейс с включенным (а так и есть по умолчанию) TXCSUM на родительском интерфейсе, то TCP пакеты через родительский интерфейс начинают чудовищно биться: в ответах сервера вместо правильного MAC-адреса получателя подставляются левые MAC-адреса, причём "левые" они только в старших двух октетах, остальные октеты правильные. В результате, естественно, TCP-коннект с сервером теряется напрочь, хотя ICMP-пакеты бегают без проблем. На серверах с абсолютно идентичной платформой (Supermicro X7SBi), работающей под FreeBSD 7.x, с яндексовскими или интеловскими драйверами (6.9.6) таких проблем не наблюдали ни разу. Bugreport отправили Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Laa Опубликовано 21 декабря, 2009 · Жалоба Ктонить уже тестил свежий релиз фри? И какие у кого сложились впечатления? Пока юзаю одну 8.0-STABLE в качестве днс и фтп-сервера. Ну пока нареканий на таких задачах нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bsdelnik Опубликовано 21 декабря, 2009 · Жалоба Тестим на одной машинке в качестве natа, шейпера, нетфлоу. Пока нареканий нет, особой разницы с семеркой тоже не видно. Те же грабли, вид в профиль. p.s. Кстати, у знакомых тоже были грабли с вланами на восмьерке... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 24 декабря, 2009 · Жалоба Грабли с mpd5 есть, отписал разработчику... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KoT Опубликовано 24 декабря, 2009 · Жалоба Грабли с mpd5 есть, отписал разработчику... Расскажите поподробнее. А то собирался обновлять сервер mpd 5.2 c 7.1 до 8.0 и mpd до 5.4 заодно. На тестовом сервере вроде бы как всё хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 24 декабря, 2009 · Жалоба Грабли с mpd5 есть, отписал разработчику... Расскажите поподробнее. А то собирался обновлять сервер mpd 5.2 c 7.1 до 8.0 и mpd до 5.4 заодно. На тестовом сервере вроде бы как всё хорошо. Где-то с 200-го ng у клиента ошибка 629, в netstat -in появляются 2 ng с одним номером, в логах mpd - невозможно назначить Ip на данном ng - уже занят. Ошибка 629 - стабильна при первом коннекте, после реконнекта все ок Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bitbucket Опубликовано 25 декабря, 2009 · Жалоба Поставили 8.0. Есть грабли с RADIX_MPATH и большими изменениями (удаление множества маршрутов) таблицы маршрутизации, например, когда падает один из bgp пиров. Система уходит в панику, такое впечатление, что где-то race с порядком удаления записи в дереве маршрутизации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 12 января, 2010 · Жалоба "Багофича" dummynet с выставлением отрицательного значения delay в восьмёрке приводит к перезагрузке. :( Убирание delay оставляет старое поведение - когда при незаполненном pipe пакеты всё равно идут с задержкой эмулируемого канала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 12 января, 2010 · Жалоба Убирание delay оставляет старое поведение - когда при незаполненном pipe пакеты всё равно идут с задержкой эмулируемого канала. Эээ... а как они (пакеты) должны идти? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 12 января, 2010 · Жалоба Ну есть у вас pipe 32 кбит и пакет размером 100 байт, если nodelay выключен считается за сколько мс пакет проползет через трубу и вносится задержка на это время, если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 13 января, 2010 · Жалоба В 8-ке есть бага с vlan-ами, поверх lagg из 2 em. Вместо .1q идет ISL. Еще что не хорощо, то что дрова на em не ахти, в 7-ке яндексовые шустрее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 13 января, 2010 · Жалоба Ну есть у вас 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 - с её помощью можно сделать нечто похожее на то, что Вы описали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
los labuh Опубликовано 13 января, 2010 · Жалоба если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале. net.inet.ip.dummynet.io_fast есть в 6.4/7.2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 13 января, 2010 · Жалоба если nodelay включен задержка вносится только если на pipe уже есть очередь, если очереди нет пакет прохордит без задержек. По простому, если клиент купил 32 кбит и грузит его на 20 кбит пинг будет как на 100 мбит, ему приятно. Это в идеале. net.inet.ip.dummynet.io_fast есть в 6.4/7.2 в описанном примере это никак не поможет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
los labuh Опубликовано 13 января, 2010 · Жалоба в описанном примере это никак не поможет. Почему ? При net.inet.ip.dummynet.io_fast=1 и пайпе, не упирающемся в лимит, пакеты идут мимо dummynet шедулера. Это разве не искомое отсутствие задержки ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 13 января, 2010 · Жалоба в описанном примере это никак не поможет. Почему ? При net.inet.ip.dummynet.io_fast=1 и пайпе, не упирающемся в лимит, пакеты идут мимо dummynet шедулера. Это разве не искомое отсутствие задержки ? Чтобы труба 32kbit/s "не упиралась в лимит", пакет должен быть не больше 32бит, т.е. 4байт (при hz=1000). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 14 января, 2010 (изменено) · Жалоба Кстати, у меня 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 14 января, 2010 · Жалоба Кстати, у меня net.inet.ip.dummynet.io_fast на 7.x при моей конфигурации пайпов не работает: А по поводу пингов, исходное сообщение на sysadmins.ru я привёл, отрицательная задержка заметно помогала в снижении времени ответа. 1) io_fast не дружит нормально с wf2q на 7.x 2) отрицательная задержка просто вызывает переполние целочисленной арифметики внутри dummynet'а, поэтому результаты могут быть занимательными. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaLblsH Опубликовано 15 января, 2010 · Жалоба Ну картина примерно такая-же как у меня была, на 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, вроде как при этом количество потоков определяется автоматически, может конечно и напутали тут что. Экспериментировать просто времени не было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaLblsH Опубликовано 20 января, 2010 · Жалоба Попробовали на другой машине, 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 ? :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 20 января, 2010 · Жалоба hw.igb.txd=4096 заводится отлично, а вот RX больше 2048 ставть нельзя... На 1.7.4 с hw.igb.rxd=4096hw.igb.txd=4096 Работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bsdelnik Опубликовано 20 января, 2010 · Жалоба В рассылке freebsd net очень ругают дрова под эти сетевушки, ссылаясь на сырость кода. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 20 января, 2010 · Жалоба В рассылке freebsd net очень ругают дрова под эти сетевушки, ссылаясь на сырость кода. И что говорят делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 20 января, 2010 · Жалоба Если кому 1.7.4 надо: http://clip2net.com/page/m17268/3504491 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MaLblsH Опубликовано 20 января, 2010 · Жалоба hw.igb.txd=4096 заводится отлично, а вот RX больше 2048 ставть нельзя...На 1.7.4 с hw.igb.rxd=4096hw.igb.txd=4096 Работает. У меня к сожалению с 1.7.4 и такими размерами не завелось. Пишет все те же самые ошибками :( На 1.8.4 при hw.igb.rxd=2048, а hw.igb.txd=4096 всё хорошо запустилось, спасибо. Будем дальше копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...