Настройка производительности сетевых адаптеровperformance tuning network adapters

Цель

Первоначально TCP был разработан для ненадежных низкоскоростных сетей (таких как ранние модемы с коммутируемым доступом ), но с ростом Интернета с точки зрения магистральных скоростей передачи (с использованием оптических каналов связи , Gigabit Ethernet и 10 Gigabit Ethernet ) и более быстрого и надежного доступа механизмы (такие как DSL и кабельные модемы ) он часто используется в центрах обработки данных и средах настольных ПК со скоростью более 1 Гигабит в секунду. Программные реализации TCP в хост-системах требуют значительных вычислительных мощностей. В начале 2000-х годов полнодуплексная гигабитная TCP-связь могла потреблять более 80% процессора Pentium 4 с тактовой частотой 2,4 ГГц (см. « ), в результате чего приложениям для работы в системе оставалось мало ресурсов обработки или вообще их не было.

TCP — это протокол с установлением соединения, который увеличивает сложность и накладные расходы на обработку. Эти аспекты включают:

  • с использованием «3-стороннего подтверждения» (SYNchronize; SYNchronize-ACKnowledge; ACKnowledge).
  • Подтверждение получения пакетов на дальнем конце, добавление к потоку сообщений между конечными точками и, таким образом, к загрузке протокола.
  • Вычисление контрольной суммы и порядковых номеров — опять же нагрузка на ЦП общего назначения.
  • Расчет скользящего окна для подтверждения пакетов и контроля перегрузки .
  • Прекращение соединения .

Перенос некоторых или всех этих функций на выделенное оборудование, механизм разгрузки TCP, освобождает основной процессор системы для других задач. По состоянию на 2012 год очень немногие потребительские сетевые карты поддерживают TOE.

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

Высвобожденные циклы ЦП

Общепринятое эмпирическое правило состоит в том, что для передачи или приема 1 бит / с TCP / IP требуется 1 герц обработки ЦП . Например, 5 Гбит / с (625 МБ / с) сетевого трафика требует 5 ГГц обработки ЦП. Это означает, что для обработки TCP / IP, связанной с трафиком TCP / IP со скоростью 5 Гбит / с, потребуются 2 полных ядра многоядерного процессора с тактовой частотой 2,5 ГГц . Поскольку Ethernet (10GE в этом примере) является двунаправленным, можно отправлять и получать 10 Гбит / с (для совокупной пропускной способности 20 Гбит / с). При использовании правила 1 Гц / (бит / с) это соответствует восьми ядрам с частотой 2,5 ГГц.

Многие циклы ЦП, используемые для обработки TCP / IP, «освобождаются» за счет разгрузки TCP / IP и могут использоваться ЦП (обычно ЦП сервера ) для выполнения других задач, таких как обработка файловой системы (на файловом сервере). или индексация (на сервере резервного копирования). Другими словами, сервер с разгрузкой TCP / IP может выполнять больше серверной работы, чем сервер без сетевых адаптеров TCP / IP.

Снижение трафика PCI

В дополнение к накладным расходам протокола, которые может решить TOE, он также может решить некоторые архитектурные проблемы, которые влияют на большой процент конечных точек на основе хоста (сервера и ПК). Многие старые узлы конечных точек основаны на шине PCI , которая обеспечивает стандартный интерфейс для добавления определенных периферийных устройств, таких как сетевые интерфейсы к серверам и ПК. PCI неэффективен для передачи небольших пакетов данных из основной памяти по шине PCI на ИС сетевого интерфейса, но его эффективность повышается по мере увеличения размера пакета данных. В рамках протокола TCP создается большое количество небольших пакетов (например, подтверждений), и, поскольку они обычно генерируются на центральном ЦП и передаются по шине PCI и из сетевого физического интерфейса, это влияет на пропускную способность ввода-вывода главного компьютера.

