Введение

В настоящее время выпускаются две серии PCI-адаптеров с интерфейсами E1. Поставляемый с адаптерами комплект драйверов для ОС Linux позволяет использовать их как для построения сетей передачи данных, так и для создания специализированных программно-аппаратных комплексов.

Применение PCI-адаптеров в сетях передачи данных подразумевает использование стека протоколов ОС Linux и достаточно хорошо документировано. При этом, как правило, у пользователей нет необходимости углубляться в тонкости работы адаптеров, организации обмена и т.д. Все необходимые действия выполняются комплектом драйверов, а задача эксплуатации сводится к несложной настройке и управлению сетевым стеком ОС Linux.

В противоположность этому, использование PCI-адаптеров в специализированных приложениях обработки потоков E1 подразумевает разработку приложений тесно взаимодействующих с комплектом драйверов и, соответственно, требует понимания многих технических аспектов. Этот документ позволяет разработчикам бегло ознакомиться с основными моментами, оценить возможность и перспективность применения изделий для решения поставленных перед ними задач.

Комплект драйверов позволяет штатно организовать приём/передачу данных в двух режимах:

• Режим HDLC - обеспечивается приём/передача пакетных данных с соответствующим деформатированием/форматированием и контролем/формированием контрольных сумм;
• «Телефонный» режим - обеспечивается прозрачный доступ к байтам, передаваемым в канальных интервалах E1;

Особенности Tau-PCI/xE1:

В моделях Tau-PCI/2E1 и Tau-PCI/4E1 для каждого интерфейса E1 в аппаратуре реализован блок поддержки «телефонного» режима. К такому блоку может быть подключен только один логический канал. К интерфейсу E1 можно «подключить» несколько логических каналов, просто распределив канальные интервалы между ними. Но только один из этих каналов может работать в «телефонном» режиме.

Разделение потока E1 на несколько «телефонных» потоков данных неоправданно, при этом кратно возрастает количество прерываний и накладных расходов на обслуживание. При необходимости несложно реализовать «софтверное» мультиплексирование, которое заведомо будет более масштабируемым и гибким. Другими словами, такое ограничение оправдано и подталкивает разработчиков к разработке правильной архитектуры приложений.

В Tau-PCI для телефонного режима реализовано автоматическое совмещение прерываний по приёму и передачи, что почти вдвое уменьшает нагрузку в экстремально многоканальных конфигурациях (4 и более нагруженных адаптера Tau-PCI/4E1 в одной системе).

Особенности Tau-PCI/32:

В моделях линейки Tau-PCI/32 таких ограничений нет, имеется 32 логических канала, каждый из которых может работать в любом режиме. Однако, достаточно часто эта возможность используется неправильно. Типовая ошибка - использование тридцать одного канала для одновременного обмена с тридцать одним канальным интервалом E1 в «телефонном» режиме. В такой схеме количество прерываний и накладных расходов в 31 раз больше, что часто приводит к невозможности работы нескольких адаптеров Tau-PCI/32.

По подобным причинам, а также по соображениям что большинству пользователей нужно только несколько логических каналов, в последних версиях комплекта драйверов по-умолчанию для моделей Tau-PCI/32 доступно только 4 логических канала. При этом сильно сократился объем информации выдаваемой sconfig , а включить требуемое количество каналов можно просто переопределив один #define.

Стоит сказать, что Tau-PCI/32 имеет больше возможностей в сравнении с Tau-PCI/xE1, но у адаптеров линейки Tau-PCI/xE1 ниже стоимость из расчета на обработанный канал E1. Для Tau-PCI/32 есть подробная документация по DDK (см. снизу на странице адаптера), и только через DDK можно использовать некоторые возможности.

Использование протокола «raw»:

Для получения доступа к «телефонному» режиму, равно как и для обмена HDLC-пакетами, необходимо использовать протокольный модуль craw.ko, который входит в состав комплекта драйверов и подключается к логическому каналу командой «sconfig chan_name raw».

При подключении протокольного модуля craw.ko в /dev/cronyx создается вход для обмена с логическим каналом через файловый дескриптор. После этого программа пользователя должна организовать взаимодействие посредством системных вызовов open(), close(), read(), write() и select().

Протокольный модуль craw.ko можно использовать как в «телефонном» режиме, так и в режиме HDLC. Функционирование craw.ko и взаимодействие при этом строится по сути одинаково, различия обусловлены только пакетной природой HDLC и непрерывностью «телефонных» данных.

Режим HDLC:

В режиме HDLC обмен осуществляется пакетам HDLC, т.е. каждый вызов read() или write() приводит к приёму или передаче HDLC-пакета. Если пользователь не поставляет данных для передачи, то в канале будут передаваться HDLC-флаги. Если вовремя не вычитывать данные, то принятые HDLC-пакеты будут потеряны. Размер буфера передаваемый в read() должен быть достаточен для размещения самого большого пакета, иначе будет производиться усечение под размер предоставленного буфера. Лишние вызовы read() или write() в неблокируемом режиме приведут к ошибке, а в блокируемом режиме к приостановке.

