Jump to content
Калькуляторы

Flow Control на управл железе

Поясните плиз принцип работы Flow Control на управл оборудовании ?

Share this post


Link to post
Share on other sites

с форума dlink :

Он нужен только в том случае если на клиентском порту может быть подключено устройство, например, которое не может работать на скорости 100 Мбит/с, а только на 10 Мбит/с, и при этом режим на нём выставлен как Auto. Flow Control позволяет более медленнему получателю на одном линке послать стоповый бит, тем самым приостановить передачу более быстрым устройством. Затем передача может быть возобновлена. Так что на магистралях однозначно выключать.

Share this post


Link to post
Share on other sites

Показательная цитата, прямо - "В ЦЫТАТНЕГ!!" 8-)

Д-Линку ещё не рассказали, что скоростей в мире бывает больше двух? 8-D

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Поясняю на пальцах:

Есть коммутатор, ему сыпется трафик. Неравномерно так сыпется. То густо, то пусто. Ещё у него есть очереди.

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

 

Если нет FC, то возможны два варианта:

1) клиент захлебнётся

2) клиент что-то не скушает (пакеты подропаются)

 

Если есть FC, то клиент, когда ему поплохело, может попросить коммутатор чуток подождать с отправкой. Больше, чем очереди на коммутаторе, коммутатор ждать не будет и сам подропает.

 

Продвинутый вариант: FC есть дальше по линку, самый продвинутый - до источника трафика, что даст возможность попросить сам источник трафика попридержать отправку, но об этом проще не думать вовсе.

 

Особенно полезен FC в связке с rate-limit, если девайс (например, хранилище) в курсе про FC. Тогда (силами девайса) можно сделать "почти как шейпинг", - в отличие от голого rate-limit, за который надо показательно четвертовать.

Share this post


Link to post
Share on other sites

усе понятно, к магистралем FC отношение не имеет, тк там должны быть одинаковые скорости доступа

Share this post


Link to post
Share on other sites

FC на абонентских портах — зло. Например есть абонент-торрентораздавальщик. Сидит себе, раздаёт на 100 mbps. И тут вылазит десятимегабитчик и начинает с него качать; при набегании трафика качок кричит сидеру «стооой!!», и, вуаля, сидер понижает скорость до 10 mbps. В это время все оставшиеся качки и сам сидер начинают компосировать мозги техподдержке!

Share this post


Link to post
Share on other sites
Продвинутый вариант: FC есть дальше по линку, самый продвинутый - до источника трафика, что даст возможность попросить сам источник трафика попридержать отправку, но об этом проще не думать вовсе.

Кончайте читать форум Д-Линка и начинайте думать своей головой уже.

Share this post


Link to post
Share on other sites
Особенно полезен FC в связке с rate-limit, если девайс (например, хранилище) в курсе про FC. Тогда (силами девайса) можно сделать "почти как шейпинг", - в отличие от голого rate-limit, за который надо показательно четвертовать.
Жестокий Вы. То расстрелять, то оперировать через не приспособленные для этого отверстия :) А можно для потенциальной жертвы четвертования раскрыть тему перед казнью. Допустим рейт-лимит без фс. Тсп разве не подстроится уменьшая размер окна? Наблюдал, что тсп-ип стек винХП в результате дает скорость cущественно меньше указанной в райт-лимит, винВиста и 2008 - уже лучше, в линуксе - еще лучше. Про не тсп-трафик молчу.

 

 

http://forum.nag.ru/forum/index.php?showto...mp;#entry422778

>>wireshark с обеих сторон и флудогенератор ;-)

>>Сравнить выход и получение, особенно в сравнении "ДО" с "ПОСЛЕ". Будете сильно удивлены ростом нагрузки "из ниоткуда".

 

Для тех, кто не проводил такого эксперимента, на раскроете тему?

 

Random early detection кажется на такое же поведение тсп-протокола расчитывает, дропая пакеты из самых тяжелых тсп-сессий.