Решение TOE, расположенное на сетевом интерфейсе, расположено на другой стороне шины PCI от хоста ЦП, поэтому оно может решить эту проблему эффективности ввода-вывода, поскольку данные, которые будут отправлены через TCP-соединение, могут быть отправлены на TOE от ЦП через шину PCI с использованием пакетов данных большого размера, при этом ни один из меньших пакетов TCP не должен проходить через шину PCI.

Настраиваем уведомления о перегрузке (ECN’ы) в Windows

Технология ECN в явном виде относится и к IP, а не только к TCP, но все равно про неё стоит тут написать.

Протокол IP изначально не особо любил технологии класса Quality of Service – QOS, поэтому в заголовке IPv4 выделен байт с целью “использовать для целей управления качеством”. Притом этот байт может содержать данные в разных форматах, и то, как его интерпретировать, решает конкретный хост. Используется два возможных формата данного байта – DSCP (он же DiffServ) и IP Precedence. По умолчанию этот байт (называющийся ToS – Type of Service) обрабатывается как IP Precedence и представляет собой копию данных канального уровня (в него копируются три бита от CoS – Class of Service, которые передаются в 802.3 кадре в составе 802.1p компонента заголовка 802.1Q).

Но нас будет интересовать ситуация, когда в заголовке IP-пакета – в поле ToS, разумеется – данные интерпретируются в формате DSCP. В этом случае на номер класса трафика отдаётся 6 бит (что даёт возможность сделать в организации 2^6 = 64 класса трафика и удобно управлять приоритетами), а оставшиеся 2 бита отдаются как раз на сигнализацию о “заторах”.

Говоря проще, если у промежуточного устройства буфер пакетов близок к перегрузке, то оно сигнализирует Вам, отправляя служебный пакет на IP отправителя, что “пакеты скоро будет некуда девать и придётся их выбрасывать, притормози”. Отправляет их, выставляя как раз специфические биты в поле ToS. Соответственно, включая поддержку данной технологии, Вы будете включать и возможность генерации подобных пакетов, и возможность анализа оных.

Простейший пример ситуации, в которой это поможет – на пути Вашего трафика стоит маршрутизатор, который в Вашу сторону смотрит интерфейсом со скоростью 1 Gbit, а дальше – интерфейсом со скоростью 100 Mbit. Если Вы будете отдавать ему трафик с максимально возможной скоростью, то его очередь пакетов, пытающихся “выйти” через интерфейс со скорость 100 Mbit, очень быстро переполнится, и если он не сможет Вам об этом сказать (ну или если Вы не включите со своей стороны возможность услышать эти сообщения от него), то ему придётся просто в определённый момент перестать принимать пакеты, сбрасывая их. А это приведёт к тому, что начнётся потеря данных, которые надо будет восстанавливать – а служебный трафик при восстановлении данных достаточно значителен. Т.е. гораздо проще передать чуть медленнее, чем потерять много пакетов и выяснить это на уровне TCP-подключения, после чего запрашивать их повторно, теряя время и тратя трафик.

Работаем с Checksum offload IPv4/IPv6/UDP/TCP

Данная пачка технологий крайне проста. Эти настройки снимают с CPU задачи проверки целостности полученых данных, которые (задачи, а не данные) являются крайне затратными. То есть, если Вы получили UDP-датаграмму, Вам, по сути, надо проверить CRC у ethernet-кадра, у IP-пакета, и у UDP-датаграммы. Всё это будет сопровождаться последовательным чтением данных из оперативной памяти. Если скорость интерфейса большая и трафика много – ну, Вы понимаете, что эти, казалось бы, простейшие операции, просто будут занимать ощутимое время у достаточно ценного CPU, плюс гонять данные по шине. Поэтому разгрузки чексумм – самые простые и эффективно влияющие на производительность технологии. Чуть подробнее про каждую из них:

IPv4 checksum offload

Сетевой адаптер самостоятельно считает контрольную сумму у принятого IPv4 пакета, и, в случае, если она не сходится, дропит пакет.