Стоит отметить, что HDLC-режим аналогично работает на PCI-адаптерах с последовательными синхронными интерфейсами. Например V.35, RS-530 и т.д.

«Телефонный» режим:

В «телефонном» режиме поток данных непрерывен и постоянен, поэтому обмен происходит равными порциями через почти равные промежутки времени. Если передатчик локального интерфейса E1 синхронизирован от одного источника с передатчиком на другой стороне, то прием и передача будут идти на одной скорости. Если нет, то в соответствии с рекомендацией G.703 допускается отклонение частоты ±50ppm (50x10^-6) с каждой стороны, т.е. ±100 ppm (10^-4) между сторонами. При битовой скорости 2048000 бит/сек возможно накопление «разницы» до 205 бит в секунду. Кроме этого, возможны произвольные колебания и дрейф частот в пределах диапазона ±50 ppm. Следует учитывать эти обстоятельства, если предполагается режим работы с раздельной синхронизацией (возможно только на моделях Tau-PCI/xE1 в режиме независимых каналов).

Обмен с файловыми дескрипторами устройства должен идти порциями данных длинной равной mtu. В свою очередь, значение mtu должно быть кратно количеству выбранных таймслотов и не превышать размера соответствующего 32 кадрам E1. Таким образом, задавая размер mtu вы можете выбирать сколько кадров E1 будет соответствовать одной порции данных. Например, максимум 32 байта если выбран один таймслот, и максимум 32x30=960 (но кратно 30 байтам) если выбрано 30. Формат принимаемых/передаваемых данных достаточно очевиден - в памяти последовательно располагаются байты для последовательности выбранных канальных интервалов. Если порция данных соответствует нескольким кадрам E1, то последовательность выбранных канальных интервалов повторяется для каждого из кадров E1. Порядок битов соответствует принятому в E1 «телефонному» - старший бит передается первым (для HDLC порядок обратный).

В драйверах адаптеров есть очереди приёма и передачи в виде цепочек DMA- дескрипторов. Каждая порция передаваемых данных ставится в очередь передачи. Каждая принятая порция по сигналу (прерыванию от адаптера) снимается с очереди и передается в файловый дескриптор. Вычитывание принимаемых данных организовать достаточно просто посредством select() или треда с блокируемым read(), порции данных будут поступать по мере приёма битов из выбранных канальных интервалов.

С передачей всё немного сложнее. Во-первых, при отсутствии данных на передачу в «телефонном» режиме, канальные интервалы E1 будут заполняться кодом 0xFF (mode=phony), либо 0xD5 (mode=voice). Драйвер при этом посчитает ошибку «underrun», но никакого специального уведомления выполняющаяся программа не получит. Соответственно основная задача - правильно организовать и обслуживать очередь передачи из прикладной программы. Если задержка (за счет буферизации, т.е. пребывания в очереди) не критична, то самый простой путь такой-же как с приёмом - использовать select() или блокируемый write() в отдельном треде. При этом вы заполняете очередь до предела и подпитываете, как только появляется место. Это самый простой и надежный способ, достаточно хорошо защищенный от латентности системы, минус только один - задержка данных в пути передачи.

Если нужно обеспечить минимизацию задержки в пути передачи, то придется использовать realtime-ядро linux и достаточно глубоко погрузиться в этот вопрос. Как вариант написать свой модуль ядра для поддержки требуемого протокола в пути/цикле обработки прерываний. Так например сделано в наших протокольных модулях поддержки DAHDI и ранее zaptel, для взаимодействия с IP-АТС Asterisk.

Альтернативный, но не очень надежный из-за латентности, способ - использовать единую синхронизацию (синхронизировать передатчик от приемника, модели Tau-PCI/32 всегда работают в этом режиме) и передавать очередную порцию данных по выходу из read().
Например так:

1. Включаем на адаптере mux-режим или синхронизируем E1 по принимаемому сигналу (sync=rcv). Это важно, чтобы скорость передачи в точности совпадала с приёмом;
2. Открываем файловый дескриптор в блокируемом режиме или в неблокируемом и используем select();
3. До первого read() делаем несколько write(), этим создаем preload-очередь на передачу. Размер preload-данных определяет запас буферизации;
4. В цикле делаем read(), и сразу за ним write(). Тем самым поддерживая заполнение очереди передачи на постоянном уровне;
5. Так как при единой синхронизации на каждый принятый блок всегда будет один переданный, а невычитанные вовремя принятые блоки буферизируются, то такая схема работает очень хорошо, с поправкой на латентность системы.

По нашей оценке для достаточно надежной работы подобного «тяни- толкая» на средней linux-системе необходимо обеспечить буфер на 5-10 ms. Используя realtime-ядро и/или программное окружение, которое не создает ядру проблем с латентностью, возможно получить неплохие realtime-характеристики.