Содержание к диссертации
Введение
1. Анализ концепции программно-конфигурируемых сетей 14
1.1 Архитектура систем коммутации пакетов. Плоскости управления и данных в системах коммутации пакетов 14
1.2 Работы по стандартизации архитектуры программно-конфигурируемых сетей 21
1.2.1 ONF TR-502 21
1.2.2 ITU Y. 3300 23
1.2.3 IRTF RFC 7426 26
1.2.4 Области дальнейшей стандартизации ПКС и перспективы исследований 29
1.3 Сетевые операционные системы программно-конфигурируемых сетей 32
1.3.1 Архитектура сетевой операционной системы OpenDaylight 33
1.3.2 OpenDaylight как распределенная сетевая операционная система 42
1.3.3 Коммерческие СОС на базе OpenDaylight 49
1.4 Выводы и результаты 54
2. Анализ многоядерных аппаратных платформ ПКС контроллеров 55
2.1 Реализация параллелизма в современных центральных процессорах 55
2.2 Аппаратные платформы на базе процессоров Intel Xeon E3 и Xeon E5 58
2.3 Метрики параллельных вычислений 67
2.4 Закон Амдала 69
2.4.1 Модель ускорения многоядерных ЦП на основе закона Амдала для многоядерных систем 70
2.4.2 Модель ускорения многоядерных ЦП с поддержкой Hyperhreading 73
2.5 Выводы и результаты 74
3. Разработка модели задержки обработки служебного трафика в программно-конфигурируемых сетях на основе протокола OpenFlow 76
3.1 Протокол взаимодействия контроллера и коммутаторов программно конфигурируемой сети OpenFlow 76
3.2 OpenFlow-коммутатор 85
3.3 Классификация задержек служебного трафика протокола ARP в программно-конфигурируемых сетях 89
3.4 Среда моделирования Mininet 95
3.5 Экспериментальное установление алгоритма обработки ARP-запросов 96
3.6 Экспериментальное выявление зависимости задержки передачи служебного трафика от задержки контроллера 99
3.7 Выводы и результаты 102
4. Исследование масштабирования задержки ПКС контроллера на аппаратных платформах с многоядерными центральными процессорами 103
4.1 Разработка методики проведения тестирования 103
4.2 Анализ программного обеспечения для тестирования ПКС-контроллера 105
4.3 Экспериментальный стенд и методология исследования 107
4.4 Экспериментальное сравнение масштабирования задержки ПКС контроллера на аппаратных платформах с ЦП Xeon E3 и Xeon E5 111
4.5 Экспериментальная апробация способа применения модели ускорения многоядерных ЦП для оценки уровня задержки обработки служебного трафика при масштабировании размера сети 116
4.6 Выводы и результаты 123
Заключение 126
Термины и аббревиатуры 128
Список использованной литературы 131
- Архитектура систем коммутации пакетов. Плоскости управления и данных в системах коммутации пакетов
- Аппаратные платформы на базе процессоров Intel Xeon E3 и Xeon E5
- Классификация задержек служебного трафика протокола ARP в программно-конфигурируемых сетях
- Экспериментальная апробация способа применения модели ускорения многоядерных ЦП для оценки уровня задержки обработки служебного трафика при масштабировании размера сети
Архитектура систем коммутации пакетов. Плоскости управления и данных в системах коммутации пакетов
Перед анализом концепции ПКС необходимо рассмотреть основные принципы внутреннего устройства или архитектуры существующих систем коммутации, осуществляющих прием, обработку и передачу сетевых пакетов. Данные операции выполняются коммутаторами и маршрутизаторами, реализующими при этом функциональность канального и сетевого уровней модели OSI [9] соответственно.
Рассмотрим общий случай обработки фрагмента данных или PDU на сетевом коммутационном узле. Весь путь PDU делится на входной тракт и выходной тракт. Первым делом после поступления PDU на входной тракт узла осуществляется отделение заголовка, определяемого протоколом, от полезной нагрузки или декапсуляция. Полезная нагрузка (PDU без заголовка) находится в буфере в ожидании завершения анализа заголовка, осуществляемого с целью определения дальнейшего пути PDU (или вообще его уничтожения, например, в случае, если размер пакета отличается от определенного протоколом). После завершения анализа, заголовок превращается в метаданные (или временный заголовок) и присоединяется к полезной нагрузке, после чего подаётся на входную очередь. Входная очередь необходима для избегания перегрузки выходного тракта. PDU ждёт разрешение на продвижение в выходную очередь. В том случае, если выходных трактов несколько, необходима коммутационная фабрика, задачей которой является передача PDU на требуемый выходной тракт. Выходной тракт так же имеет выходную очередь, в которой PDU ожидает выходной обработки (например, применения политик QoS) и формирования заголовков. Последним этапом осуществляется присоединение заголовков к нагрузке или инкапсуляция, после чего PDU готов к передаче.
Из рассмотренной процедуры обработки PDU чётко видно разделение задач коммутационного узла на два различных класса:
анализ заголовков PDU с целью определения его дальнейшего пути;
физическое продвижение PDU в соответствии с результатами анализа его заголовка.
В связи с этим в архитектуре систем коммутации принято выделять [59, 95, 32, 56, 63] две плоскости, реализующих различный функционал сетевого коммутационного узла: плоскость управления (control plane) и плоскость данных (data plane). Плоскость управления реализует логику работы сетевого устройства, определяя с помощью различных служебных протоколов (например, ARP, STP, OSPF, PJP и др.) правила для дальнейшего продвижения пакета данных. Для решения этой задачи могут использоваться достаточно сложные алгоритмы, такие как алгоритм Дейкстры [70]. Далее определенные с помощью специальных протоколов правила пересылки заносятся в таблицы. Задача плоскости данных заключается в передаче полезного трафика через сетевое устройство в соответствии с установленными правилами. Исходя из особенностей решаемых каждой плоскостью задач, производители систем коммутации достаточно давно [63] осознали, что разделение данных плоскостей и реализация их на различных аппаратных компонентах позволит повысить производительность.
Рассмотрим реализацию функционала плоскостей управления и данных на примере коммутатора. Коммутатор - это сетевое устройство, выполняющее Рисунок 3. Плоскости управления и данных в архитектуре коммутатора фильтрацию и пересылку кадров данных на основе полей, содержащих адреса канального уровня. Как известно [33, 49, 34], основными показателями производительности коммутаторов наряду с пропускной способностью и задержкой передачи кадра являются скорость фильтрации и скорость продвижения кадров. Для того, чтобы коммутатор мог реализовывать перечисленные операции на скорости порта (wire-speed), в устройствах данного типа используются отдельные интегральные схемы специального назначения ASIC (англ. application-specific integrated circuit). ASIC имеет заранее предопределённый набор функций, которые выполняются аппаратно. Алгоритм работы зашит в неё на этапе производства и не может быть изменён в дальнейшем. ASIC выполняет однотипные рутинные операции, такие как преобразование поступающих на физический порт электрических импульсов в последовательность бит, подсчёт количества принятых и отправленных кадров. Применение ASIC позволяет достигать достаточно высоких показателей производительности коммутаторов. Коммутатор может иметь в своем составе как одну, так и несколько микросхем ASIC, например, работу каждых 12 портов контролирует собственная микросхема ASIC. Программирование логики работы ASIC выполняет плоскость управления, функционирующая на базе центрального процессора общего назначения. Такая архитектура схематично изображена на рисунке 3. Примерами коммутаторов, имеющих подобную архитектуру, могут быть Cisco Catalyst 2960/3650/3850 [32].
Стоит отметить, что если коммутатор обладает функционалом третьего (сетевого) уровня OSI, т.е. способен маршрутизировать трафик между подсетями, то его плоскость управления способна реализовывать более широкий функционал, чем у коммутатора канального уровня.
В случае объединения нескольких физических коммутаторов в логический стек фактически получается ситуация, при которой плоскость управления главного коммутатора в стеке управляет несколькими плоскостями данных ведомых коммутаторов. Команды плоскости управления при этом пересылаются на ведомые коммутаторы через стековый канал связи, как показано на рисунке 4, после чего плоскость данных каждого коммутатора в стеке способна выполнять принятые инструкции и осуществлять пересылку кадров данных. Создание стека коммутаторов позволяет несколько упростить администрирование сетевого оборудования и повысить отказоустойчивость сети.
Рисунок 4. Плоскости управления и данных в стеке коммутаторов Маршрутизатор также обладает функционалом и плоскости управления, и плоскости данных. Маршрутизатором называют сетевое устройство, функционирующее на третьем (сетевом) уровне OSI, предназначенное для объединения сетей и реализующее различные дополнительные сервисы, такие как трансляцию адресов NAT, списки контроля доступа ACL, обнаружение вторжений IDS. Отличительной особенностью маршрутизатора, показанной на рисунке 5, является тот факт, что в нем функционал как плоскости управления, так и плоскости данных выполняется на базе процессоров общего назначения (при этом прочие ресурсы системы, такие как память, также являются разделяемыми). В результате маршрутизатор, по сравнению с коммутатором, является более гибким, функциональным и интеллектуальным устройством, но обладающим меньшей производительностью [35]. Примерами устройств с такой архитектурой являются маршрутизаторы серий Cisco 800, 1900, 2900.
Современные маршрутизаторы, такие как серия Cisco ISR 4400 [61], для увеличения производительности снабжаются многоядерными процессорами, при этом плоскости управления и данных могут выполняться на различных процессорных ядрах. При разработке высокопроизводительных маршрутизаторов, в тех случаях, когда возможностей многоядерных процессоров общего назначения недостаточно, производители прибегают к заимствованию элементов архитектуры коммутаторов, а именно специализированных микросхем [59]. Однако в данном случае речь идет не об использовании ASIC, обеспечивающих высокую производительность, но слабую функциональность, а о применении особого класса микросхем – сетевых процессоров (англ. Network Processor Unit - NPU). Одна из последних разработок компании Cisco в этой области способна обеспечить пропускную способность до 400 Гбит/с в полнодуплексном режиме [62].
Аппаратные платформы на базе процессоров Intel Xeon E3 и Xeon E5
Как отмечают аналитики, современный рынок серверных процессоров на 96% состоит из процессоров с х86-совместимой архитектурой [145], при этом единогласным лидером в этом сегменте является компания Intel [7, 18]. В выводах первой главы диссертационной работы отмечалось, что в соответствии с рекомендациями производителей, аппаратные платформы для коммерческих версий контроллера OpenDaylight должны быть снабжены многоядерными процессорами Intel Xeon с числом ядер от 4 и выше. Производимые компанией Intel серверные процессоры по критерию масштабируемости и области применения можно разделить на следующие категории:
однопроцессорные системы, включающие линейки Xeon ЕЗ 1200, Е5 1600. Область применения - сервера начального уровня для малого и среднего бизнеса, рабочие станции [86];
двухпроцессорные системы, включающие линейки Xeon Е5 2600 и Xeon Е7 2800. Сервера на базе таких ЦП предназначены для широкого класса задач, обладают расширенными возможностями виртуализации, используются в центрах обработки данных и для построения программно-определяемой инфраструктуры SDI [88];
четырехпроцессорные системы Xeon Е5 4600, Xeon Е7 4800 также применяются в центрах обработки данных, но для задач, требующих больший уровень производительности и виртуализации или с трудно прогнозируемой нагрузкой [88];
восьмипроцессорные системы Xeon E7 8800 обладают расширенными возможностями в плане обеспечения надежности и высокого уровня производительности и предназначены для использования в транзакционных системах реального времени OLTP, системах планирования ресурсов предприятия ERP и прочих системах анализа Big Data [89];
однокристальные системы Atom C2000 предназначенны для встраиваемых систем и микросерверов [84], а Xeon D1500 - для сетевых хранилищ, коммутаторов и маршрутизаторов, устройств индустриального Интернета вещей [21]. Отдельно отмечается преимущество линейки Xeon D1500 над Atom C2000 в задачах, связанных с обработкой сетевых пакетов, в том числе при использовании виртуализации сетевых функций (NFV-решений) [21].
сопроцессоры Xeon Phi, поставляемые в виде отдельной платы расширения с интерфейсом PCI Express x 16, применяемые для ускорения различного рода научных вычислений, таких как обучение нейросетей и приложения с высокой степенью параллелизации. [141]
Таким образом, исходя из рекомендаций производителей контроллеров и позиционирования семейств серверных процессоров Intel, рассмотрим далее спецификации серверных аппаратных платформ на базе процессоров Intel Xeon E3 и Xeon E5.
В период выполнения автором экспериментальных исследований, актуальные x86-серверные платформы были основаны на процессорах Intel с микроархитектурой Haswell-EP. Haswell – это кодовое наименование микроархитектуры процессоров Intel Core четвертого поколения, Haswell-EP же представляет собой вариацию этой микроархитектуры для серверного сегмента. Микроархитектура Haswell достаточно подробно была проанализирована в работах D. Kanter [90] и W. J. Carranza [57], а также в официальной документации Intel [69]. Обобщённо конвейер исполнения инструкции для процессоров микроархитектуры Haswell представлены на рисунке 20.
В процессорах Haswell можно выделить подсистему упорядоченной предварительной обработки (In-Order Front End), отвечающую за выборку и декодирование инструкций в предусмотренном программой порядке, подсистему исполнения с изменением последовательности (Out-of-Order), задачей которой является исполнение микроопераций в оптимальном порядке, и подсистему упорядоченного завершения (In-Order Retirement), которая снова переупорядочивает результаты исполнения в изначальном предусмотренном программой порядке и подсистему кэш-памяти [57, 90, 142]. Исполнение инструкции начинается со считывания и выборки её из кэша, откуда она, проходя через буфер выборки инструкций (Fetch Buffer) и буфер инструкций (Intsructions Queue), поступают для декодирования на блок декодера (-ops Queue), преобразующий x86-инструкции в простейшие микрооперации. Инструкции может соответствовать одна микрооперация (в этом случае декодирование проводит декодер простых инструкций или simple decoder) или несколько микроопераций (от 2 до 4 штук, декодирование осуществляется декодером сложных инструкций или complex decoder). Стоит отметить наличие выделенного кэша для микроопераций [57, 69, 90, 142].
После декодирования инструкций микрооперации и данные помещаются в т.н. станцию-резервуар (Reservation Station) - специальный буфер-диспетчер, определяющий оптимальный порядок исполнения. Микрооперации могут быть выполнены во внеочередном порядке, если в требуемый момент времени доступны необходимые им данные. Результаты исполнения хранятся в буфере переупорядочивания микроопераций (Reorder Buffer) до тех пор, пока программа не определит их готовность к удалению из конвейера и не будет осуществлена т.н. процедура отставки (retire stage), в ходе которой осуществляется сохранение результатов в кэш-память данных. Однако если результат исполнения необходим для выполнения последующих микроопераций – то он помещается в станцию-резервуар. Когда все стадии конвейера пройдены (14-19 для Haswell), на вход конвейера подается следующая инструкция. Порядок подачи инструкций определяется при непосредственном участии блока предсказания ветвлений (Branch Predictors) [57, 69, 90, 142].
Стоит отметить, что при реализации SMT, которая в случае с процессорами Intel получила наименование Hyperhreading (далее HT), буферы подсистем упорядоченной предварительной обработки и упорядоченного завершения являются теми ресурсами, которые требуется физически продублировать. При этом доступ к подсистеме исполнения с изменением последовательности, кэшу, блоку предсказания ветвлений осуществляется в разделяемом режиме. Буфер переупорядочивания (ROB) при активации HT также осуществляет координирование записей различных логически процессоров. Важно обратить внимание, что все рассмотренные выше блоки процессора составляют ядро.
По оценкам производителя, реализация технологии HT ведет к увеличению площади кристалла всего лишь на 5% [130], хотя достигаемое ускорение при этом может доставлять до 30%. Однако эффект от использования HT не всегда положительный. В частности, для типа нагрузок, характерного для баз данных, известны проблемы снижения производительности при использовании HT в таких СУБД, как Microsoft SQL Server [137], а при использовании отечественной системы 1С: Предприятие 8 не рекомендуется активировать HT при превышении показателя загрузки процессора порога 80% [31]. В работах [60, 72, 75] исследуется поведение Java-приложений на многоядерных процессорах с HT. Авторами отмечаются узкие места производительности программ и предлагаются способы оптимизации виртуальной машины JVM. Однако при использовании виртуализованных сред HT дает ощутимый прирост производительности [30, 138]. В задачах классификации сетевых пакетов использование многоядерных процессоров дает весьма серьезный прирост ускорения, что показано в исследовании [148] на примере процессора Tilera-Gx36, снабженного 36 ядрами, однако не являющимся x86-совместимым. Кроме факторов производительности при использовании многоядерных процессоров с HT, необходимо учитывать модель лицензирования используемого программного обеспечения, поскольку некоторые компании предлагают расчет стоимости лицензии исходя из числа физических и логических процессоров в системе. Такую политику ведет Microsoft при лицензировании операционных систем Windows Server или отечественный производитель средств криптографической защиты информации «Крипто-ПРО» (продукт КриптоПРО JCP 2.0).
В распоряжении автора находились серверные платформы, снабженные процессорами Intel Xeon E3-1241 v3 и Xeon E5-2670 v3. Сравнение технических характеристик приведено в таблице 5, составленной на основе данных ресурсов [67] и [119].
Классификация задержек служебного трафика протокола ARP в программно-конфигурируемых сетях
В традиционных локальных вычислительных сетях в процессе передачи пакетов данных от одного узла к другому важную роль играет процесс определения адресов, осуществляемый в соответствии с протоколом определения адреса ARP, описанным в RFC 826 [129]. Однако механизм для обработки ARP-запросов и ARP-ответов в программно-конфигурируемых сетях отличается от данного механизма в традиционных сетях IP. В ПКС при отсутствии на коммутаторах записей о направлении ARP-пакетов механизм определения адресов должен быть выполнен, в первую очередь, на контроллере — программно-аппаратной платформе, реализующей интеллектуальные функции сети [42].
В работе Internet Draft «Address Resolution Delay in SDN» [118], являющейся рабочим документом Инженерного совета Интернета (IETF) и опубликованной в октябре 2014 года, определяются две метрики, которые можно применить для характеристики задержки механизма определения адреса:
1) Address Resolution Delay No Forwarding Flow Registrations ( ARDNFFR) — задержка определения адреса без установки потока для передачи пакета на коммутаторе;
2) Address Resolution Delay Forwarding Flow Registrations ( ARDFFR) — задержка определения адреса с установкой потока для передачи пакета на коммутаторе.
Дадим определения этим величинам, основываясь на топологии сети, представленной на рисунке 30, где С — контроллер; S — коммутатор; H0 и H1 — узлы в сети.
Определение 1: Рассмотрим задержку ARDNFFR. Пусть узел Нх отправляет первый бит пакета ARP-запроса узлу Н0 в момент времени TH, тогда Нх принимает первый бит ARP-ответа от Н0 в момент времени TH + drNF при отсутствии требуемой ARP-записи в таблице потоков (кэше) коммутатора. Получаем, что задержка ARDNFFR есть величина drNF. Единицами измерения данного параметра являются миллисекунды. За эталонное значение принимается время первого прохождения пакета по сети при отсутствии установленных потоков на коммутаторах для ARP-пакетов [40, 74, 118].
С учетом определения 1 и топологии сети, представленной на рисунке, предложим формулу для оценки данной метрики задержки: dzNF=L + CNF+SNF, (12) где L — задержка в каналах связи; CNF — задержка обработки на контроллере; SNF — задержка обработки на коммутаторе без установленных правил.
Очевидно, что с ростом размера сети и усложнением топологии значение задержки определения адреса без установки потока для передачи пакета на коммутаторе drNF будет расти.
Определение 2: Рассмотрим задержку ARDFFR. Пусть узел Нх отправляет первый бит пакета ARP-запроса узлу Н0 в момент времени TH, тогда Нх принимает первый бит ARP-ответа от Н0 в момент времени TH + dr при наличии требуемой ARP-записи в таблице потоков (кэше) коммутатора. Получаем, что задержка ARDFFR есть величина dr. Единицами измерения данного параметра являются миллисекунды. За эталонное значение принимается время первого прохождения пакета по сети при наличии установленных потоков на коммутаторах для ARP-пакетов [40, 74, 118].
С учетом определения 2 и топологии сети, представленной на рисунке 30, предложим формулу для оценки данной метрики задержки: dr = L + S, (13) где L — задержка в каналах связи; S — задержка обработки на коммутаторе с установленными правилами.
Очевидно, что с ростом размера сети и усложнением топологии значение з а Исходя из определений 1 и 2, а также формул (12), (13) можно сделать дывод, что задержка механизма определения адресов в ПКС будет превышать езначения задержки в аналогичной традиционной сети с коммутацией пакетов ртолько в том случае, когда на коммутаторе отсутствует запись в таблице жпотоков. к Применение dr вместо drNF обусловлено следующими факторами: и - определение адреса с установленными потоками на коммутаторах является основной формой механизма определения адреса в ПКС; п - когда время жизни ARP-таблиц на коммутаторе заканчивается, узел должен вновь инициировать механизм определения адреса, а значит и установку потока на коммутаторах. д Высокое значение параметров dr и drNP может свидетельствовать о проблемах на одном или более сегментах сети, а значит, данный параметр может быть использован для диагностики программно-конфигурируемой сети е целом [40].
Рассмотрим возможность использования двух перечисленных параметров для оценки программно-конфигурируемых сетей. я Введем следующие обозначения: Н0,НХ — сетевые узлы;
В [118] выдвинуто предположение, что поток ARP-пакетов можно рассматривать в качестве Пуассоновского. Имея значения T0,Tf и А,, можно описать псевдослучайный Пуассоновский процесс на временном интервале I T 0 ,T f I с интенсивностью поступления пакетов X. В каждый момент времени Tt значением задержки для первого процесса механизма определения адреса является параметр dtNF, а для последующих процессов механизма определения адреса — значения параметра dr Далее можно получить значение параметров drNF и dr на промежутке от Т0 до Tf c интервалом Ti.
Согласно [16], поток событий — последовательность событий, происходящих одно за другим в случайные моменты времени.
Пуассоновский поток — это поток, обладающий двумя свойствами — ординарностью и отсутствием последействия.
Таким образом, поток можно считать ординарным, если за малый промежуток времени может произойти не более одного события (или ни одного события, вероятность чего обозначим P0(t,At).
Отсутствие последействия — свойство, когда для двух неперекрывающихся интервалов времени число событий, попадающих в один интервал, не зависит от того, сколько событий попало в другой [16].
Воспользуемся формулой распределения Пуассона для оценки вероятности возникновения -запросов от коммутатору к контроллеру на установление правила на временном интервале [ о»7}] = mTr
Из полученных результатов исследования можно сделать ряд выводов.
1. Если величина Г. стремится к бесконечности, то параметр dz будет преобладать над drNF. В противном случае может практически не быть dz .
2. Если величина стремится к бесконечности, то параметр drNF ничтожно мал на фоне dr поскольку только одно из всего множества событий на интервале убудет соответствовать режиму функционирования сети без установленных потоков на коммутаторах. В противном случае, если X слишком мала, вероятность возникновения ARP-запросов на интервале
Полученные формулы оценки задержек в программно-конфигурируемых сетях имеют практическую ценность, поскольку позволяют сетевому инженеру получить конкретные значения времени обработки пакетов на каждом из устройств сети. В случае если величина задержки на контроллере весьма велика, системный администратор может сделать вывод о необходимости оптимизации работы ПКС-контроллера либо путем перенастройки установленных правил, либо путем модернизации аппаратной части.
Экспериментальная апробация способа применения модели ускорения многоядерных ЦП для оценки уровня задержки обработки служебного трафика при масштабировании размера сети
В ходе эксперимента была использована аппаратная платформа с ЦП Xeon E5 как показавшая больший выигрыш от параллелизации. С помощью Cbench смоделирована сеть из 2 коммутаторов (где последовательно принимает значения 0,1,2,3,4,5,6,7), память каждого коммутатора содержала 105 МАС-адресов, проведено 10 серий замеров по 10 тестов в каждой серии при длительности одного теста 10 секунд, пауза между тестами 30 секунд. Результатом серии замеров является среднее значение задержки, получаемое при постоянном числе ядер ЦП, количество же управляемых OpenFlow-коммутаторов последовательно изменялось программой автоматизации тестирования. После этого через BIOS изменялось число активных ядер процессора, осуществлялось включение/отключение HT и цикл замера повторялся. Экспериментально полученные значения задержки представлены в табличном виде в приложении Г. Для удобства представления информации в графическом виде на рисунках 44-51 показаны результаты для 1, 8, 32 и 128 коммутаторов.
При малом числе коммутаторов, согласно рисунку 44, увеличение числа процессорных ядер приводит к росту задержки ПКС-контроллера, активация HT только усугубляет положение.
Положительных эффект наблюдается в случае управления контроллером сегментов сети из 16 OpenFlow-коммутаторов, что показано на рисунке 45: увеличение числа ядер с 1 до 12 способствует снижению задержки с 96 мкс до 23 мкс. Положительный эффект усиливается с дальнейшим ростом размера сегмента управляемо сети: при 128 коммутаторах задержка падает с 337 мкс при 1 активном процессорном ядре до 71 мкс при 12 ядрах, активация HT позволяет при 12 активных ядрах дополнительно снизить задержку до 56 мкс.
Увеличение числа OpenFlow-коммутаторов позволяет достичь больших значений ускорения при увеличении числа процессорных ядер, доступных ПКС-контроллеру. Однако достигнутое в максимальной конфигурации процессора Xeon E5 ускорение, составившее 4,7 раз при 128 коммутаторах, меньше, чем получаемое в идеальном случае по линейному закону значение 12. Активация HT в этом случае позволяет достичь ускорения в 6 раз при использовании 12 ядер, что показано на рисунке 47.
Дальнейшему росту ускорения препятствуют последовательные не распараллеливаемые операции, при 128 коммутаторах и 12 активных ядрах ЦП доля которых составляет порядка 0,13 от общего числа совершаемых операций, как видно из рисунка 48. Начиная с 6 ядер доля линейных операций меняется достаточно слабо, в диапазоне от 0,17 до 0,13 при 128 коммутаторах и от 0,2 до 0,14 при 32 коммутаторах. На графике это выглядит как колебания «хвоста» функции в небольших пределах. В этом случае большего значения ускорения при фиксированном числе ядер можно достичь за счет увеличения вычислительной сложности решаемой задачи, т.е. увеличения числа коммутаторов в управляемом ПКС-контроллером сегменте сети.
При малом числе коммутаторов в управляемом сегменте сети доля последовательных операций имеет вид, показанный на рисунке 49. Рост данного параметра при 1 коммутаторе обусловлен низкой сложностью решаемой задачи, в следствие которой растут издержки параллелизации. В такой ситуации также рационально увеличивать вычислительную сложность решаемой задачи.
Рассчитанное из экспериментальных данных значение эффективности, представленное на рисунках 50 и 51, говорит о том, что увеличение размера сети наряду с использованием технологии HT способствует росту эффективности применения многоядерных процессоров. Как показывает рисунок 51, с увеличением числа физических ядер процессора наблюдается снижение эффективности. Hyperhreading позволяет увеличить эффективность использования многоядерных процессоров при постоянном числе физических ядер процессора. При размере сети в 128 коммутаторов и 12 ядрах ЦП эффективность составляет 0,395, активация HT позволяет повысить это значение до 0,501, таким образом наблюдаемый прирост эффективности составляет 1,26 раз. Среднее значение эффективности при 128 коммутаторах, учитывая все возможные конфигурации ядер ЦП с Hyperhreading, составляет 0,76, а в конфигурации без HT – 0,59, и таким образом среднее значение прироста эффективности от активации HT составляет 1,28 раз. Если же ПКС-контроллер управляет сетью из 32 коммутаторов, то при 12 ядрах ЦП активация HT не дает прироста эффективности. Однако среднее значение эффективности при всех возможных конфигурациях физических ядер ЦП ПКС-контроллера и 32 коммутаторах составляет 0,51, активация Hyperhreading повышает это значение до 0,62, средний прирост эффективности составляет 1,22 раза. Таким образом, эффективность использования многоядерных процессоров может быть увеличена путем использования технологии логической многопоточности Hyperhreading при достаточном размере сегмента сети (сложности вычислительной задачи).