Бывает продвинутая версия этой технологии, когда адаптер умеет сам проставлять чексумму отправляемого пакета. Тогда ОС должна знать про поддержку этой технологии, и ставить в поле контрольной суммы нуль, показывая этим, чтобы адаптер выставлял параметр сам. В случае chimney, это делается автоматически. В других – зависит от сетевого адаптера и драйвера.

IPv6 checksum offload

Учитывая, что в заголовке IPv6 нет поля checksum, под данной технологией обычно имеется в виду “считать чексумму у субпротоколов IPv6, например, у ICMPv6”. У IPv4 это тоже подразумевается, если что, только у IPv4 субпротоколов, подпадающих под это, два – ICMP и IGMP.

TCPv4/v6 checksum offload

Реализуется раздельно для приёма и передачи (Tx и Rx), соответственно, считает чексуммы для TCP-сегментов. Есть тонкость – в TCPv6 чексумма считается по иной логике, нежели в UDP.

Общие сведения для всех технологий этого семейства

Помните, что все они, по сути, делятся на 2 части – обработка на адаптере принимаемых данных (легко и не требует взаимодействия с ОС) и обработка адаптером отправляемых данных (труднее и требует уведомления ОС – чтобы ОС сама не считала то, что будет посчитано после). Внимательно изучайте документацию к сетевым адаптерам, возможности их драйверов и возможности ОС.

Ещё есть заблуждение, гласящее примерно следующее “в виртуалках всё это не нужно, ведь это все равно работает на виртуальных сетевухах, значит, считается на CPU!”. Это не так – у хороших сетевых адаптеров с поддержкой VMq этот функционал реализуется раздельно для каждого виртуального комплекта буферов отправки и приёма, и в случае, если виртуальная система “заказывает” этот функционал через драйвер, то он включается на уровне сетевого адаптера.

Как включить IP,UDP,TCP checksum offload в Windows

Включается в свойствах сетевого адаптера. Операционная система с данными технологиями взаимодействует через минипорт, читая настройки и учитывая их в случае формирования пакетов/датаграмм/сегментов для отправки. Так как по уму это всё реализовано в NDIS 6.1, то надо хотя бы Windows Server 2008.

Результаты тестирования для оборудования с высоким быстродействием:Testing results for high-end hardware:

Тестирование проводилось с 1500 клиентами.Testing was performed with 1500 clients. Трафик делился в следующем отношении: 70 % — клиенты Teredo и 30 % — клиенты IPHTTPS.Traffic split was 70% Teredo and 30% IPHTTPS. Во всех тестах использовался TCP-трафик через Nat64 с использованием 2 туннелей IPsec для каждого клиента.All tests involved TCP traffic over Nat64 using 2 IPsec tunnels per client. Во всех тестах использование памяти было незначительным, а использование ЦП — приемлемым.In all tests, memory utilization was light and CPU utilization was acceptable.

Результаты отдельных тестов:Individual Test Results:

В следующих разделах приводится описание отдельных тестов.The following sections describe individual tests. В заголовке каждого раздела выделены основные элементы каждого теста с кратким описанием результатов; далее следует таблица с подробной информацией о результатах.Each section title highlights the key elements of each test followed by a summary description of the results and then a chart containing the detailed results data.

1500 клиентов, разделение трафика 70/30, пропускная способность 153,2 Мбит/с1500 clients, 70/30 split, 153.2 Mbits/sec throughput

Следующие пять тестов представляют оборудование с высоким быстродействием.The following five tests represent high-end hardware. В следующих тестах использовались 1500 клиентов со средней пропускной способностью примерно 153,2 Мбит/с и разделением трафика между 1050 клиентами Teredo и 450 клиентами IPHTTPS.In the below test runs there were 1500 clients with an average throughput of 153.2 Mbits/sec and a traffic split of 1050 Teredo and 450 IPHTTPS. Среднее использование ЦП во всех пяти тестах составило 50,68 %, а среднее использование памяти, выраженное в процентах зарегистрированного количества байт от общей доступной памяти в 8 ГБ, — 22,25 %.CPU utilization averaged 50.68% across the five tests, and average memory utilization, expressed as a percentage of committed bytes of the total available memory of 8Gb, was 22.25%.

