Ветеран
Сообщения: 1958
Благодарности: 306
|
Профиль
|
Отправить PM
| Цитировать
Цитата:
|
• DisableTaskOffload. С помощью данного параметра можно задействовать установленный в сетевой карте процессор, чтобы переложить на него обработку всех операций работы с сетевыми пакетами. Поскольку сетевая карта не всегда имеет встроенный процессор (естественно, потому что отдельный процессор повышает стоимость сетевой карты), по умолчанию возможность использования встроенного в сетевую карту процессора не задействуется, а работа с сетевыми пакетами выполняется процессором компьютера. Если вы точно знаете, что ваша сетевая карта имеет такой процессор, тогда для его использования нужно присвоить параметру DisableTaskOffload значение 0.
|
1. Выберите в меню Пуск пункт Выполнить, введите команду regedit и нажмите кнопку ОК.
2. Найдите и выберите следующий подраздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Убедитесь в том, что на правой панели присутствует запись реестра DisableTaskOffload. Если эта запись отсутствует, выполните следующие действия, чтобы добавить ее.
-1. В меню Правка выберите пункт Создать, а затем — Параметр DWORD.
-2. Введите DisableTaskOffload и нажмите клавишу ВВОД.
4. Щелкните DisableTaskOffload.
5. В меню Правка выберите пункт Изменить.
6. Введите 0 в поле Значение и нажмите клавишу ВВОД.
DisableTaskOffload = 0
Аналогично с
Цитата:
|
• SackOpts. Данный параметр позволяет включить механизм SACK, с помощью которого при потере одного из пакетов, отправитель пакетов может передать лишь потерянный пакет, а не все пакеты сообщения, что позволяет ускорить работу сети. Для активизации данного механизма параметру SackOpts нужно присвоить значение 1.
|
SackOpts = 1
Цитата:
...
фактор, влияющий на стратегию отправки TCP, - алгоритм Нейгла. Этот алгоритм впервые предложен в RFC 896 [Nagle 1984]. Он требует, чтобы ни*когда не было более одного неподтвержденного маленького сегмента, то есть сегмента размером менее MSS. Цель алгоритма Нейгла — не дать TCP забить сеть последовательностью мелких сегментов. Вместо этого TCP сохраняет в своих буферах небольшие блоки данных, пока не получит подтверждение на предыдущий маленький сегмент, после чего посылает сразу все накопившиеся данные.
Если приложение записывает данные небольшими порциями, то эффект от алгоритма Нейгла очевиден. Предположим, что есть простаивающее соединение, окна передачи и перегрузки достаточно велики, а выполняются подряд две небольшие операции записи. Данные, записанные вначале, передаются немедленно, поскольку окна это позволяют, а алгоритм Нейгла не препятствует, так как неподтвержденных данных нет (соединение простаивало). Но, когда до TCP доходят данные, получен*ные при второй операции, они не передаются, хотя в окнах передачи и перегрузки есть место. Поскольку уже есть один неподтвержденный маленький сегмент, и алго*ритм Нейгла требует оставить данные в очереди, пока не придет АСК.
Обычно при реализации алгоритма Нейгла не посылают маленький сегмент, если есть неподтвержденные данные. Такая процедура рекомендована RFC 1122. Но реализация в BSD (и некоторые другие) несколько отходит от этого правила и отправляет маленький сегмент, если это последний фрагмент большой одновре*менно записанной части данных, а соединение простаивает. Например, MSS для простаивающего соединения равен 1460 байт, а приложение записывает 1600 байт. При этом TCP пошлет (при условии, что это разрешено окнами передачи и перегрузки) сначала сегмент размером 1460, а сразу вслед за ним, не дожидаясь под*тверждения, сегмент размером 140. При строгой интерпретации алгоритма Ней*гла следовало бы отложить отправку второго сегмента либо до подтверждения первого, либо до того, как приложение запишет достаточно данных для формиро*вания полного сегмента.
Алгоритм Нейгла - это лишь один из двух алгоритмов, позволяющих избе*жать синдрома безумного окна (SWS - silly window syndrome). Смысл этой так*тики в том, чтобы не допустить отправки небольших объемов данных. Синдром SWS и его отрицательное влияние на производительность обсуждаются в RFC 813 [Clark 1982]. Как вы видели, алгоритм Нейгла пытается избежать синдрома SWS со стороны отправителя. Но требуются и усилия со стороны получателя, который не должен декларировать слишком маленькие окна.
Напомним, что окно передачи дает оценку свободного места в буферах хоста на другом конце соединения. Этот хост объявляет о том, сколько в нем имеется места, включая в каждый посылаемый сегмент информацию об обновлении окна. Чтобы избежать SWS, получатель не должен объявлять о небольших изменениях.
Следует пояснить это на примере. Предположим, у получателя есть 14600 сво*бодных байт, a MSS составляет 1460 байт. Допустим также, что приложением на Конце получателя читается за один раз всего по 100 байт. Отправив получателю 10 сегментов, окно передачи закроется. И вы будете вынуждены приостановить отправку данных. Но вот приложение прочитало 100 байт, в буфере приема 100 байт освободилось. Если бы получатель объявил об этих 100 байтах, то вы тут же послали бы ему маленький сегмент, поскольку TCP временно отменяет алгоритм Нейгла, если из-за него длительное время невозможно отправить маленький сегмент. Вы и дальше продолжали бы посылать стобайтные пакеты, так как всякий раз, когда приложение на конце получателя читает очередные 100 байт, получатель объявляет освобождении этих 100 байт, посылая информацию об обновлении окна.
Алгоритм избежания синдрома SWS на получающем конце не позволяет объявлять об обновлении окна, если объем буферной памяти значительно не увеличился. В RFC 1122 «значительно» - это на размер полного сегмента или более чем на половину максимального размера окна. В реализациях, производных от BSD, требуется увеличение на два полных сегмента или на половину максималь*ного размера окна.
Может показаться, что избежание SWS со стороны получателя излишне (поскольку отправителю не разрешено посылать маленькие сегменты), но в действи*тельности это защита от тех стеков TCP/IP, в которых алгоритм Нейгла не реали*зован или отключен приложением (совет 24). RFC 1122 требует от реализаций TCP, удовлетворяющих стандарту, осуществлять избежание SWS на обоих концах.
На основе этой информации теперь можно сформулировать стратегию отправ*ки, принятую в реализациях TCP, производных от BSD. В других реализациях стратегия может быть несколько иной, но основные принципы сохраняются.
При каждом вызове процедуры вывода TCP вычисляет объем данных, кото*рые можно послать. Это минимальное значение количества данных в буфере пере*дачи, размера окон передачи и перегрузки и MSS. Данные отправляются при выполнении хотя бы одного из следующих условий:
* можно послать полный сегмент размером MSS;
* соединение простаивает, и можно опустошить буфер передачи;
* алгоритм Нейгла отключен, и можно опустошить буфер передачи;
* есть срочные данные для отправки;
* есть маленький сегмент, но его отправка уже задержана на достаточно дли тельное время;
Примечание: Если у TCP есть маленький сегмент, который запрещено посылать, то он взводит таймер на то время, которое потребовалось бы для ожидания АСК перед повторной передачей (но в пределах 5-60 с). Иными словами, устанавливается тайм-аут ретрансмиссии (RТО). Если этот таймер, называемый таймером терпения (persist timer), срабатывает, то TCP все-таки посылает сегмент при условии, что это не противоречит ограничениям, которые накладывают окна передачи и перегрузки. Даже если получатель объявляет окно размером нуль байт, TCP все равно попытается послать один байт. Это делается для того, чтобы потерянное обновление окна не привело к тупиковой ситуации.
* окно приема, объявленное хостом на другом конце, открыто не менее чем на*половину;
* необходимо повторно передать сегмент;
* требуется послать АСК на принятые данные;
* нужно объявить об обновлении окна.
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
TcpAckFrequency=2 (DWORD value, 1=disable, 2=default, 2-n=send ACKs if outstanding ACKs before timed interval. Setting not present by default)
Цитата:
|
NetDMA enables support for advanced direct memory access. In essence, it provides the ability to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from handling memory data transfers between network card data buffers and application buffers by using a DMA engine.
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (DWORD, 1 to enable, 0 to disable NetDMA. Value not present by default) |
