tanenbaum_seti_all.pages (525408), страница 171
Текст из файла (страница 171)
Таким образом, уменьшение на и числа посылаемых ТРО!)-модулей дает снижение числа прерываний и накладных расходов в целом в и раз. Данное наблюдение служит аргументом в пользу сбора значительного количества данных перед их отправкой с целью снизить количество прерываний у по- 642 Глава 6. Транспортный уровень лучатсля. Алгоритм Нагля и предложенный Кларком метод избавления от синдрома глупого окна действуют имсппо в этом направлснии. Правило 3.
"минимизируйте количество переключений контекста Переключения контекста (например, из режима ядра в режим пользователя) обладают рядом неприятных свойств, в этом они схолпы с прерываниями. Самое неприятное — потеря содержимого каша. Количество переключений контекста может быть сии>кено при помощи библиотечной процедуры, посылающей данные во внутренний буфер до тех пор, пока их не наберется лостаточное количество.
Аналогично, на получающей стороне небольшие ТР>э'г>-модули следует собирать вместе и передавать пользователю за один раз, минимизируя количество переключений контекста. В лучшем случае прибывший пакет вызывает одно переключспие контекста из текущего пользовательского процесса в режим ядра, а затем еще одно переключение контекста при передаче управления принимающему процессу и предоставлении ему прибывших данных. К сожалению, во многих опсрациоппых системах происходит еше одно переключение контекста. Например, если сстевой менеджер работает в виде отдельного процесса в пространстве пользователя, поступление пакета вызывает передачу управления от процесса пользователя ядру, затем от ядра сетевому менеджеру, затем снова ядру и, наконец, от ядра получающему процессу.
Эта последовательность переключений контекста показана на рис. 6.36. Вес псрсключсния контекста при получении ка>клого пакета сильно расходуют время центрального процессора и существенно спи>кают производительность сети. Процесс пользгеателя, работающий во время прихода пакета Получающий процесс Сетевой менеджер Пространство ? пользователя Пространство ядра рис. 6.36.
Четыре переключения контекста для обработки одного пакета в сети, в которой сетевой менеджер находится в пространстве пользователя Правило 4: минимизируйте число операций копирования Еще больше времени процессора отнимается излишним копированием пакета. Часто полученный пакет копируется три или четыре раза, прежде чем содержащийся в нем ТРОВ-модуль доставляется по назначению. Сначала пакет принимается сетевым интерфейсом в специальный аппаратный буфер, расположенный Вопросы производитвпьности 64З з сетевой карте. Из аппаратного буфера пакет копируется в системный буфер дра, откуда он копируется в буфер се~свого уровня, а затем — в буфер транспортного уровня и, наконец, доставляется получающему приложению.
' Грамотно разработанные операционные системы копируют по одному машинному слову за такт процессора, цо передки случаи, когда копирование одного слова требует пять инструкций процессора (считывание, запись, увеличение на единицу индексного регистра, проверка на конец данных и условный переход иа начало цикла). Если на олно копирование 32-битного слова требуется пять инструкций процессора, то прн трех операциях копирования каждого пакета па каждый скопированный байт приходится 15/4, или почти 4 команды. На машине с производительностью в 500 млн инструкций в секунду (500 М1РБ) каждая команда выполняется за 2 нс, следовательно, копирование каждого байта будет производиться процессором в течение 8 цс (около 1 цс на бит). Значит, максимальная скорость ограничивается 1 Гбит/с.
С учетом накладных расходов на обработку заголовка и переключения контекстов, возможно, удастся достичь скорости в 500 Мбит/с, а ведь мы еще не учли обработку самих данных. Очевидно, что о поддержке 10-гигабнтной линни не может быть и речи. В действительности поддержка линии со скоростью в 500 Мбит/с также может оказаться абсолютно невозможной.
В приведенных расчетах мы предполагали, что машина с произволитсльностью 500 М1РЯ может выполнить 500 млн любых инструкций в секунду. На самом деле, машина может работать с такой скоростью, только если она не обращается к памяти. Операции с памятью часто оказываются в дссятки раз л1едленцсе, чем операции с использованием только внутренних регистров (па выполнение инструкции расходуегся около 20 нс).
Если 20 % инструкций связано с обращением к памяти (то есть имеются потери кэшируемых данных) — а это вполне вероятная цифра при обработке входящих пакетов, — среднее время выполнения инструкции будет равно 5,6 нс (0,8 ° 2+ 0,2 20). Предполагая, что па обработку байта требуются 4 инструкции, нам понадобится 22,4 нс/байт (или около 2,8 пс/бит), что в результате дает суммарную скорость около 357 Мбит/с. Допустим, половина этой производительности уйдет на обработку заголовков, тогда остается 178 Мбит/с. Обратите внимание на то, что аппаратныс улучшения здесь не помогут. Проблема состоит в слишком большом числе операций копирования, выполняемых операционной системой.
Правило б: можно купить более высокую пропускную способность, но не низкую задержку Следу1ощие три правила относятся не к протоколам, а к линиям связи, Первое правило утверждает, что если вам нужна более высокая пропускная способность, вы можете просто купить ее. Если проложить второй оптоволоконный кабель параллельно первому, пропускная способность удвоится, но время задержки от этого меньше не станет.
Чтобы снизить задержку, слсдует улучшить программное обеспечение протоколов, операционную систему или сетевой интерфейс. И даже это не поможет, если загвоздка состоит во времени передачи по линии. Е44 Глава 6. Транспортный уровень Правило 6: лучше избегать перегрузки, чем бороться с уже возникшей перегрузкой Старая пословица, глашпцая, что профилактика лучше лечения, справедлива и в деле борьбы с перегрузками в сетях.
Когда в сети образуется затор, пакеты теряются, пропускная способность растрачивается впусту>о, увеличиваются задержки и т. п. Процесс восстановления после перегрузки требует времени и терпения. Гораздо более эффективной стратегией является предотвращение перегрузки, напоминающее прививку от болезни — это нссколько неприятно, зато избавляет от возможных больших неприятностей. Правило 7: избегайте тайм-аутов Таймеры необходимы в сетях, но их следует применять умеренно, и следует минимизировать количество тайм-аутов. Когда срабатывает таймер, обычно повторяется какое-либо действие.
Если повтор етого действия необхолнм, его следует повторить, однако повторение действия без особой необходимости является расточительным. Чтобы избегать излишней работы, следует устанавливать период ожидания с небольшим запасом. Таймер, срабатывающий слишком поздно, несколько увеличивает задержку в Гх<аловероятном) случас потери ТРР1)-модуля, Преждевременно срабатывающий таймер растрачивает попусту время пропсссора, пропускную способность и напрасно увеличивает нагрузку на, возмож><о, десятки маршрутизаторов.
Быстрая обработка ТР00-модулей Мораль привсденной истории состоит в том, что основным препятствием на пути ускорения сетей является программное обеспечение протоколов. В данном разделе мы рассмотрим некоторые способы ускорения этих программ. Дополнительные сведения по этой теме см. в ГС)аг)< и др., 1989; О>азе и др., 2001). Накладные расходы по обработке ТРР11-модулей< состоят из двух компонентов: затрат по обработкс заголовка и затрат по обработке каждого байта. Следует вести наступление сразу на обоих направлениях. Ключ к быстрой об>работке ТРР<)-модулей лежит в выделении нормального случая Годпостороцней передачи данных) и отдельной обработке этого случая.
Хотя для перехода в состояние ЕЗТАВЕБНЕР требуется передача последовательности специальных ТРР1)-модулей, цо как только это состояние достигнуто, обработка ТРРП-ь<одулсй нс вы зывает затруднений, пока олна из сторон пе начнет закрывать соединение.
Начнем с рассмотрения посылающей стороны, находящейся в состоянии ЕЗТАВЕ!5ПЕР, когда лолжны отправляться данные. Для простоты мы предположим, что транспортная сущность расположена в ядре, хотя тс же самые идеи применимы и в случае, когда она представляет собой процесс, находящийся в пространстве пользователя, или набор библиотечных процедур в посылающем процессе. На рис. 6.37 отправляющий процесс эмулирует прерывание, выполняя примитив %сКР, и передает управление ядру. Прежде всего, транспортная сущ- Вопросы производительности 646 ность проверяет, находится ли она в нормальном состоянии, то есть таком, когда установлено состояние Е5ТАВИ3НЕР, ни одна сторона пе пытается закрыть соединение, посылается стандартный полный ТРЕН)-модуль и у получателя достаточный размер окна.
Если все эти условия выполнены, то никаких дополнительных проверок не требуется, и алгоритм транспортной сущности может выбрать быстрый путь. В большинстве случаев именно так и происходит. Сеть Рис. 6.37. Быстрый путь от отправителя до получателя показан кгирной линией. Шаги обработки вдоль этого пути показаны затененными прямоугольниками В нормальной ситуации заголовки соседних ТРО()-модулей почти одинаковы.
Чтобы использовать этот факт, транспортная сущность сохраняет в своем буфере прототип заголовка. В начале быстрого пути он как можно быстрее пословно копируется в буфер нового заголовка. Затем поверх персзаписываются все отличающиеся поля. ь1асто эти поля легко выводятся из переменных состояния — например, следующий порядковый номер ТРР()-модуля. Затем указатель на полный ТР1)1)-модуль и указатель на данные пользователя передаются сетевому уровню.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