Share this post


Link to post
Share on other sites

TCP, кроме того, периодически пытается приподнять скорость. Результат - дропы. А т.к. rate-limit на свичах как правило сделан на внутренних счётчиках, то что именно подропается, - ну почти можно считать рандомным. После чего перепосыл и новые дропы, снижение скорости и опять перепосыл. Оверхэд выглядит просто удручающе :-(

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

Share this post


Link to post
Share on other sites

Спасибо за ответ. А не просветите чуть глубже про механизм фс?

Вот читаю про формат кадра ПАУЗЕ

"В поле DA (Destination Address) кадра данного типа должен быть размещен код 01-80-C2-00-00-01, который представляет собой Multicast адрес станций, которые поддерживают выполнение данной процедуры, или Unicast адрес конкретного абонента в сети, формирующего избыточный трафик для данной станции.

В поле SA (SOURCE Address) кадра типа «Пауза» помещается MAC - адрес станции, которая инициирует выполнение процедуры управления потоком. "

 

Так все же дест-мак - мультикастовый в основном или юникастовый? И зависит ли работоспособность фс от его поддержки на всей цепочке свичей? И при чем тут тогда пример с торентом и 10м в постах выше, если скорость будет снижена для трафика на конкретный мак? Не вообще же скорость линка изменится. Как понимать "и, вуаля, сидер понижает скорость до 10 mbps. В это время все оставшиеся качки и сам сидер начинают компосировать мозги техподдержке! " Как при этом пострадают другие качки?

 

 

 

Share this post


Link to post
Share on other sites

Там их два, вы читаете про новый, для фуллдуплекса. Для халфдуплекса - back pressure - он действительно душит всю передачу. А какой адрес клиент пошлёт - зависит от самого клиента.

Share this post


Link to post
Share on other sites

Там их два, вы читаете про новый, для фуллдуплекса. Для халфдуплекса - back pressure - он действительно душит всю передачу. А какой адрес клиент пошлёт - зависит от самого клиента.

Спасибо.

Share this post


Link to post
Share on other sites

уточнение: back pressure ОБЫЧНО дальше своего коммутатора не уходит, поэтому рассказ про 10м и торренты тут ни при чём.

Share this post


Link to post
Share on other sites
уточнение: back pressure ОБЫЧНО дальше своего коммутатора не уходит

back pressure - такой же Flow Control, как и обмен пакетами Pause. И, например, те же RTL83xx прекрасно ретранслируют back-pressure с одного порта 10HD на другой 100FD в виде pause-фреймов, конечно, в тот момент, когда переполняются буфера. На micrel'овских свичевых камнях - аналогично. Так что ситуация с десятимегабитным клиентом и торрентами вполне имеет право на жизнь. Тут, конечно, руки надо отрывать тем, кто "изобретал" протокол в торрент-клиентах - такая ситуация свидетельствует, что нет никаких потуг к регулировке скорости передачи (хотя-бы аля TCP). К сожалению, руки им не оборвешь :(

Share this post


Link to post
Share on other sites
уточнение: back pressure ОБЫЧНО дальше своего коммутатора не уходит

back pressure - такой же Flow Control, как и обмен пакетами Pause. И, например, те же RTL83xx прекрасно ретранслируют back-pressure с одного порта 10HD на другой 100FD в виде pause-фреймов, конечно, в тот момент, когда переполняются буфера. На micrel'овских свичевых камнях - аналогично. Так что ситуация с десятимегабитным клиентом и торрентами вполне имеет право на жизнь. Тут, конечно, руки надо отрывать тем, кто "изобретал" протокол в торрент-клиентах - такая ситуация свидетельствует, что нет никаких потуг к регулировке скорости передачи (хотя-бы аля TCP). К сожалению, руки им не оборвешь :(

Все же не понятно, как пострадают другие качки. Может я туплю, но механизм не ясен. 10м клиент уведомит так или иначе 100м сидера - "притормози", он притормозит, на сколько это возможно, передачу на конкретный мак. И все. Каков механизм того, что он вообще для всех скинет скорость?

Share this post


Link to post
Share on other sites
10м клиент уведомит так или иначе 100м сидера - "притормози", он притормозит, на сколько это возможно, передачу на конкретный мак.

Да не на конкретный мак, в том то и дело. Передавателю придет pause-фрейм, и он остановит все передачи. Блокируется порт.

Share this post


Link to post
Share on other sites
10м клиент уведомит так или иначе 100м сидера - "притормози", он притормозит, на сколько это возможно, передачу на конкретный мак.

Да не на конкретный мак, в том то и дело. Передавателю придет pause-фрейм, и он остановит все передачи. Блокируется порт.

vIv писал:

>>back pressure - он действительно душит всю передачу

 

Как я понял - это касается только back pressure. Pause более избирательно может действовать.

 

Вы написали, что back pressure свичем легко преобразуется в pause на нужный порт. Так почему тогда будет полная блокировка? В формате паузе может варьироваться дст-мак - или юникаст или мультикаст, а срц-мак там будет по любому.

Share this post


Link to post
Share on other sites

Вы ещё сидите на half-duplex? 8-)

