Flow Control — опция необходима для защиты от переполнения буфера, включать необходимо при большом входящем трафике.
Включать или нет: только если наблюдаются странности в работе сети при большом количестве входящего трафика (обычно для игр включать ненужно).
Эта настройка предназначена для ситуаций, когда входящего трафика так много, что может произойти ошибка переполнения буфера, при котором оборудование отправляет команду паузы, после которой повторил отправку данных спустя некоторое время. Если подобную команду не послать — будет перегрузка, часть данных может потеряться, в итоге могут быть например глюки в игре. Также стоит понимать, что из-за команды паузы — увеличится значение пинга.
Функция полезна, когда происходит загрузка большого количества данных, например торренты. Игры обычно не имеют настолько активный трафик.
Функция например присутствует в сетевом адаптере D-Link DFE-550TX.
Flow Control включать стоит, когда наблюдаются непонятные задержки, обрывы, пропадания, лаги, тормоза при просмотре онлайн-видео. Также эту опцию включают при соединении разноскоростного оборудования или разноскоростных сетей, образно говоря, чтобы скоростная сеть не забила трафиком порт менеескоростной.
Опция сетевого адаптера Realtek:
Однако также спокойно может встречаться и в адаптерах других производителей, например Intel, Atheros.
Кстати открыть диспетчер устройств можно простым способом — зажмите Win + R, появится окошко Выполнить, вставьте команду devmgmt.msc и нажмите ОК.
Управление потоком IEEE 802.3x обеспечивает функции управления трафиком для режима полного дуплекса. Управление потоком позволяет улучшить работу сетевого адаптера в режиме полного дуплекса с коммутатором. При работе в полном дуплексе (при этом требуется непосредственное подключение к коммутатору) и при угрозе переполнения буфера данных коммутатора, сетевой адаптер получит специальный кадр паузы. Последующий промежуток времени защищает буфер от переполнения и предотвращает потерю данных. Эта технология может улучшить общую производительность сети, предотвращает потерю данных и помогает достичь оптимальной производительности в сети.
1) По сути Flow Control нужен в том случае если устройства на одном линке имеют разную произвиодительноть по приёму передаче кадров. Посылка стопового сигнала помогает избежпть потерь кадров.
2) Flow Control должен быть включён или выключен на обоих концах линка, т.е. сетевая карта конечно тоже должна поддерживать эту функцию и причём если на свитче она включена на сетвой карте она тоже должна быть включена.
3) Между управляемым и неуправляемым тоже может работать.
4) Последствия могут быть только если есть несоотвествие выбора режима работы функции на обоих концах линка.
5) На некоторых сериях свитчей например DES-30XX для корректной работы функции Bandwidth Control функция Flow control должна быть включена.
Как настроить сетевой адаптер на Windows 7: самое важное
Иногда при подключении интернета или использовании ресурсов локальной сети возникают проблемы. Могут вылезать ошибки подключения, получения IP адресов или конфигурации сетевого оборудования. Внутри компьютера или ноутбука, функцией подключения к локальной или глобальной сети, занимается сетевой адаптер. В статье мы как раз и поговорим про настройку сетевого адаптера для улучшения связи в интернете. Инструкция будет ходовая для всех версий Windows 7, 8 и 10.
Более подробная настройка
Мне постоянно приходят письма с вопросами – как более детально настроить сетевой адаптер для меньшего пинга в играх, для лучшего просмотра кино и большей скорости скачивания. Поэтому я решил написать более детальную статью. Ну, поехали! По идее она настраивается автоматически под рациональное использование ресурсов системы и самого устройства. Но конфигурацию можно корректировать под свои нужды.
Переходим во вкладку «Дополнительно». И так смотрите, у нас есть определённые свойства, которые мы можем включать (Enebled) или выключать (Disable). На новых версиях «Виндовс» может быть написано «Вкл» или «Выкл». А теперь разбёрем каждое свойство:
ВНИМАНИЕ! Параметры адаптера могут в какой-то степени улучшить показатели, в каком-то моменте ухудшить. Изменяя установки сетевого адаптера, лучше возьмите листочек и выпишите – что именно вы изменили, чтобы в случаи чего вернуть параметры обратно. Также я рекомендую скачать последнюю версию драйвера для вашей сетевой карты или Wi-Fi модуля и установить его. Только после этого заходим в характеристики
После изменения, следует перезагрузить компьютер или ноутбук, чтобы некоторые изменения вступили в силу. Установки сетевого адаптера всегда можно откатить обратно, самое главное не потеряйте тот листок с настройками.
ПРОСЬБА! Если я что-то не указал, или написал что-то не так – пишите смело в комментариях свои исправления или замечания, буду рад поучиться чему-то у своих читателей.
«Распределенное управление информационными потоками»/«Distributed Information Flow Control»
Мотивация Практически единственным способом обеспечивать безопасность и приватность данных в системе принято считать аутенификацию (отвечает на вопрос: «Кто это сказал?») и авторизацию («Что он имеет право делать с этими данными»). Т.е. если программе необходим доступ к некоторым данным, мы фактически имеем 2 варианта: отказать или поверить. Если мы не доверяем этой программе, то теряем возможность работать с ней и возможно лишаемся важной функциональности. Если же мы решаем, что доверяем программе (и/или ее разработчикам), то программа фактически становится «полновластным хозяином» этой информации (или копии). Такой принцип в литературе называют All-Or-Nothing — «Все или ничего».
Естественно, что этот принцип недостаточно гибок и кроме того является основной причиной многих уязвимостей в системах, таких как переполнение буфера. В общем случае, этот принцип не позволяет создавать более интересные приложения, где права доступа не ограничиваются традиционными: «no access», «read only» и «read/write». Оказывается, что существуют системы, которые позволяют намного более гибкие разграничения прав доступа к данным — системы с поддержкой управления информационными потоками. Самой главной особенностью этих систем является то, что они следят за данными на всем протяжении их жизненного цикла в системе. Вспомним, что традиционно система ответственна только за начальный доступ к данным, например, проверку имеет ли программа доступ к файлу, а что после этого программа делает с этими данными систему уже не интересует.
Классический пример. Допустим, что в системе есть 2 пользователя Алиса и Боб. Они хотят назначить встречу, но так чтобы не раскрывать слишком много информации о своем расписании недели. Можно ли в многопользовательской системе Linux/Unix/Windows написать программу таким образом, чтобы она имела одновременный доступ к календарям и Алисы, и Боба и гарантировала конфиденциальность обоих пользователей системы?
Самый простой способ — попросить «суперпользователя» написать такую программу или хотя бы правильно назначить права на уже существующе решение. Но этот путь создает как минимум 2 проблемы:
1. Нет гарантии, что программа не содержит логических ошибок и, например, не скопирует данные Алисы куда-нибудь еще (или админ неправильно назначит права). 2. Нужно доверять на все 100% «суперпользователю» и кроме того, такой процесс неинтерактивен, т.е. ждать пока админ напишет такую программу или выставит права.
Решение первой проблемы осуществляется при помощи систем с поддержкой управления информационными потоками.
В общем системы с поддержкой управления информационными потоками условно делятся на 2 категории: централизованные и распределенные (децентрализованные). К централизованным относят всем известные SELinux и AppArmor. В этой же статье я постараюсь рассказать о децентрализованных системах, на примере исследовательской (следовательно совершенно непригодной для реального использования, к сожалению) ОС Flume, т.к. имел некоторый опыт «общения» с ней. Децентрализованные системы позволяют избавиться и от второй проблемы — зависимость от суперпользователя.
(Distributed) Information Flow Control Если кратко, то идея контроля потока информации тривиальна и заключется в том, чтобы отслеживать как данные «перетекают» в системе от отправителя к получателю. Главная задача системы предотвратить несанкционированную утечку данных из нее. В общем случае, ни одна программа (кроме «привилегированной») не может иметь одновременный (в контексте жизни программы) доступ к приватным данным и любому «стоку информации» (sink), таким как монитор, принтер, сокет (AF_INET). Т.е. если программа один раз прочитала мои личные файлы, то после этого система не позволит этой программе иметь доступ к сети.
Для того чтобы сделать данные приватными необходимо явно это указать, например, с помощью специальных флагов/тэгов. Вот тут и главное различие между централизованными и распределенными системами. В первом случае существует особый пользователь — «менеджер безопасности», который ответственен за правильное «тэгирование» данных и определение прав доступа различных программ к таким данным. Например, можно назначить тэг «особо секретно» на файлы с вашими паролями или информацией о личных доходах и разрешить доступ к нему только для Vim/Emacs без прав (1) эти данные экспортировать куда бы то ни было и (2) снять эти тэги. Таким образом, даже если скомпроментировать ваши текстовые редакторы, то система (предполагая, что сама система безопасна и работает без ошибок) не позволит сохранить эти файлы где-либо в системе (/tmp) с другими более разрешающими тэгами и отослать их каким-либо образом в Интернет. Я не работал с SELinux, поэтому отсылаю вас к официальным руководствам за дальнейшей информацией.
В распределенных же системах любая программа/сущность может создавать свои тэги, назначать права и давать доступ к своим данным для других программ.
В ОС Flume вы можете создать тэг для доступа к некоторым личным данным. Причем у вас есть выбор. Можно отдать в открытый доступ права на назначение этого тэга и/или на его удаление. Допустим, что мы создали тэг tag1 и отдали в открытый доступ право , тогда любая программа может поместить этот тэг в свой собственный набор тэгов. Если мы создадим файл F и ассоциируем его с тэгом tag1, то любой процесс p1 может включить в свой набор тэгов этот тэг tag1 и после этого сможет читать все данные, помеченные tag1. Однако, так как не в открытом доступе, то этот процесс не сможет удалить tag1 со своего набора тэгов и отныне может общаться только с процессами, с набором тэгов, которые являются надмножеством аналогичного набора процесса p1.
В принципе система должна гарантировать, чтобы процесс мог послать сообщение другому только при условии, что получатель имеет как минимум такой же набор меток (или даже больший), что и отправитель, а также, что ни один процесс с непустым набором не имеет доступа к «стоку» информации (по мат индукции доказывается, что система с такими условиями безопасна). Disclaimer: в оригинальной статье более формальная формулировка и помимо тэга безопасности еще есть понятие тэга целостности, но в этой статье я его не рассматриваю.
Flume — это одна из разработанных систем, которая обеспечивает «правильность» потока информации. На системном уровне Flume — это Linux с модифицированной системой LSM, которая перехватывает основные системные вызовы, хранит информацию о тэгах, метках и проверяет на корректность потока данных от одного процесса к другому.
Заключение К сожалению, я не смогу охватить всех сфер применимости идей DIFC (даже тех, которые использовал в качестве мотивации проблемы) Есть немало отличных статей на эту тему, начинаю с самых классических (Jiff) до достаточно свежих HiStar/DStar или Resin. При наличии интереса к данной теме могу более подробно/формально рассказать о, например, фреймворке Resin от MIT. В свое время посчастливилось побеседовать с Барбарой Лисков (которая является, наверное, одной из главных авторитетов в данной области) на тему контроля потока информации, применимости этих принципов для других задач и просто заболел этой темой. Есть несколько интересных «видений» развития этой идеи: W5 (world wide web without walls) или Fabric. Но это уже совершенно другая история…
Тест не выявил описанной вами проблемы. Пришлите, пожалуйста, мне конфиг файл, вывод статистики по пакетам на порту, полное название сетевой карточки и версии драйверов и желательно dump Ethereal-а на (rbigarov(a)dlink(.)ru)
config igmp ipif System version 3 query_interval 125 max_response_time 10 robustness_variable 2 state disable config igmp ipif System last_member_query_interval 1
config wac method radius disable wac
disable mac_based_access_control config mac_based_access_control ports 1-28 state disable config mac_based_access_control method local config mac_based_access_control password default
disable dvmrp config dvmrp ipif System metric 1 probe 10 neighbor_timeout 35 state disable
config rip ipif System authentication disable tx_mode v2_only rx_mode v1_or_v2 state disable disable rip
config ospf ipif System area 0.0.0.0 priority 1 hello_interval 10 dead_interval 40 config ospf ipif System authentication none metric 1 state disable active config ospf router_id 0.0.0.0 disable ospf
Мне соль проблемы видится оччень просто: на коммутаторе 26-ой порт работает «с гигабитной скоростью», а карточка на сервере по какой-то причине только «на сотке». Из приведённой вами статистики по 26-ому порту видно, что коммутатор в данный конкретный момент передавал данные в ваш сервер со скоростью 10947 пакетов в секунду. Это примерно соответствует (или несколько превышает) «скорость стамегабитного трафика». Серверная карта (по каким-то причинам) не справляется с этой нагрузкой и просит коммутатор уменьшить скорость потока данных. А делает она это посылом специфических мультикаст-пакетов коммутатору (в этом, собстенно, и заключается механизм действия фишки, называемой flow control). Кстати, эти flow_control-пакеты пролетают мимо ACL, так что «порезать» их не удастся.
ps. А кстати, вы абсолютно уверены в отсутствии проблем с сетевым кабелем между 26 портом коммутатора и сервером?
Мне соль проблемы видится оччень просто: на коммутаторе 26-ой порт работает «с гигабитной скоростью», а карточка на сервере по какой-то причине только «на сотке». Из приведённой вами статистики по 26-ому порту видно, что коммутатор в данный конкретный момент передавал данные в ваш сервер со скоростью 10947 пакетов в секунду. Это примерно соответствует (или несколько превышает) «скорость стамегабитного трафика». Серверная карта (по каким-то причинам) не справляется с этой нагрузкой и просит коммутатор уменьшить скорость потока данных. А делает она это посылом специфических мультикаст-пакетов коммутатору (в этом, собстенно, и заключается механизм действия фишки, называемой flow control). Кстати, эти flow_control-пакеты пролетают мимо ACL, так что «порезать» их не удастся.
ps. А кстати, вы абсолютно уверены в отсутствии проблем с сетевым кабелем между 26 портом коммутатора и сервером?
В поле DA (Destination Address) кадра данного типа должен быть размещен код 01-80-C2-00-00-01, который представляет собой Multicast-адрес станций, которые поддерживают выполнение данной процедуры, или Unicast-адрес конкретного абонента в сети, формирующего избыточный трафик для данной станции.
В поле SA (SOURCE Address) кадра типа «Пауза» помещается MAC–адрес станции, которая инициирует выполнение процедуры управления потоком.
В поле LENGTH/TYPE этого кадра размещается код 8808 зарезервированный IEEE для кадров, которые используются в процедурах управления на уровне MAC. Поле OPCODE содержит признак кадра управления потоком 0001. В последующих двух байтах размещается код, который соответствует размеру предлагаемой паузы, выраженному в битовых интервалах. Единица младшего разряда этого кода соответствует 512 битовым интервалам используемой технологии. Таким образом, размер предлагаемой паузы для технологий Fast Ethernet может иметь значение от 0 до 0.3 секунды. Остальные поля данного кадра зарезервированы для дальнейшего использования или выполняют служебные функции.
Зарегистрирован: Ср фев 01, 2006 10:11 Сообщений: 429 Откуда: Волгоград
В поле DA (Destination Address) кадра данного типа должен быть размещен код 01-80-C2-00-00-01, который представляет собой Multicast-адрес станций, которые поддерживают выполнение данной процедуры, или Unicast-адрес конкретного абонента в сети, формирующего избыточный трафик для данной станции.
В поле SA (SOURCE Address) кадра типа «Пауза» помещается MAC–адрес станции, которая инициирует выполнение процедуры управления потоком.
В поле LENGTH/TYPE этого кадра размещается код 8808 зарезервированный IEEE для кадров, которые используются в процедурах управления на уровне MAC. Поле OPCODE содержит признак кадра управления потоком 0001. В последующих двух байтах размещается код, который соответствует размеру предлагаемой паузы, выраженному в битовых интервалах. Единица младшего разряда этого кода соответствует 512 битовым интервалам используемой технологии. Таким образом, размер предлагаемой паузы для технологий Fast Ethernet может иметь значение от 0 до 0.3 секунды. Остальные поля данного кадра зарезервированы для дальнейшего использования или выполняют служебные функции.
Ни один управляемый свич не показывает такие маки.