Перейти к содержимому
Калькуляторы

размер пакетного буфера коммутатора

8 минут назад, edo сказал:

но вот как вы вычисляете размер этого «неравномерно» деля скорости — для меня загадка.

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

Логика: раз передать пакет в низкоскоростом интерфейсе в 1000 раз дольше, чем в высокоскоростном, значит мы должны обеспечить такой буфер, который бы позволил накапливать пакеты из высокоскоростного, пока низкоскоростной их передает. Очевидно, что он должен содержать 1000 единиц передачи (пакетов) или больше (но зачем? тогда буфер всегда будет полупустой, если не брать экзотические случаи с flow control, который уже почти вымер), иначе может возникнуть ситуация, когда при заполненом буфере передатчик занят, а пакеты продолжают в буфер поступать. Это же не только в коммутаторах, это вообще базовые принципы буфферизации...

Т.е. достаточность буфера расчитывать надо в пакетах (хотя в ethernet пакеты могут быть разной длины, так что в итоге для расчета буфера всегда принимают максимальный пакет, 1500, jumbo frame тут никто не рассматривает)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

54 минуты назад, [anp/hsw] сказал:

Очевидно, что он должен содержать 1000 единиц передачи (пакетов)

мне неочевидно. почему не 10 или не 100000?

 

55 минут назад, [anp/hsw] сказал:

Логика: раз передать пакет в низкоскоростом интерфейсе в 1000 раз дольше, чем в высокоскоростном, значит мы должны обеспечить такой буфер, который бы позволил накапливать пакеты из высокоскоростного, пока низкоскоростной их передает

за то время, как низкоскоростой передаст первый пакет, мы накопили 1000 из высокоскоростного. дальше что? пока мы передаём второй пакет, с высокоскоростного придёт ещё 1000. и т. д., и т. п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, edo сказал:

пока мы передаём второй пакет, с высокоскоростного придёт ещё 1000. и т. д., и т. п.

Т.е. вы имеете ввиду ситуацию, когда целевой трафик не влезает в порт? Во всех коммутаторах тут будет абсолютно одинаковое поведение - все следующие пакеты отбросить (а для "важных" пакетов QOS вытеснит ими "не очень важные").

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

Если будете спорить - то ответьте сначала на вопрос "зачем это делать"?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, [anp/hsw] сказал:

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

я не понимаю как сравнивать мегабиты в секунды («может пропустить порт назначения») и мегабайты («накапливать трафик в буфере»).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 часов назад, [anp/hsw] сказал:

Логика: раз передать пакет в низкоскоростом интерфейсе в 1000 раз дольше, чем в высокоскоростном, значит мы должны обеспечить такой буфер, который бы позволил накапливать пакеты из высокоскоростного, пока низкоскоростной их передает. Очевидно, что он должен содержать 1000 единиц передачи

давайте доведём ваш пример до предела.

пусть у нас два порта: downlink 10 Кбит/c и uplink 100 Гбит/c, то есть соотношение 1:10⁷. размер пакета всё те же 1500 байт.

по вашей логике нам нужен буфер размером 15 ГБ (на 10 миллионов пакетов).

предположим, downlink у нас был занят передачей пакета, буфер наполнился. и что нам с ним теперь делать? он будет передаваться через downlink 4 с половиной месяца, если я не ошибся в расчётах.

 

или нам не нужно его наполнять? но зачем он тогда такого размера?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, edo сказал:

я не понимаю как сравнивать мегабиты в секунды («может пропустить порт назначения») и мегабайты («накапливать трафик в буфере»).

Мы секунды здесь вообще не сравниванием, исключительно их соотношения, которые уже не секунды, а безразмерная величина.

 

7 часов назад, edo сказал:

по вашей логике нам нужен буфер размером 15 ГБ (на 10 миллионов пакетов).

Зачем вам в этот буфер пихать весь трафик 100-гигабитного порта? Туда надо пихать только трафик, который предназначается в 10-килобитный.

7 часов назад, edo сказал:

предположим, downlink у нас был занят передачей пакета, буфер наполнился. и что нам с ним теперь делать? он будет передаваться через downlink 4 с половиной месяца, если я не ошибся в расчётах.

Опять запутались в собственных рассуждениях. Вы условия задачи поставьте хотя бы!

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

В моей вселенной я пытаюсь пропустить 10 килобит нужного трафика из 100 гигабит общего в 10-килобитный порт, и считаю с этой позиции.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, [anp/hsw] сказал:

В моей вселенной я пытаюсь пропустить 10 килобит нужного трафика из 100 гигабит общего в 10-килобитный порт, и считаю с этой позиции.

Так и какой размер буфера для этого нужен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

26 минут назад, edo сказал:

Так и какой размер буфера для этого нужен?

QOS делать будем? Если нет, то хватит буфера в 1 пакет (условных 1500 байт).

И это при допущении, что 10-килобитный ethernet порт существует (хотя 10 килобит это больше ATM, с соответствующей спецификой реализации буферов).

