[uanog] switch's port buffers
Alexander V Soroka
alex at euro.net.ua
Tue Jan 4 14:08:55 EET 2022
Привет !
частично ответыт тут есть:
ASIC vs. FPGA: What’s the difference?
https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference
Цитаты:
...Термин ASIC является аббревиатурой от Application Specific
Integrated Circuit. Как следует из названия, ASIC - это интегральная
схема, разработанная для конкретного использования или приложения,
которую нельзя перепрограммировать или изменить после того, как она
будет произведена. ASIC разработан в соответствии со спецификациями
продукта и не предназначен для общего использования. Более
распространенным термином является SoC (система на кристалле), который
представляет собой ASIC, который действует как целая подсистема,
включая ЦП, память и периферийные устройства.
... FPGA (или всем знакомое ПЛИС) расшифровывается как
Field Programmable Gate Array. FPGA производится для общего использования с
использованием настраиваемых логических блоков и программируемых
межсоединений. Это означает, что FPGA может быть запрограммирована и
перепрограммирована (в зависимости от типа FPGA) для выполнения многих
функций после ее изготовления.
Типы ПЛИС
ПЛИС можно классифицировать двумя способами. Либо по их внутренней
архитектуре, либо по типу программируемой технологии. В рамках этих
двух классификаций существует несколько типов ПЛИС.
...
ЧТО Я могу сказать: с точки зрения "на вырост" я бы всегда выбирал
FPGA. Потому что технологии меняются, а ПО всегда можно переписать. У
майнеров есть несколько видео про то как FPGA делает некоторые виды
видеокарт, просто потому что можно "выпилить" внутри архитектуру
работы именно под то что вам нужно, и получить И аппартно заточенное И
программно заточенное решение. Оно по-любому будет быстрее чем
"примерно подходящее", но может проиграть "очень острозаточенному для
1 операции".
Я бы в проектах использовал только FPGA.
Tuesday, January 4, 2022, 1:59:15 PM, Yevgen Ionov yevgen.ionov at gmail.com you wrote:
YI> Привет Максим,
>> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
YI> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
YI> Беглый просмотр документа указывает на наличие инструментов для
YI> программируемых сетей (P4 Toolkit) & P4 programmable switches, которые по
YI> своей архитектуре отличается от традиционных.
YI> И если я правильно понимаю данное обсуждение, речь идет о традиционных
YI> ASIC-based свитчах с фиксированными размерами buffers.
YI> Мне лично интересно понять:
YI> 1. Обсуждается ли тема в среде операторов использования programmable
YI> switches & P4?
YI> С точки зрения управления flows, congestions, etc использование P4 сильно
YI> отличаться от традиционного подхода и протоколов.
YI> На различных Telco презентациях об этом достаточно много разговоров, но
YI> есть ли практическое развитие?
YI> 2. Корректно ли сравнивать в данном случае выводы для программируемой
YI> архитектуры FPGA vs традиционную ASIC-based архитектуру?
YI> Спасибо.
YI> On Thu, 30 Dec 2021 at 11:57, Maksym Tulyuk <maksym at tulyuk.com> wrote:
>> Привет!
>>
>> У меня совсем другие выводы:
>> 1) из последнего доклада "We still know very little about buffer size” и
>> ИМХО это лучший вывод/совет
>> 2) все академики продолжают обсуждать TCP tuning и не хотят видеть, что
>> уже в 2019 у Deutsche Telekom он составлял всего 84.4% (все остальное - UDP
>> с быстрым ростом QUIC)
>> 3) все доклады рассказывают про MTU size 1500, хотя в реальном мире такого
>> трафика 50% максимум https://stats.ams-ix.net/sflow/size.html и как видно
>> из графика 35% - это пакеты размером 64-127 bytes
>>
>> Из интересного:
>>
>> - Understanding switch buffer utilization in CLOS data center fabric
>> (Verizon)
>> http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx
>> - Buffer sizing and Video QoE Measurements at Netflix
>> http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf
>> - Queueing at the Telco Service Edge (Deutsche Telekom)
>> http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf
>> - Buffer Sizing Experiments at Facebook
>> http://buffer-workshop.stanford.edu/papers/paper30.pdf
>>
>> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
>> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
>>
>> НО это все было в 2019, а сейчас кажется что Гугл был прав и будущее это
>> UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.
>>
>> Максим
>> On 28 Dec 2021, 10:02 +0100, Volodymyr Litovka <doka at funlab.cc>, wrote:
>>
>> Привет,
>>
>> для любителей лонгридов, есть прекрасная статья про стратегии буферизации
>> и обработки очередей по результатам воркшопа в Стэнфордском университете в
>> 2019 году - "*It hosted 98 attendees from 12 economies with 26 from
>> academia and 72 from industry.*" --
>> https://blog.apnic.net/2019/12/12/sizing-the-buffer/
>>
>> Для совсем уж любителей копать - материалы этого воркшопа доступны тут:
>> http://buffer-workshop.stanford.edu/program/
>>
>> [ ... ] buffers also add additional lag to a packet’s transit through the
>> network. If you want to implement a low jitter service, then deep buffers
>> are decidedly unfriendly! The result is the rather enigmatic observation
>> that network buffers have to be as big as they need to be, but no bigger!
>>
>> Так какими же? :) Главные выводы из статьи:
>>
>> === 1. утверждение "буфер 40MB - отстой" не выдерживает проверки
>> академическими исследованиями ===
>>
>> A study by a Stanford TCP research group in 2004
>> <http://doi.acm.org/10.1145/1030194.1015499> used the central limit
>> theorem to point to a radically smaller model of buffer size. Link
>> efficiency can be maintained for N desynchronized flows with a buffer that
>> is dimensioned to the size of:
>>
>> *Size* = (*BW* ∙ *RTT*) / √*N*
>>
>> This is a radical result for high-speed extended latency links in a busy
>> network. The consequences on router design are enormous:
>>
>> “For example, a 1 Tb/s ISP router carrying one TCP flow with an RTTmin of
>> 100ms would require 12.5 GB of buffer and off-chip buffering. *If it
>> carries 100,000 flows, then the buffer can be safely reduced to less than
>> 40MB, reducing the buffering and worst-case latency by 99.7%*. With small
>> buffers, the buffer would comfortably fit on a single chip switch ASIC.”
>> Nick McKeown et. al. Sizing Router Buffers (Redux)
>> <https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/>
>>
>> иными словами, совершенно не случайно большинство коммутаторов из списка
>> https://people.ucsc.edu/~warner/buffer.html в портовом диапазоне 48x10/25
>> + 6-8/100 укомплектованы размером буфера 32-40MB - этого достаточно. А если
>> учесть, что операторские реалии - это 1/10G агрегация (даже не 25), то
>> можно предположить, что оператор is absolutely safe с буфером такого
>> размера в своих коммутаторах.
>>
>> === 2. использование inline notification улучшает качество передачи
>> трафика ===
>>
>> The advantage of ECN is that the sender is not placed in the position of
>> being informed of a congestion condition well after the condition has
>> occurred. Explicit notification allows the sender to be informed of a
>> condition as it is forming so that it can take action while there is still
>> a coherent ack pacing signal coming back from the receiver (that is before
>> packet loss occurs).
>>
>> However, ECN is only a single bit marking. Is this enough? [ ... ] The
>> conclusion from one presentation is that the single-bit marking, while
>> coarse and non-specific is probably sufficient to moderate self-clocking
>> TCP flows such that they do not place pressure on network buffers, leaving
>> the buffers to deal with short term bursts from unconstrained sources.
>>
>> [ ... ]
>>
>> And if we want to reduce buffer size and maintain efficient and fair
>> performance how can we achieve it? One view is that sender pacing can
>> remove much of the pressure on buffers, and self-clocking flows can
>> stabilise without emitting transient bursts that need to be absorbed by
>> buffers. Another view, and one that does not necessarily contradict the
>> first, is that the self-clocking algorithm can operate with higher
>> precision if there was some form of feedback from the network on the state
>> of the network path. This can be as simple as a single bit (ECN) or a
>> complete trace of path element queue state (HPCC).
>>
>>
>> всё же имеет смысл хотеть поддержки ECN
>>
>> === 3. flow-aware traffic management не является однозначной заявкой на
>> успех ===
>>
>> If the network was in a position to be able to classify all currently
>> active flows into either elephants or mice, then the network could be able
>> to use different queuing regimes for each traffic class. This sorting adds
>> to the cost and complexity of packet switches, and if scaling pressures are
>> a factor in switch design then it’s not clear that the additional cost of
>> switch complexity would be offset by a far superior efficiency outcome in
>> the switching function.
>>
>>
>> === 4. и если вдруг вендора начинают говорить про гигантские (напр 100ms)
>> буфера ===
>>
>> Further analysis reveals an estimate of packet drop rates if the network’s
>> buffers were reduced in size, and for this particular case, the analysis
>> revealed that an 18msec buffer would be able to sustain a packet drop rate
>> of less than 0.005%.
>>
>>
>> Спасибо.
>>
>>
>> On 15.10.2021 14:48, Volodymyr Litovka wrote:
>>
>> Привіт,
>>
>> а ось тут мене запитали, а я не знаю як відповісти :) Я розумію, що
>> питання може звучати трішки дивно, але тим не менш -
>>
>> за вашим досвідом, скільки буферу (на порт або shared) достатньо для
>> уникнення або зниження до непомітного рівня втрат пакетів при появі traffic
>> bursts? Ну тобто цікавлять не теоретичні розрахунки після відповідей на
>> питання на кшталт "а який час барста?", "а скільки складає барст у
>> відсотках до нормального" та таке інше, а по робітничо-селянському -
>> поточний досвід в живій мережі в поточних умовах поточного Інтернету? Ну,
>> наприклад, на будинковому комутаторі 24x1G + 2x10G з підключеними
>> середньостатистичними абонентами?
>>
>> Хтось взагалі цим питанням париться? :)
>>
>> Дякую.
>>
>> --
>> Volodymyr Litovka
>> "Vision without Execution is Hallucination." -- Thomas Edison
>>
>> --
>> Volodymyr Litovka
>> "Vision without Execution is Hallucination." -- Thomas Edison
>>
>> _______________________________________________
>> uanog mailing list
>> uanog at uanog.kiev.ua
>> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>>
>> _______________________________________________
>> uanog mailing list
>> uanog at uanog.kiev.ua
>> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
--
Best regards,
Alexander V Soroka http://www.svr.ua/
AS106-RIPE
mailto:alex at euro.net.ua
More information about the uanog
mailing list