Jump to content

    
Sign in to follow this  
Koluchiy

Ethernet: насколько распространена поддержка Flow control?

Recommended Posts

В случае если используется BASE-TX, то сеть на L2 именно и состоит из набора P2P.

Не совсем так. В одноранговых сетях peer-to-peer каждый хост должент выполнять административные функции и отслеживать общую конфигурацию сети. Например средства MS-сети, встроенные в Windows, так называемые "подключения". В принципе, пользоваться услугами такой сети, где все равны в правах, неправильно из соображений элементарной безопасности. В более-менее серьезных организациях не используется. Поэтому вы ошибаетесь насчет повсеместного p2p.

"И это хорошо!" ©. А зачем хосту-источнику знать о блокировке приема хоста приемника, если источник как раз может чудно слать данные в буфер свича? Есть возможность - данные из хоста отправляем, ничего не ждем, а оборудование на маршруте само разберется. Я вот чудный гигабитный свичик SLM2008 прикупил - никак не могу определить сколько у него памяти на борту - по разным источникам от 4 до 32 Мегабайт. "Это жжжж - наспроста" © - имхо, Циско что-то знает, раз столько памяти в свич ставит.

Вы снова ошибаетесь. Вот типичный пример. Есть некий источник данных, который может формировать UDP пакеты и отправлять их по гигабитному Ethernet каналу в сеть со скоростью примерно 800 mbps. В этой сети, имеется приемник этих UDP-пакетов, который может принимать и обрабатывать поток данных не быстрее, например 400 mbps. Хосты соединены через гигабитный свитч. Теперь прикиньте, за какое время переполнится 32 Мегабайт буфер вашего хваленого свитча, если торомозить порт свитча и не торомозить непосредственно источник данных? Правильный ответ- за 1 минуту.

Нет, не так - по стандарту PAUSE тут же в свиче и умирает:

Ничего личного, но криво читаете стандарты. Там говорится, что PAUSE умирает в bridge, но не в switch. Это сильно разные вещи. и для разных целей. Еще предлагаю подумать- откуда в свитчах на портах вдруг взялся MAC? Его там нет по определению. А раз нет, то и управления на уровне MAC устройства- тоже нет. Свитч воспринимает все входящие пакеты одинаково, включая пакеты FlowControl.

Upd2: просмотрел Ethernet MAC контроллеры для которых писал код (SAM7X, LPC17/23, MPC83xx, STM32F2xx) нигде не нашел в регистрах как задавать DA - везде PAUSE фреймы генерируются автоматически, с фиксированным в стандарте малтикастом. На прием аналогично - проверяется именно малтикаст. Так что - на упомянутых контроллерах фрейм PAUSE с уникальным DA это типа "закат солнца вручную" - только искусственно сформировать и отослать как обычный пакет.

Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных. И представьте, этот пакет прекрасно проходит через свитч и достигает именно источника!

 

 

 

Share this post


Link to post
Share on other sites
Еще предлагаю подумать- откуда в свитчах на портах вдруг взялся MAC? Его там нет по определению.

Читал-читал, но на этом перле уж не сдержался. :lol:

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

Share this post


Link to post
Share on other sites
Не совсем так. В одноранговых сетях peer-to-peer каждый хост должент выполнять административные функции и отслеживать общую конфигурацию сети. Например средства MS-сети, встроенные в Windows, так называемые "подключения".

Мда, "смешались в кучу люди, кони" (с).

Есть такая вещь - OSI - Open Systems Interconnection. Она описывает уровни сетевого взаимодействия, классической считается 7-уровневая модель. Так вот, обсуждаемый в данном топике Flow Control относится к уровню L2 (канальный, Data Link Layer). А все что Вы написали - администрирование, конфигурирование и прочее - как минимум парой-тройкой уровней модели выше и к топику имеет очень и очень слабое отношение.

Поэтому вы ошибаетесь насчет повсеместного p2p.

Повторюсь - p2p на канальном уровне (L2). Если используется Ethernet на витых парах, то порт каждого хоста на канальном уровне общается непосредственно с портом другого хоста или свича. И каждое такое соединение на канальном уровне - точка-точка, отдельный сетевой физический сегмент.

 

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

ИМХО, это не типичный пример, а сложности FPGA-шников при реализации нормального надежного транспортного протокола типа TCP.

 

В этой сети, имеется приемник этих UDP-пакетов, который может принимать и обрабатывать поток данных не быстрее, например 400 mbps. Хосты соединены через гигабитный свитч. Теперь прикиньте, за какое время переполнится 32 Мегабайт буфер вашего хваленого свитча, если торомозить порт свитча и не торомозить непосредственно источник данных? Правильный ответ- за 1 минуту.

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

 

Ничего личного, но криво читаете стандарты. Там говорится, что PAUSE умирает в bridge, но не в switch. Это сильно разные вещи.

Нет, вот именно ethernet switch на витых парах и является bridge - поскольку он соединяет физически отдельные сетевые сегменты на уровне L2. То что эти сегменты используют физику одного стандарта (а не разных) не имеет ровно никакого значения - все равно это bridge.

 

Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных. И представьте, этот пакет прекрасно проходит через свитч и достигает именно источника!

Он проходит и достигает, поскольку Вы нарушили стандарт и засунули в пакет не требуемое фиксированное малтикастовое значение DA, а индивидуальное. А ведь вполне может попасться такой свич который еще и на управляющее поле пакета смотреть будет - от тогда PAUSE может и не дойти. И Вы хотите сказать, что если указать фиксированный DA в PAUSE, то возникают проблемы? ИМХО, тогда это не очень хорошее оборудование (свич).

 

Итого, для меня результаты дискуссии такие:

 

1. Стандарт четко описывает чего в PAUSE посылается, и как PAUSE на уровне L2 коммутируется.

2. Распространенные микроконтроллеры не имеют средств задания индивидуального DA в отсылаемом PAUSE и не понимают индивидуальный DA в принимаемом PAUSE.

3. Просто здравый смысл (пример с NAS, DLNA-телевизором и тестовым девайсом)

 

Дальше, в-общем-то, обсуждать нечего.

 

Когда я реализовывал свой сетевой стек, вопрос Flow Control на уровне L2 обдумывал тщательно, в итоге его не использую вообще. Все функции FC возложены на транспортный уровень - в моем случае TCP. Правильный выбор размера окна решает(_в общем случае_, а не только при использовании ethernet) проблему переполнения и прекрасно масштабируется, например HTTP-сервер на 8 сокетов, живет на 4К буферной памяти с окнами по 512 байт на LPC23, а искази-таргет выжимает по TCP 70Мбайт/сек с мегабайтным окном на MPC8347.

 

У Вас в FPGA нет TCP (по крайней мере такого же быстрого как аппаратный UDP), отсюда и желание использовать Flow Control на нижних уровнях сетевой модели. Я думаю, если сделаете по стандарту (фиксируете DA в PAUSE) и возьмете нормальный свич, то ситуация хуже не станет.

Share this post


Link to post
Share on other sites
Дальше уже, в-общем-то, обсуждать нечего.

Вы правы. У нас сильно разные практические задачи. Найти общий язык и доказать что-либо вряд-ли получится.

У Вас в FPGA нет TCP (по крайней мере такого же быстрого как аппаратный UDP), отсюда и желание использовать Flow Control на нижних уровнях. Я думаю, если сделаете по стандарту (фиксируете DA в PAUSE) и возьмете нормальный свич, то ситуация хуже не станет.

Даже пробовать, и потом плясать с бубном вокруг зависшей системы,- я не стану. У меня прекрасно работает, как я написал- с DA, равным MAC адресу источника данных. И обычная сетевая карта с включенной опцией FlowControl в хосте-источнике прекрасно понимает PAUSE-пакеты, которые пришли к ней через свитч. Несмотря на то, что адрес назначения стоит не мультикастовый. Узнает по значению поля FrameType и коду операции FlowControl.

 

Честно говоря, я не понимаю о чем мы спорим. Я представил Вам живой работающий пример высокоскоростной передачи данных ( до 860 mbps). Все работает на jumbo-пакетах в протоколе UDP с притормаживанием на MAC уровне. В любимом вами TCP такой поизводительности достичь невозможно, Да и проблема FlowControl в TCP вообще не актуальна. TCP было отвергнуто с самого начала. А FPGA было выбрано потому, что софтовый стек на микроконтроллере не обеспечивает требуемую производительность на гигабитном канале Ethernet. Не о чем спорить.

 

Share this post


Link to post
Share on other sites
Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных.

У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

 

Share this post


Link to post
Share on other sites
У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

ИМХО, конфигурировать PHY нужно в той части, в которой оно сообщает своему Link Partner о поддержке Flow Control. Я понимаю это так, что самому PHY принимаемые-передаваемые фреймы PAUSE безразличны и в самом PHY ни на что не влияют. Но при установлении линка два PHY между собой проводят negotiations - меняются между собой специальными фреймами (которые на MAC не транслируются), и вот там передается информация о поддержке Flow Control MAC-ом каждой стороны. Поскольку PHY о возможностях имеющегося на его стороне MAC ничего не знает, то обычно внутри PHY имеется регистр, куда софт до разрешения линка и проведения negotiations записывает информацию о том как имеющийся в наличии MAC и его драйвер будут поддерживать PAUSE. Потом линк разрешается, PHY проводят между собой negotiations и софт на удаленном хосте может прочитать из своего PHY результаты "переговоров" и узнать, будет ли наш MAC передавать и принимать PAUSE-фреймы.

 

 

Share this post


Link to post
Share on other sites
У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

Признаться, специально такой конфигурацией PHY не занимался. Использую PHY autonegotiation, которая происходит автоматически при вкл.питания. По его окончании всегда можно прочесть в регистрах PHY, на что способно данное подключение. У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию. Эту опцию можно изменить потом программно на disable. Но тогда, вслед за этим, придется также программно запускать и autonegotiation, чтобы дать знать приемнику на другой стороне канала связи- мол, не шли мне пауз-пакеты, я их все равно не понимаю.

 

Сами же пауз-пакеты формирует MAC. PHY же только их отправляет, ему до лампочки.

 

Share this post


Link to post
Share on other sites
У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию.

Нет, надо смотреть даташит на конкретный PHY чип. Например, MV88E1111 конфигурируется внешними ножками, что именно декларировать при negotiation. А у KSZ8031 - по дефолту после сброса стоит "No PAUSE".

 

 

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this