Вы в крайность ударились, на такой разности скоростей исходящую очередь с сохранением джиттера реализовать невозможно.

 

Хорошо, я вижу, что у вас есть своя устоявшая точка зрения на этот вопрос.

Тогда теперь вы ответьте, какой размер буфера для этого нужен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а вот не знаю.

 

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

в тех масштабах, что мы видим на soc cвитчей, можно сказать «чем больше — тем лучше».

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я не говорю, что я лучше всех знаю, просто высказываю свои соображения:

я не понимаю логику, которая лежит в основе варианта «посчитать соотношение скоростей и умножить на максимальный размер пакета».

 

 

В 29.10.2020 в 11:50, [anp/hsw] сказал:

Учитывая, что в ethernet 1 такт = 1 пакет, то для того, чтобы отправить пакет из 10-гигабитного порта в 10-мегабитный нужно всего лишь буфер на 10000/10=1000 пакетов. Т.е. по сути 1.5мб (при размере пакета 1500) будет достаточно на каждый 10-мегабитный линк, и 150кб на каждый 100-мегабитный.

хорошо, подключим свитчи гирляндой: 10G → 1G → 100M → 10M

 

по вашей логике, в этом случае хватит по 15 КБ буфера на каждый свитч, итого 45 КБ.

если же воткнуть десятимегабитный линк сразу в первый свитч, то, по вашим подсчётам, нужно в 300 раз больше. не понимаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

14 часов назад, edo сказал:

по вашей логике, в этом случае хватит по 15 КБ буфера на каждый свитч, итого 45 КБ.

если же воткнуть десятимегабитный линк сразу в первый свитч, то, по вашим подсчётам, нужно в 300 раз больше. не понимаю.

Здесь нет противоречия. В первом случае у нас будет тройная буферизация, во втором - одинарная.

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 30 октября 2020 г. в 08:24, [anp/hsw] сказал:

если не брать экзотические случаи с flow control

Где это flow control вымер? Ты с back pressure не перепутал?
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 часов назад, [anp/hsw] сказал:

и убедиться, в какую кашу превратится порядок следования пакетов без принудительного навешивания QOS

что-то я не помню случаев переупорядочивания пакетов в свитчах без qos (ну оно может случиться со всякими lacp, но обычно настраивается так, чтобы пакеты внутри одной tcp-сессии приходили в исходном порядке)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 часов назад, straus сказал:

Где это flow control вымер? Ты с back pressure не перепутал?

В провайдерстве давно уже вымер. В ДЦ тоже. Это потенциально опасная фича, позволяющая вообще весь трафик на свиче остановить, ситуации где он включен намеряно, можно посчитать по пальцам одной руки.

В корпоративной локалке может еще и используется.

 

7 часов назад, edo сказал:

что-то я не помню случаев переупорядочивания пакетов в свитчах без qos

Так мы буферизуем, или где? При забивке в буфер изменится как минимум время между поступлением пакетов. При двойной буферизации между ними опять попадут другие пакеты, еще больше увеличив джиттер. Про переупорядочивание действительно история спорная, это возможно только если пакет пройдет дополнительную обработку через cpu. Но игрунам, например, от этого ничуть не легче.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, [anp/hsw] сказал:

В провайдерстве давно уже вымер.

Не сказал бы.

Сейчас мы уже мультикаст не используем, раньше использовали для IPTV.

И на некоторых моделях коммутаторах без него приемлемого качества получить не удавалось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, alibek сказал:

И на некоторых моделях коммутаторах без него приемлемого качества получить не удавалось.

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

А то я видел массу ушибленных коммутаторов, которые могут пропустить pause frame в аплинк при выключеном flow control (вместо того, чтобы дропнуть его еще на приходе).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот как плохо, когда нет микротика?

 

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

Далее смотрим, в шейпере в сторону 10М порта постоянно находятся данные в количестве 100-150киб и 60-100 пакетов.

Умножьте на 10 и будет ситуация с 10г портом.

 

 

mtbuftest.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, Saab95 сказал:

На нем легко реализуется данная задача - берется порт на 1г и порт на 10м.

Пропущено "берется 3 микротика".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет всем.

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

 

Кароче кто может обяснить поведение коммутатора DGS 3620 внизу.

Схема было/стало (ядро и вся коммутация бегает дальше ч/з SNR, я переключил нижний свич напрямую в SNR, укоротив "гирлянду"):

32193461_m.png

 

Все вланы, снупинги и тд для нижнего коммутатора остались прежними. Трафик такой же.

По легенде я просто хотел разгррузить верхний DGS, что и сделал. 

CPU нижнего свича после переключения:

32193505_m.png

 

На остальных +/- так же осталось. Убрал примерно гиг трафика.

Я понимаю что снижение нагрузки на проц это хорошо, ну или как минимум неплохо, но чо хоть я сделал то такого?

Это буффер выдохнул? (в схеме DGS-DGS когда было)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.