СценарийScenario Среднее использование ЦП (по счетчику)CPUAvg (from counter) Мбит/с (на стороне предприятия)Mbit/s (Corp Side) Мбит/с (на стороне Интернета)Mbit/s (internet Side) Активные QMSAActive QMSA Активные MMSAActive MMSA Использование памяти (система с 4 ГБ ОЗУ)Mem Utilization (4 Gig system)
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 51,71243751.712437 157,029157.029 216,29216.29 3000,313000.31 30463046 21,58 %21.58%
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 48,8602020548.86020205 151,012151.012 206,53206.53 3002,863002.86 3045,33045.3 21,15 %21.15%
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 52,2397951952.23979519 155,511155.511 213,45213.45 3001,153001.15 3002,93002.9 22,90 %22.90%
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 51,2626976751.26269767 155,09155.09 212,92212.92 3000,743000.74 3002,43002.4 22,91 %22.91%
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 50,1575130750.15751307 154,772154.772 211,92211.92 3000,93000.9 3002,13002.1 22,93 %22.93%
Высокопроизводительное оборудование. 1050 клиенты Teredo. 450. клиенты IPHTTPS.High-end HW. 1050 Teredo clients. 450 IPHTTPS clients. 49,8366560749.83665607 145,994145.994 201,92201.92 3000,513000.51 30063006 22,03 %22.03%

Netfilter

Linux has an advanced firewall capability as a part of the kernel.

Netfilter provides functions:

  • packet filtering
  • address translation

Properties that matching filter can be defined with:

  • Network interface
  • IP address, IP address range, subnet
  • Protocol
  • ICMP type
  • Port
  • TCP flag
  • State

Netfilter classifies each packet into one of the following 4 states:

  • NEW
  • ESTABLISHED
  • RELATED
  • INVALID

Configure

To reduce the number of connections in TIME_WAIT state, we can decrease the number of seconds connections are kept in this state before being dropped:

Misc Notes: You may want to reduce net.netfilter.nf_conntrack_tcp_timeout_established to 900 or some manageable number as well.

«Господи, я не хочу в этом разбираться!»

И не нужно. Я уже разобрался и, чтобы не тратить время на то, чтобы объяснять это коллегам, написал набор утилит — netutils-linux. Написаны на Python, проверены на версиях 2.6, 2.7, 3.4, 3.6.

network-top

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

rss-ladder

Эта утилита распределяет прерывания сетевой карты на ядра выбранного физического процессора (по умолчанию на нулевой).

autorps

Эта утилита позволяет настроить распределение обработки пакетов между ядрами выбранного физического процессора (по умолчанию на нулевой). Если вы используете RSS, скорее всего вам эта утилита не потребуется. Типичный сценарий использования — многоядерный процессор и сетевые карты с одной очередью.

server-info

Данная утилита позволяет сделать две вещи:

  1. : посмотреть, что за железо вообще установлено на сервере. В целом похоже на велосипед, повторяющий , но с акцентом на интересующие нас параметры.
  2. : найти узкие места в аппаратном обеспечении сервера. В целом похоже на индекс производительности Windows, но опять же с акцентом на интересующие нас параметры. Оценка производится по шкале от 1 до 10.

Прочие утилиты

  • автоматически увеличивает буфер выбранной сетевой карты до оптимального значения.
  • отключает плавающую частоту процессора. Энергопотребление будет повышенным, но это не ноутбук без зарядного устройства, а сервер, который обрабатывает гигабиты трафика.

Monitoring and Diagnosing

  • ss
  • ip
  • ethtool
  • /proc/net/snmp
  • SystemTap
    • nettop.stp
    • socket-trace.stp
    • dropwatch.stp
    • latencytap.stp

Performance Metrics

  • packets received and sent
  • bytes received and sent
  • collisions per second
    • the number of collisions that occur on the network that the respective interface is connected to
    • sustained values of collisions often concerns a bottleneck in the network infrastructure (consists of hubs ?) other than the server
  • packets dropped
  • overruns
    • represents the number of times that the network interface ran out of buffer space
    • this metric should be used in conjunction with the packets dropped value to identify a possible bottleneck in network buffers or the network queue length
  • errors
    • the number of frames marked as faulty
    • this is often caused by a network mismatch or a partially broken network cable

Работаем с Header Data Split

Фича достаточно интересна и анонсирована только в NDIS 6.1. Суть такова – допустим, что у Вас нет Chimney Offload и Вы обрабатываете заголовки программно. К Вам приходят кадры протокола Ethernet, а в них, как обычно – различные вложения протоколов верхних уровней – IP,UDP,TCP,ICMP и так далее. Вы проверяете CRC у кадра, добавляете кадр в буфер, а после – идёт специфичная для протокола обработка (выясняется протокол сетевого уровня, выясняется содержимое заголовка и предпринимаются соответствующие действия). Всё логично.

Но вот есть одна проблема. Смотрите. Если Вы приняли, допустим, сегмент TCP-сессии, обладающий 10К данных, то, по сути, последовательность действий будет такая (вкратце):

  1. Сетевая карта: Обработать заголовок 802.3; раз там 0x0800 (код протокола IPv4), то скопировать весь пакет и отдать наверх на обработку. Ведь в данные нам лезть незачем – не наша задача, отдадим выше.
  2. Минипорт: Прочитать заголовок IP, понять, что он нормальный, найти код вложения (раз TCP – то 6) и скопировать дальше. Данные-то не нам не нужны – это не наша задача, отдадим выше.
  3. NDIS: Ага, это кусок TCP-сессии номер X – сейчас изучим его и посмотрим, как и что там сделано

Заметили проблему? Она проста. Каждый слой читает свой заголовок, который исчисляется в байтах, а тащит ради этого путём копирования весь пакет.

Технология Header-Data Split адресно решает этот вопрос – заголовки пакетов и данные хранятся отдельно. Т.е. когда при приёме кадра в нём обнаруживается “расщепимое в принципе” содержимое, то оно разделяется на части – в нашем примере заголовки IP+TCP будут в одном буфере, а данные – в другом. Это сэкономит трафик копирования, притом очень ощутимо – как минимум на порядки (сравните размеры заголовков IP, который максимум 60 байт, и размер среднего пакета). Технология крайне полезна.

Как включить Header-Data Split в Windows

Включится оно само, как только сетевой драйвер отдаст минипорту флаг о поддержке данной технологии. Можно выключить вручную, отдав NDIS_HD_SPLIT_COMBINE_ALL_HEADERS через WMI на данный сетевой адаптер – тогда минипорт будет “соединять” головы и жо не-головы пакетов перед отправкой их на NDIS. Это может помочь в ситуациях, когда адаптер некорректно “расщепляет” сетевой трафик, что будет хорошо заметно (например, ничего не будет работать, потому что TCP-заголовки не будут обрабатываться корректно). В общем и целом – включайте на уровне сетевого адаптера, и начиная с Windows Server 2008 SP2 всё дальнейшее будет уже не Вашей заботой.

Окружение для тестирования

Основы

  • How to receive a million packets per second от CloudFlare;
  • How to achieve low latency with 10Gbps Ethernet от CloudFlare;
  • Scaling in the Linux Networking Stack из документации по ядру Linux.

Машины

  • Мы использовали два экземпляра в Amazon AWS EC2 с CentOS 7.
  • На обоих машинах включена enhanced networking.
  • Каждая машина — NUMA с 2 процессорами, у каждого процессора по 9 ядер, у каждого ядра по 2 потока (hyperthreads), что обеспечивает эффективный запуск 36 потоков на каждой машине.
  • У каждой машины по сетевой карте 10Gbps (NIC) и 60 Гб оперативной памяти.
  • Для поддержки enhanced networking и IPvlan мы установили ядро Linux 4.3.0 с драйвером Intel ixgbevf.

Конфигурация

Receive Side Scaling (RSS)IRQReceive Packet Steering (RPS)

  • IRQ. Первое ядро каждого из двух узлов NUMA настроено на получение прерываний из NIC. Чтобы сопоставить CPU с узлом NUMA, используется :

    Эта настройка выполняется записью и в , где номера IRQ получаются через :

  • Receive Packet Steering (RPS). Было протестировано несколько комбинаций для RPS. Чтобы уменьшить задержку, мы разгрузили процессоры от обработки IRQ, используя только CPU под номерами 1–8 и 10–17. В отличие от в IRQ, у sysfs-файла нет постфикса , поэтому для перечисления CPU, которым RPS может направлять трафик, используются битовые маски (подробнее см. Linux kernel documentation: RPS Configuration):
  • Transmit Packet Steering (XPS). Все процессоры NUMA 0 (включая HyperThreading, т.е. CPU под номерами 0—8, 18—26) были настроены на tx-0, а процессоры NUMA 1 (9—17, 27—37) — на tx-1 (подробнее см. Linux kernel documentation: XPS Configuration):
  • Receive Flow Steering (RFS). Мы планировали использовать 60 тысяч постоянных подключений, а официальная документация рекомендует округлить это количество до ближайшей степени двойки:
  • Nginx. Nginx использовал 18 рабочих процессов, у каждого — свой CPU (0—17). Это настраивается с помощью :
  • Tcpkali. У Tcpkali нет встроенной поддержки привязки к конкретным CPU. Чтобы использовать RFS, мы запускали tcpkali в и настроили планировщик для редкого переназначения потоков:

tunedправила NOTRACK

От переводчика: Большое спасибо коллегам из Machine Zone, Inc за проведённое тестирование! Оно помогло нам, поэтому мы захотели поделиться им и с другими.
P.S. Возможно, вас также заинтересует наша статья «Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров».

IEEE 802.11г

Ни в одном беспроводном стандарте толком не описаны правила роуминга, то есть перехода клиента от одной зоны к другой. Это намереваются сделать в стандарте IEEE 802.11г.

Стандарт IEEE 802.11ac

Он обещает гигабитные беспроводные скорости для потребителей.

Первоначальный проект технической спецификации 802.11ac
был подтвержден рабочей группой (TGac) в прошлом году, в то время как ратификация Wi-Fi Alliance
ожидается в конце этого года. Несмотря на то, что стандарт 802.11ac
пока в стадии проекта и еще должен быть ратифицирован Wi-Fi Alliance и IEEE
, мы уже начинаем видеть продукты гигабитного Wi-Fi, доступные на рынке.

Характеристики стандарта нового поколения Wi-Fi 802.11ac:

WLAN 802.11ac
использует целый ряд новых методов для достижения огромного прироста производительности к теоретически поддерживает гигабитный потенциал и обеспечение высоких пропускных способностей, таких как:

  • 6GHz
    полоса

  • Высокая плотность модуляции до 256 QAM.

  • Более широкие полосы пропускания — 80MHz для двух каналов или 160MHz для одного канала.

  • До восьми Multiple Input Multiple Output пространственных потоков.

Многопользовательские MIMO низкого энергопотребления 802.11ac ставят новые проблемы для разработки инженеров, работающих со стандартом. Далее мы обсудим эти проблемы и доступные решения, которые помогут разработке новых продуктов, основанных на этом стандарте.

Более широкая полоса пропускания:

802.11ac имеет более широкую полосу пропускания 80 MHz или даже 160 MHz по сравнению с предыдущим до 40 MHz в стандарте 802.11n. Более широкая полоса пропускания приводит к улучшению максимальной пропускной способности для цифровых систем связи.

Среди наиболее сложных задач проектирования и производства — генерация и анализ сигналов широкой полосы пропускания для 802.11ac. Потребуется тестирование оборудования, способного обрабатывать 80 или 160 MHz для проверки передатчиков, приемников и компонентов.

