[anp/hsw] Posted May 17, 2010 Posted May 17, 2010 сетевуха intel 1000/PT dualport PCIE (Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller) нагрузка не достигает и 100 мегабит, но считчик flow-control постоянно крутится tx_deferred_ok: 163870 rx_flow_control_xon: 165992 rx_flow_control_xoff: 535264 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 примерно 20kpps, счетчик увеличивается на 2k в секунду. изза этого подскакивают пинги до 300мс, и иногда рвется связь. если отключить flow-control начинаются мелкие потери, примерно 0.1% пакетов, но жить мешают. сетевуху менять пробовал на 82572EI - не помогло, все остается также. на тачке крутится squid, accel_pptp и шейперы (без NAT) squid и шейперы отключать пробовал - ситуация не меняется, pptp - не пробовал, да и без него никак нагрузку не создашь... Вставить ник Quote
Giga-Byte Posted May 17, 2010 Posted May 17, 2010 сколько трафика? а перейти на гигабит? вот ТТК выделяют гигабитный порт и переводят абонента при трафике свыше 80Мбит наверное не зря. Вставить ник Quote
[anp/hsw] Posted May 17, 2010 Author Posted May 17, 2010 сколько трафика?а перейти на гигабит? вот ТТК выделяют гигабитный порт и переводят абонента при трафике свыше 80Мбит наверное не зря. интерфейс и так работает в 1000/full, но трафика на нем набирается немного меньше сотки. да, это внутренний интерфейс (т.е. flow-control инициируется при приеме от клиентов какого-то барахла) с внешним (он тоже 1000/full) все отлично, счетчики по нулям. Вставить ник Quote
Giga-Byte Posted May 17, 2010 Posted May 17, 2010 "инициируется"? может вы имели ввиду "инкрементится" тогда у вас с системой чего-то. (настройки, ненужный мега-тюнинг и пр. вплоть до железа) ибо с какого перепугу при трафике меньше сотки на гигабитном интерфейсе начнуться дропы. точно в full работает? режим 1000/full руками выставлять пробовали? Вставить ник Quote
Умник Posted May 17, 2010 Posted May 17, 2010 сетевуху менять пробовал на 82572EI - не помогло, все остается также.Дело не в сетевухе, потому что у вас rx_flow_control. Сетевуха получает pause frame и делает tx_defer. Проблему, ИМХО, нужно искать на девайсе, к которому подключена сетевуха. Вставить ник Quote
[anp/hsw] Posted May 17, 2010 Author Posted May 17, 2010 (edited) Дело не в сетевухе, потому что у вас rx_flow_control. Сетевуха получает pause frame и делает tx_defer. Проблему, ИМХО, нужно искать на девайсе, к которому подключена сетевуха. девайс кстати самый обычный - dlink DGS1024, занято всего 8 портов. Длинк я по этому поводу мучал, сказали что этот свич хоть гигабит мелкими пакетами перешлет - у него мозгов нету, ему пофигу. может вы имели ввиду "инкрементится" тогда у вас с системой чего-то. (настройки, ненужный мега-тюнинг и пр. вплоть до железа) ибо с какого перепугу при трафике меньше сотки на гигабитном интерфейсе начнуться дропы. инициируется в значении "начинается", хотя не суть важно. ненужного тюнинга нету, да и откуда ему взяться, правил iptables по минимуму - простые forward и filter, плюс TPROXY для squid, но я его для теста отключал. весь мега-тюнинг обычно заточен под локальные соединения, сокеты, итд. Для форварда там и не покрутишь особо ничего. p.s. Действительно, MPCP валится со стороны свича - к чему бы это? суммарный трафик меньше сотки, так что врядли возможно, что он куда-то отослать не успевает... Edited May 17, 2010 by [anp/hsw] Вставить ник Quote
Giga-Byte Posted May 17, 2010 Posted May 17, 2010 вопрос в другом, почему без flow-control у вас потери сыпятся. имхо вы пытаетесь исправить последствия а не причину, что я считаю неправильным. Вставить ник Quote
[anp/hsw] Posted May 17, 2010 Author Posted May 17, 2010 имхо вы пытаетесь исправить последствия а не причину, что я считаю неправильным. в том-то и дело, что причину я так и не смог выяснить - все выглядит отлично... Вставить ник Quote
Умник Posted May 17, 2010 Posted May 17, 2010 девайс кстати самый обычный - dlink DGS1024, занято всего 8 портовЧто к нему еще подключено? Может ли оборудование с других портов генерировать PAUSE-кадры? Я как-то видел свитч, который любой PAUSE-frame, полученный с одного из портов рассылал (в нарушение стандартов) по всем портам - как обычный broadcast. Вставить ник Quote
[anp/hsw] Posted May 17, 2010 Author Posted May 17, 2010 Что к нему еще подключено? Может ли оборудование с других портов генерировать PAUSE-кадры? Я как-то видел свитч, который любой PAUSE-frame, полученный с одного из портов рассылал (в нарушение стандартов) по всем портам - как обычный broadcast. подключено 6 гигабитных линков и 100-мегабитный, сервера, на них смотрел - flow-control не генерится. заменил щас свич сначала на cisco 3508, потом на compex DSG-1008 - похоже, виноват Dlink, причем не какой-то конкретный порт глючит, а он весь. сейчас flow-control включен, но паузы не генерятся. потестирую более конкретно... Вставить ник Quote
[anp/hsw] Posted May 17, 2010 Author Posted May 17, 2010 Нет, на compex DSG-1008 аналогично проскакивает pause, правда уже намного реже 3 пакета на 14kpps, а было в районе 200 минимум. Неужели опять не справляется? (на очереди cisco 3508, но хочется понять, нужно ли) Вставить ник Quote
wtyd Posted May 18, 2010 Posted May 18, 2010 Нет, на compex DSG-1008 аналогично проскакивает pause, правда уже намного реже 3 пакета на 14kpps, а было в районе 200 минимум. Неужели опять не справляется? (на очереди cisco 3508, но хочется понять, нужно ли) Может быть у десктопных дешёвых свичей уж совсем мелкие буферы ? Т.е. вас длинк обманул :-). Не может он гигабит на скоростях среды, больше 100 может в SOHO нагрузках (маленький pps), а провайдерский трафик не может. Может конкретно этот длинк глючный или работает с указанными фремами неправильно. Загрузку вы всегда видите интегральную, кратковременные всплески (дифференциальную загрузку) увидеть невозможно, только судя по каунтерам можно понять, что что-то не так - что вы и сделали. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.