Share this post


Link to post
Share on other sites
В формате паузе может варьироваться дст-мак - или юникаст или мультикаст, а срц-мак там будет по любому.

Во-первых, варьируется src. Dst фиксирован (специальный мультикастный мак), а src - игнорируется.

 

Первоисточник - http://cbsie.dyndns.info/802.3-2005_section2.pdf

Курить Annex 31B (ну и остальное по референсам, если надо добиться полного просветления ;) )

 

Upd: более правильная ссылка для скачивания всей пачки 802.3 - http://standards.ieee.org/getieee802/802.3.html

Edited by Rst7.CBSIE

Share this post


Link to post
Share on other sites
Вы ещё сидите на half-duplex? 8-)
Это вопрос к m_medved, его пример. Пример выглядит как жизненный, наблюдаемый лично, а не в духе "что, если". Или описанная ситуация не соотв. дейсвительности и m_medved чего-то не тогой, или... тогда хочется понять механизм :) А то вон даже мужики на форуме длинк-а - и те не в курсе :)

Да и вообще, для раскрытия заявленной темы, так сказать.

Share this post


Link to post
Share on other sites
В формате паузе может варьироваться дст-мак - или юникаст или мультикаст, а срц-мак там будет по любому.

Во-первых, варьируется src. Dst фиксирован (специальный мультикастный мак), а src - игнорируется.

 

Первоисточник - http://cbsie.dyndns.info/802.3-2005_section2.pdf

Курить Annex 31B (ну и остальное по референсам, если надо добиться полного просветления ;) )

 

Upd: более правильная ссылка для скачивания всей пачки 802.3 - http://standards.ieee.org/getieee802/802.3.html

http://www.ieee802.org/3/ad/public/sept98/seifert_090198.pdf

>>Use DA in reserved multicast space

>>01-80-C2-00-00-00 through 01-80-C2-00-00-10

>>Alternative: Use the unicast address of the port

Тогда что такое unicast address of the port и когда используется такая альтернатива?

 

Share this post


Link to post
Share on other sites
Тогда что такое unicast address of the port и когда используется такая альтернатива?

Для передачи STP и прочего. Посмотрите, как в документе по Вашей ссылке алгоритм обработки попадает в альтернативу PAUSE (на всех 3х диаграммах) - только при DA=01-80-C2-00-00-xx.

Share this post


Link to post
Share on other sites
Тогда что такое unicast address of the port и когда используется такая альтернатива?

Для передачи STP и прочего. Посмотрите, как в документе по Вашей ссылке алгоритм обработки попадает в альтернативу PAUSE (на всех 3х диаграммах) - только при DA=01-80-C2-00-00-xx.

Да, действительно.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now