aprox 0 9 января, 2012 Опубликовано 9 января, 2012 · Жалоба В случае если используется 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-адрес источника данных. И представьте, этот пакет прекрасно проходит через свитч и достигает именно источника! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vitan 2 9 января, 2012 Опубликовано 9 января, 2012 · Жалоба Еще предлагаю подумать- откуда в свитчах на портах вдруг взялся MAC? Его там нет по определению. Читал-читал, но на этом перле уж не сдержался. Уважаемый! Вы хоть немного теории почитайте для начала, ну нельзя же так, только по своим представлениям о мире судить. Эдак можно и до земли на трех китах дойти! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 9 января, 2012 Опубликовано 9 января, 2012 · Жалоба Не совсем так. В одноранговых сетях 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) и возьмете нормальный свич, то ситуация хуже не станет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 9 января, 2012 Опубликовано 9 января, 2012 · Жалоба Дальше уже, в-общем-то, обсуждать нечего. Вы правы. У нас сильно разные практические задачи. Найти общий язык и доказать что-либо вряд-ли получится. У Вас в FPGA нет TCP (по крайней мере такого же быстрого как аппаратный UDP), отсюда и желание использовать Flow Control на нижних уровнях. Я думаю, если сделаете по стандарту (фиксируете DA в PAUSE) и возьмете нормальный свич, то ситуация хуже не станет. Даже пробовать, и потом плясать с бубном вокруг зависшей системы,- я не стану. У меня прекрасно работает, как я написал- с DA, равным MAC адресу источника данных. И обычная сетевая карта с включенной опцией FlowControl в хосте-источнике прекрасно понимает PAUSE-пакеты, которые пришли к ней через свитч. Несмотря на то, что адрес назначения стоит не мультикастовый. Узнает по значению поля FrameType и коду операции FlowControl. Честно говоря, я не понимаю о чем мы спорим. Я представил Вам живой работающий пример высокоскоростной передачи данных ( до 860 mbps). Все работает на jumbo-пакетах в протоколе UDP с притормаживанием на MAC уровне. В любимом вами TCP такой поизводительности достичь невозможно, Да и проблема FlowControl в TCP вообще не актуальна. TCP было отвергнуто с самого начала. А FPGA было выбрано потому, что софтовый стек на микроконтроллере не обеспечивает требуемую производительность на гигабитном канале Ethernet. Не о чем спорить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Костян 0 9 января, 2012 Опубликовано 9 января, 2012 · Жалоба Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных. У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 10 января, 2012 Опубликовано 10 января, 2012 · Жалоба У меня к Вам практический вопрос. Нужно ли 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-фреймы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 10 января, 2012 Опубликовано 10 января, 2012 · Жалоба У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ? Признаться, специально такой конфигурацией PHY не занимался. Использую PHY autonegotiation, которая происходит автоматически при вкл.питания. По его окончании всегда можно прочесть в регистрах PHY, на что способно данное подключение. У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию. Эту опцию можно изменить потом программно на disable. Но тогда, вслед за этим, придется также программно запускать и autonegotiation, чтобы дать знать приемнику на другой стороне канала связи- мол, не шли мне пауз-пакеты, я их все равно не понимаю. Сами же пауз-пакеты формирует MAC. PHY же только их отправляет, ему до лампочки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 10 января, 2012 Опубликовано 10 января, 2012 · Жалоба У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию. Нет, надо смотреть даташит на конкретный PHY чип. Например, MV88E1111 конфигурируется внешними ножками, что именно декларировать при negotiation. А у KSZ8031 - по дефолту после сброса стоит "No PAUSE". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться