Jump to content
Калькуляторы

мучает flow-control, как лечить?

сетевуха 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 - не пробовал, да и без него никак нагрузку не создашь...

 

 

Share this post


Link to post
Share on other sites

сколько трафика?

а перейти на гигабит?

 

вот ТТК выделяют гигабитный порт и переводят абонента при трафике свыше 80Мбит наверное не зря.

Share this post


Link to post
Share on other sites
сколько трафика?

а перейти на гигабит?

 

вот ТТК выделяют гигабитный порт и переводят абонента при трафике свыше 80Мбит наверное не зря.

интерфейс и так работает в 1000/full, но трафика на нем набирается немного меньше сотки.

 

да, это внутренний интерфейс (т.е. flow-control инициируется при приеме от клиентов какого-то барахла)

с внешним (он тоже 1000/full) все отлично, счетчики по нулям.

Share this post


Link to post
Share on other sites

"инициируется"?

может вы имели ввиду "инкрементится"

 

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

ибо с какого перепугу при трафике меньше сотки на гигабитном интерфейсе начнуться дропы.

 

точно в full работает? режим 1000/full руками выставлять пробовали?

Share this post


Link to post
Share on other sites

сетевуху менять пробовал на 82572EI - не помогло, все остается также.

Дело не в сетевухе, потому что у вас rx_flow_control. Сетевуха получает pause frame и делает tx_defer. Проблему, ИМХО, нужно искать на девайсе, к которому подключена сетевуха.

Share this post


Link to post
Share on other sites
Дело не в сетевухе, потому что у вас rx_flow_control. Сетевуха получает pause frame и делает tx_defer. Проблему, ИМХО, нужно искать на девайсе, к которому подключена сетевуха.

девайс кстати самый обычный - dlink DGS1024, занято всего 8 портов. Длинк я по этому поводу мучал, сказали что этот свич хоть гигабит мелкими пакетами перешлет - у него мозгов нету, ему пофигу.

 

может вы имели ввиду "инкрементится"

 

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

ибо с какого перепугу при трафике меньше сотки на гигабитном интерфейсе начнуться дропы.

инициируется в значении "начинается", хотя не суть важно.

ненужного тюнинга нету, да и откуда ему взяться, правил iptables по минимуму - простые forward и filter, плюс TPROXY для squid, но я его для теста отключал.

весь мега-тюнинг обычно заточен под локальные соединения, сокеты, итд. Для форварда там и не покрутишь особо ничего.

 

p.s.

Действительно, MPCP валится со стороны свича - к чему бы это? суммарный трафик меньше сотки, так что врядли возможно, что он куда-то отослать не успевает...

Edited by [anp/hsw]

Share this post


Link to post
Share on other sites

вопрос в другом, почему без flow-control у вас потери сыпятся.

 

имхо вы пытаетесь исправить последствия а не причину, что я считаю неправильным.

Share this post


Link to post
Share on other sites
имхо вы пытаетесь исправить последствия а не причину, что я считаю неправильным.

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

Share this post


Link to post
Share on other sites

девайс кстати самый обычный - dlink DGS1024, занято всего 8 портов

Что к нему еще подключено? Может ли оборудование с других портов генерировать PAUSE-кадры? Я как-то видел свитч, который любой PAUSE-frame, полученный с одного из портов рассылал (в нарушение стандартов) по всем портам - как обычный broadcast.

Share this post


Link to post
Share on other sites
Что к нему еще подключено? Может ли оборудование с других портов генерировать PAUSE-кадры? Я как-то видел свитч, который любой PAUSE-frame, полученный с одного из портов рассылал (в нарушение стандартов) по всем портам - как обычный broadcast.

подключено 6 гигабитных линков и 100-мегабитный, сервера, на них смотрел - flow-control не генерится.

заменил щас свич сначала на cisco 3508, потом на compex DSG-1008 - похоже, виноват Dlink, причем не какой-то конкретный порт глючит, а он весь.

 

сейчас flow-control включен, но паузы не генерятся. потестирую более конкретно...

 

Share this post


Link to post
Share on other sites

Нет, на compex DSG-1008 аналогично проскакивает pause, правда уже намного реже 3 пакета на 14kpps, а было в районе 200 минимум.

Неужели опять не справляется? (на очереди cisco 3508, но хочется понять, нужно ли)

Share this post


Link to post
Share on other sites

Нет, на compex DSG-1008 аналогично проскакивает pause, правда уже намного реже 3 пакета на 14kpps, а было в районе 200 минимум.

Неужели опять не справляется? (на очереди cisco 3508, но хочется понять, нужно ли)

Может быть у десктопных дешёвых свичей уж совсем мелкие буферы ? Т.е. вас длинк обманул :-). Не может он гигабит на скоростях среды, больше 100 может в SOHO нагрузках (маленький pps), а провайдерский трафик не может. Может конкретно этот длинк глючный или работает с указанными фремами неправильно.

 

Загрузку вы всегда видите интегральную, кратковременные всплески (дифференциальную загрузку) увидеть невозможно, только судя по каунтерам можно понять, что что-то не так - что вы и сделали.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this