Для генерации 80 MHz сигналов, многие генераторы RF сигналов не имеют достаточно высокой частоты дискретизации для поддержки типичного минимума 2X соотношения пере дискретизации, которые дадут в результате необходимые образы сигналов. Используя правильные фильтрации и пере дискретизации сигнала из Waveform файла, возможно генерировать 80 MHz сигналы с хорошими спектральными характеристиками и EVM.

Для генерации сигналов 160 MHz
, в широком диапазоне генератор волновых сигналов произвольной формы (AWG), такие как Agilent 81180A, 8190A могут быть использованы для создания аналоговых I/Q сигналов. Эти сигналы могут быть применены к внешнему I/Q. Как входы векторного генератора сигналов для преобразования частоты RF. Кроме того, можно создать 160 MHz сигналы с использованием 80 +80 MHz режима поддерживающего стандарт для создания двух сегментов 80 MHz в отдельных MCG или ESG генераторах сигнала, объединив затем радиосигналы.

MIMO:
MIMO
является использованием нескольких антенн для повышения производительности системы связи. Вы могли видеть некоторые Wi-Fi точки доступа, имеющие более одной антенны, торчащие из них, — эти маршрутизаторы используют технологию MIMO.

Проверкой MIMO конструкций является изменение. Многоканальный генерации и анализ сигналов могут быть использованы для представления о производительности устройств MIMO и оказания помощи в устранении неполадок и проверки проектов.

Усилитель Линейности:

Усилитель Линейности является характеристикой и усилителем с помощью которого выходной сигнал усилителя остается верным входному сигналу по мере возрастания. Реально усилители линейности линейны только до предела, после которого выход насыщается.

Есть много методов для улучшения линейности усилителя. Цифровой предыскажения является одним из таких технику. Автоматизация проектирования программного обеспечения, как SystemVue обеспечивает приложение, которое упрощает и автоматизирует цифрового дизайна предыскажений для усилителей мощности.

Совместимость с предыдущими версиями

Хотя стандарт 802.11n используется уже в течение многих лет, до сих пор также работают многие маршрутизаторы и беспроводные устройства более старых протоколов 802.11b и 802.11g. Также и при переходе к 802.11ac, будут поддерживаться старые Wi-Fi стандарты и обеспечиваться обратная совместимость.

Пока это все. Если у Вас еще есть вопросы, можете смело написать мне в,

Настраиваем использование NetDMA в Windows

NetDMA – достаточно интересная функция. Смысл её применения есть тогда, когда у Вас не поддерживается Chimney Offload и Вы хотите ускорить обработку сетевых подключений. NetDMA позволяет копировать без участия CPU данные (в общем, как и любой DMA-доступ) из приемных буферов сетевого стека сразу в буферы приложений, чем снимает с CPU данную задачу по тупому выполнению чего-то типа .

Говоря проще, если Ваша сетевая плата не может “вытащить” на себя полную обработку TCP-соединений, то NetDMA хотя бы разгрузит процессор от самой унылой части задачи по обслуживанию сетевых соединений – копированию данных между сетевой подсистемой и использующими её приложениями.

Секретный уровень

Если Вы дочитали до этого места, то дальше не читайте – опасно. Но вообще, в том же ключе – – есть параметр , тоже типа , который, что и логично, исходя из его названия, указывает минимальный размер пакета, для которого имеет смысл инициировать DMA-передачу. Параметр данный выставляется автоматически и его тюнинг имеет слабый практический смысл – т.е. в принципе можно представить ситуацию, когда система поставит слишком малый параметр, и будет слишком часто переключаться на DMA, а Вы это поправите вручную, но очень слабо могу представить себе КПД этой операции – выяснять сие путём достаточно кропотливых синтетических тестов, чтобы выиграть призрачные доли процента на единственной операции в единственной подсистеме, притом доли эти будут укладываться в погрешность измерений, весьма уныло.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий