Телеграмм чат группы ntwrk страница 52510

на работе сегодня обсуждали вот этого перца https://www.arista.com/assets/data/pdf/Datasheets/7060X_7260X_DS.pdf , там народ жалуется что нужно перетыкать кабели серверов между порт-группами если внутри одной порт-группы слишком много трафика тк проседает перформанс. Я особо не в теме таких низкоуровневых дел, но в даташите заметил что они про cut-through режим говорят, а на свиче store-and-forward - интересно имеет ли смысл потестить в другом режиме

Сегодня... На работе... Ты чё не на самоизоляции чтоль?

источник

08:20пожаловаться #4

Mr Smith in ntwrk

Дмитрий Плуталов

Сегодня... На работе... Ты чё не на самоизоляции чтоль?

На ней самой, а то как же

источник

08:22пожаловаться #5

Mr Smith in ntwrk

Evgeniy

типа 2 congested порта в разных портгруппах больше буфера смогут забрать

Ну вот да, я сразу вспомнил первые 3750 где надо было тоже между группами кабеля перетыкивать в зависимости от паттернов трафика )

источник

08:23пожаловаться #6

Mr Smith in ntwrk

Evgeniy

типа 2 congested порта в разных портгруппах больше буфера смогут забрать

Просто по идее с cut though в общем случае меньше буферизоваться будет, нет разве ?

источник

08:24пожаловаться #7

Vladimir Antipov in ntwrk

Mr Smith

Просто по идее с cut though в общем случае меньше буферизоваться будет, нет разве ?

неа

источник

08:25пожаловаться #8

Vladimir Antipov in ntwrk

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

источник

08:25пожаловаться #9

Vladimir Antipov in ntwrk

cut-through не для этого, он для латенси, но цена расплаты - битые фреймы.

источник

08:26пожаловаться #10

Mr Smith in ntwrk

Так в том то и дело что там несколько недонагруженных портов которым просто непосчастливилось быть в одной группе , которую обслуживает один чип

источник

08:29пожаловаться #11

Vladimir Antipov in ntwrk

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

источник

08:37пожаловаться #12

Vladimir Antipov in ntwrk

это ж не переподписка какая-то

источник

08:39пожаловаться #13

Mr Smith in ntwrk

Я понимаю так, там архитектура свича даёт четыре пайплайна вход-выход, объединённых в порт группы. То есть когда внутри одной группы много трафика то на буферы может быть занята только область памяти этого пайплайна, остальная память простаивает, собственно Евгений выше на это и указал в даташите

источник

08:42пожаловаться #14

Mr Smith in ntwrk

Короче говоря non-blocking это все еще маркетинговая уловка я так вижу)))

источник

08:45пожаловаться #15

Vladimir Antipov in ntwrk

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

источник

08:46пожаловаться #16

Mr Smith in ntwrk

дело в том что там микс из 40 и 100г портов а разных группах, то есть буфер выдирается именно в пределах какой-то одной группы чаще всего , когда у остальных все ок. поэтому и приходится «балансировать» порты между группами перетыкая сервера

источник

08:48пожаловаться #17

Vladimir Antipov in ntwrk

просто не надо нагружать линки, оставляй хотя бы 30-35% запас емкости на порту, чтоб берстам было куда толкаться. даже в методичках гугла про это было - они уже при 55% нагрузке на порту лезут подключать еще порты.

источник

08:50пожаловаться #18

Mr Smith in ntwrk

да это разумно. Просто по моим наблюдениям в группе где совокупного транзита больше (например там много 100г дырок, пусть даже загруженных на 70%) то буфера там уже не хватает именно этой группе

источник

08:52пожаловаться #19

Yaroslav in ntwrk

ну потери в буферах обычно можно посмотреть на самой коробке

источник

08:53пожаловаться #20