Arial Georgia Tahoma Times New Roman Verdana

Модемное сжатие: V.44 против V.42bis

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

Введение

Известно, что при использовании модемной связи для просмотра веб-страниц в интернете, приема текстовых документов или объемных почтовых вложений существенную роль играет сжатие данных. Наиболее часто для этого применяется "модемное" сжатие данных, наиболее распространенный на сегодня протокол сжатия V.42bis служит именно этим целям. Передающий модем следит за потоком данных, и, если данные поддаются сжатию, сжимает и затем передает их через узкое место — телефонную сеть — в уже упакованном виде. Принимающий модем "на лету" распаковывает данные и передает их в компьютер. Различные типы данных по разному сжимаются: в зависимости от конкретной ситуации "модемное" сжатие позволяет получить выигрыш от нескольких процентов до 5–10 раз по сравнению с передачей данных в исходном (несжатом) виде. Поэтому пользователю должно быть небезразлично, насколько хорошо работает в конкретном модеме данная функция. Одна из целей данного материала — сравнение эффективности различных реализаций протоколов сжатия.

Эффективность сжатия протокола V.42bis в общем случае зависит от двух основных параметров протокола: размера словаря сжатия и длины строки. С помощью строки передающая сторона описывает определенную последовательность символов в потоке данных от компьютера и заменяет такую последовательность более коротким кодовым словом при передаче. Принимающий модем, получив кодовое слово, трансформирует его в соответствующую строку. При этом, чем больше символов в строке (больше ее длина), тем большие повторяющиеся фрагменты могут заменяться кодовыми словами, следовательно, тем эффективнее может быть сжатие. В том случае, если длинных повторяющихся участков мало, использование более коротких кодовых строк может способствовать получению лучших результатов. Совокупность используемых строк и соответствующих им кодовых слов составляет словарь — его размер определяется в элементах (строках). Структура словаря динамическая, состав элементов изменяется в процессе передачи в зависимости от того, какие последовательности встречаются в потоке данных чаще других. Чем больше размер словаря, тем большее количество различных строк может использоваться в процессе сжатия. Физическим фактором, ограничивающим максимальные размеры параметров протокола V.42bis в модемах различных производителей, является, прежде всего, имеющийся в распоряжении объем оперативной памяти (т.н. "быстрой" ОЗУ).

Само по себе сжатие может быть как полезным, так и нежелательным — в том случае, если передаются практически несжимаемые данные, попытка сжать их приведет к увеличению объема передаваемых данных. Протокол V.42bis способен отслеживать ситуацию, когда сжатие перестает приносить выгоду, и переключаться из режима сжатия в т.н. "прозрачный" режим. Вместе с тем излишне частое переключение из одного режима в другой снижает общую пропускную способность канала. Критерии переключения из режима в режим определяются конкретными производителями, и могут различаться у разных модемов. Интеллект алгоритма "переключений" во многом определяет общий КПД при передаче данных.

Следует обратить внимание читателей на тот факт, что не совсем верно было бы говорить о данном материале, как о тестировании исключительно функции сжатия. Дело в том, что для работы протокола сжатия необходимо использование еще одного протокола, отвечающего непосредственно за прием/передачу данных. В отличие от потоковой передачи внутри компьютера, данные, передаваемые посредством телефонной сети, могут быть подвержены воздействию помех. В случае использования потокового метода при модемной передаче любая случайная ошибка непоправимо исказит поток данных. Для того, чтобы избежать этого, в модемах предусмотрен протокол канального уровня — V.42, называемый также протоколом коррекции ошибок. На него возложен контроль целостности передаваемых данных.

Кратко описать функции протокола V.42 можно следующей схемой: данные, принимаемые от компьютера (в том числе, те, которые сжаты протоколом V.42bis), разбиваются на блоки фиксированной длины, или "кадры", несколько таких кадров составляют "окно". Принимающий модем последовательно принимает каждый из кадров, а в ответ на прием последнего кадра из "окна" посылает подтверждение об успешном приеме. Получив подтверждение, передающий модем начинает отправку следующей порции данных. Если в процессе приема из-за случайной ошибки кадр был поврежден, принимающий модем пошлет запрос на повторную передачу этого кадра: таким образом достигается целостность данных в процессе передачи. Само собой, создание такой логической структуры — кадров, окна — требует определенных накладных расходов. Объем служебной информации в кадре — фиксированная величина, а значит, чем больше размер кадра, тем меньший процент от общего количества данных составят накладные расходы. То же самое можно сказать и про число кадров в окне: для окна размером в пять кадров при отсутствии ошибок модему придется подтверждать каждый пятый успешно принятый кадр, а при окне размером в 15 кадров — только каждый пятнадцатый.

Так как в модемах разных производителей по-разному реализована структура кадр/окно, то, очевидно, и общая величина накладных расходов канального уровня будет у них несколько отличаться. Насколько велики оказываются эти различия у разных модемов, будет рассмотрено ниже.

Методика

В качестве основных "тестовых" сжимаемых файлов используется стандартный набор, используемый западными компьютерными изданиями для сходных целей — TSB-38. В ходе данных испытаний проверяются особенности работы модемов при приеме файлов.

Файлы принимаются с ftp-сервера провайдера MTU-Inform. В качестве сервера используется Cisco 5300 с модемами MICA, поддерживающими как V.42bis, так и V.44 (V92/V44 preview software). Линейная скорость принимающих модемов ограничена значением 9600 бит/с как по соображениям минимизации возможного помехового влияния и исключения ошибок при приеме, так и по соображениям исключения влияния пропускной способности COM-порта на демонстрируемые показатели.

Испытуемый модем в качестве вызывающего модема устанавливает связь с хостовым модемом, после чего в терминальном режиме осуществляется прием тестовых файлов. Для каждого из модемов проводится по 10 попыток измерений с каждым типом файлов. С целью исключения влияния протокола коррекции ошибок в расчете учитываются только те попытки, когда в процессе работы не возникало сбойных кадров в направлении как приема, так и передачи. В случае отклонения результата в какой-либо из попыток от среднего значения более чем на 1%, количество измерений пропорционально увеличивается.

Факультативно проверяется эффективность при передаче неоднородного файла. Примером файла с неоднородным содержимым является специальный тестовый файл, полученный репликацией сборки из html-текста, картинок и java-скриптов (заглавная страница сайта www.zyxel.ru) объемом 661440 байт. В качестве принимающего модема при этом используется модем HTS Express, с предустановленным размером кадра коррекции ошибок 128 октетов, и размером словаря/строки 1024/16. Данное ограничение нивелирует физические свойства различно реализованных в испытываемых модемах протоколов канального уровня, с целью выявления в первую очередь отличий в работе алгоритмов сжатия.

В результатах факультативной части теста, кроме значения полученного CPS, справочно приводится среднее (по сумме попыток) количество переключений между режимом сжатия и прозрачным режимом, а также средний коэффициент "модемного" сжатия по результатам передачи файла. Последние два параметра определяются на основании данных статистики принимающего модема HTS Express.

Участники испытаний:

• USR Courier 56K (модель 3453) с размером словаря/строки 2048/32 (микропрограмма 1.0.6).
• USR Courier 56K (модель 3453) с размером словаря/строки 4096/32 (модем допускает использование "альтернативного" размера словаря)
• ZyXEL Omni 56K Pro — размер словаря/строки 1024/16 (микропрограмма 1.01)
• ZyXEL U-336E — размер словаря/строки 2048/32 (микропрограмма 1.18)
• LT Win modem (Genius GM56PCI-L) — размер словаря/строки 2048/32 (драйвер версии 6.00)
• LT Win modem (Genius GM56PCI-L) — V.44 (драйвер версии ZOOM 8.02A)
• USR 56K Faxmodem PCI (OEM-2977) — размер словаря/строки 2048/32 (DSP rev. 5.19.1)

Описание файлов, входящих в набор TSB-38.

Файлы, используемые для измерения показателей CPS, получены репликацией стандартных файлов пяти типов:

1. Текстовый файл.
2. Несжатый графический файл.
3. Exe-файл.
4. Архивный (несжимаемый) файл.
5. Смешанный файл, включающий в себя фрагменты 1, 2 и 4-го типа.

Адрес размещения файлов: ftp://ftp.mtu.ru/pub/horgi/test/

Насколько потенциально может быть сжат тот или иной тип, можно посмотреть в таблице 3 — " Сравнение эффективности сжатия данных V.42bis, V.44 и обычного pkzip".

Результаты приема файлов.

Прежде чем перейти к графикам и таблицам, стоит напомнить читателям, что протокол передачи файлов (в данном случае FTP) тоже вносит некоторую часть дополнительных накладных расходов и влияет на итоговую эффективную скорость (CPS). С одной стороны, для максимально "чистой" сравнительной оценки схем сжатия (а также для целей отладки — достигается ли "рекомендованное" значение TSB-38) следовало бы использовать протокол с наименьшими накладными расходами. С другой стороны, учитывая большинство типичных случаев применения (и позиционирования производителями) протоколов сжатия, представляется вполне обоснованным тестирование в условиях, максимально приближенных к традиционным. В то же время, такой подход позволяет пользователю получить более объективную и приближенную к реальности картину.

Относительная эффективность сжатия. За единицу принят результат для приема файлов без сжатия:

Таблица 1:

Эти же результаты в графическом виде:

Результаты по абсолютной эффективной скорости приема данных, CPS:

Таблица 2:

* — результат без сжатия для модемов Omni 56K Pro и LT-Win

Эти же результаты в графическом виде:

Небольшой комментарий к результатам.

Вопреки возможным ожиданиям, результаты работы V.44 достаточно скромные. Безусловно, отрыв от других схем сжатия налицо, но это вовсе не те 20-200%, о которых так много написано в различных источниках. Сравнивая схемы V.42bis и V.44 одного и того же модема — LT Win (GM56PCI-L) — мы можем увидеть выигрыш в производительности от 38% (на несжатых графических файлах, редко встречающихся в web-пространстве) до 12% (на неоднородных файлах, наиболее близких к структуре типичных web-страниц). При сравнении же "максимальной" из приведенных схем V.42bis (Courier 4096/32) и V.44 (в исполнении LT Win) разница в производительности еще больше сглаживается: 31% для экзотических графических форматов, около 13% для чистого текста и менее 4% для данных смешанного типа.

Интереснее выглядит сравнение различных схем V.42bis, в зависимости от используемых структур разброс в результатах между "минимальной" (1024/16) и "максимальной" (4096/32) из приведенных схем достигает от 42% на текстовых файлах до 13% на данных смешанного типа. Справедливости ради стоит заметить, что для несжатой графики аналогичный разброс весьма невелик — всего около 5%, а в случае с exe-файлом минимальная структура V.42bis даже выигрывает в эффективности сжатия 9% с лишним.

Еще один интересный момент: две разных модели ZyXEL — U-336E и Omni 56K Pro. Несмотря на то, что старшая модель имеет вдвое больший объем словаря и длину строки, ожидаемого выигрыша нигде, кроме как на текстовых файлах, не продемонстрировано.

А теперь классический вопрос "а можно ли сжимать сильнее?" Конечно, можно, если рассматривать не потоковое "модемное" сжатие (жестко ограниченное ресурсами быстродействия и памяти), а классические архиваторы.

Сравнение эффективности сжатия данных V.42bis, V.44 и обычного pkzip.

Таблица 3:

Легко видеть, что эффективность pkzip значительно выше, чем любое "модемное" сжатие, а разница в результатах между pkzip-V.44 значительно больше разницы V.44-V.42bis.

Небольшое отступление. В последнее время часто встречаются ссылки на материалы www.v92.com. Те читатели, которые уже успели посмотреть на продемонстрированные там результаты, могут быть несколько удивлены. На графиках с вышеупомянутого сайта результаты сжатия V.44 находятся примерно в середине между результатами V.42bis и Winzip. Но это кажется странным только на первый взгляд. В ходе подготовки результатов теста и сравнения полученных результатов с другими источниками, было подсчитано сжатие при использовании архиваторов в данном тесте и в материале www.v92.com. Для текстового файла разница в сжатии pkzip и Winzip версии "www.v92.com" составила более 18-ти процентов в пользу pkzip, а для графического файла целых 49%. Почему же архиватор на сайте www.v92.com так плохо сжимает файлы, предлагается догадаться самим читателям.

Таким образом, можно говорить о том, что даже с появлением новых протоколов "модемного" сжатия концепция построения сайтов и общие правила подготовки файлов для передачи остаются прежними: все, что поддается сжатию, крайне желательно предварительно сжимать. Для программных (*.exe) файлов традиционные архиваторы обеспечивают значительно больший выигрыш при последующей передаче, для графических файлов также предпочтительно использование форматов без избыточности — gif, jpg и других.

Результаты передачи данных различными модемами.

Данное испытание проводилось для протокола V.42bis, общего для всех рассмотренных модемов. В качестве небольшого дополнения была рассмотрена также одна из "младших" моделей USR — OEM-модем модель 2977.

Как уже говорилось выше, результаты получены при использовании поддерживаемого всеми участниками словаря сжатия объемом 1024 символа и строки длинной 16 символов. При передаче все участники работали с размером кадра коррекции ошибок 128 октетов и размером окна 15 кадров. Исключение составили Omni 56K Pro (размер окна 16 кадров) и LT Win modem (размер окна 8 кадров).

Таблица 4:

По результатам, показанным в таблице, не возникает желания строить график. Опять же, вопреки ожиданиям, несмотря на существенное различие в схемах переключения между режимами, максимальная разница в результатах эффективной скорости составляет всего около двух процентов. Единственное, что обращает на себя внимание — это то, что разница эта возникает у двух моделей одной и той же фирмы (!), а число переключений между режимами "сжатия" и "прозрачным" у обеих моделей почти одинаково. Одна из возможных причин такого расхождения — разница в критериях переключения режимов. Тем не менее, говорить о чьем-либо однозначном лидерстве по результатам этого испытания не приходится.

Что еще оказывает влияние на результаты эффективной скорости.

Как показал опыт, наиболее существенное влияние на результат оказывает используемая в модеме схема сжатия данных — в случае с V.42bis это разные размеры словаря/строки, в случае с V.44 — просто иной алгоритм сжатия. В большинстве ситуаций, чем больше размер словаря сжатия, тем эффективнее сжимаются данные. Под большинством понимаются наиболее часто встречаемые в интернете данные: это, как правило, текст или данные того типа, что в тесте описаны как "файл смешанного типа". Большинство же графических форматов в сети интернет — это предварительно сжатые и уже несжимаемые далее изображения, а программы — это либо самораспаковывающиеся архивы, либо совсем короткие установочные файлы (setup.*** и т.п.). Именно поэтому желающие могут еще раз посмотреть на результаты, обращая внимание в основном на первый и последний элемент данных.

Однако, как уже говорилось, на полученный результат влиял и ряд других факторов, часть из которых имеет объективный характер, часть — более субъективный.

Влияние основного из объективных параметров (размера кадра протокола коррекции ошибок) легко определяется по формуле:

CPS=(линейная_скорость/8)*(62/63)*(размер_кадра_V.42/(размер_кадра_V.42+6))

Следует иметь в виду, что данная формула не учитывает влияния накладных расходов на уровне, более высоком, нежели модемный. Но хотя получить точный абсолютный результат для использования кадра данных определенного размера невозможно, сравнительные результаты при использовании кадров РАЗНОЙ длины, тем не менее, вполне можно увидеть.

Справочно (и для тех, кто любит считать самостоятельно) приведем используемые модемами размеры кадров V.42 (число через дробь — максимальный размер окна):

Таблица 5:

Те читатели, которые внимательно следили все это время за повествованием, могут быть удивлены "несоответствием" между таблицей и небольшим замечанием, сделанным выше. Что ж, к этому "несоответствию" мы обратимся несколько ниже.

Используя данные из таблицы 5 в указанной выше формуле, можно вполне объяснить разницу около 2% между определенными модемами в результатах из таблицы 2 (при приеме архивных файлов).

Размер логической структуры — "окна" протокола V.42 также оказывает влияние (хотя и меньшее) на эффективную скорость приема. Однако, подсчитать разницу между различными схемами сложнее, так как готовой формулы не существует, а задержки при передаче подтверждающих кадров зависят как от конкретных условий в канале (времени прохождения сигнала), так и от субъективных факторов: задержек в удаленном модеме (на прием подтверждающих кадров и последующую реакцию), количества ошибок на уровне протокола V.42, распределения этих ошибок и т.п. Достаточно знать, что в общем случае, чем больше окно, тем меньше задержек при передаче данных.

А теперь вернемся к обещанному объяснению "несоответствия". Речь идет о структуре V.42 (а именно, о размере окна) в модеме ZyXEL Omni 56K Pro. В таблице приведено значение кадра 256 октетов при размере окна 8 кадров. Данная структура используется "по умолчанию". С другой стороны, ничто не запрещает использовать имеющуюся "быструю" оперативную память иначе. Именно этим удалось воспользоваться в факультативном тесте сжатия при передаче: как помнит читатель, там Omni 56K Pro работал с кадром размером 128 октетов при окне в 16 кадров. Эта опция работает в режиме ответа — Omni 56K Pro распределяет имеющиеся в его распоряжении ресурсы наиболее оптимальным образом. Если удаленный модем поддерживает размер кадра 256 октетов, Omni использует эту возможность, экономя на размере "окна", что вполне оправдано, так как размер кадра играет более важную роль в достижении максимальных результатов, нежели размер окна. В том случае, если удаленный модем имеет структуру кадр/окно 128/15, Omni вполне согласится работать и с этими значениями, перераспределив память в соответствии с возможностями удаленного модема. Возможны и нестандартные значения: например, при размере кадра 192 октета максимальный размер окна составит 10 кадров.

Подобная идея реализована также и у некоторых провайдерских модемов, в модемах же для конечного пользователя увидеть ее в действии пока удалось только у Omni 56K Pro.

Помимо рассмотренных причин, влияние которых так или иначе оценивается, существует еще ряд субъективных факторов, способных влиять на эффективную скорость приема данных, и воздействие которых в данном тесте не оценивалось:

Ресурсы быстродействия контроллера модема на высоких скоростях. В рамках данного теста модемы работали на невысокой скорости из соображений получения максимально "чистого" результата. Однако не исключена ситуация, когда контроллер модема перестанет адекватно справляться с задачей подготовки данных для передачи или приема. При низких линейных скоростях такая проблема вряд ли может возникнуть, но на высоких скоростях (или при одновременной работе в режимах передачи и приема) некоторые модемы могут не справиться с увеличившимся потоком данных, результатом чего будет недостижение "расчетных" показателей эффективной скорости. Данная проблема является предметом дальнейших исследований.

Используемая схема треллис-кодирования на V.34. В настоящее время широко используются две схемы: 16-ти позиционная и 64-х позиционная. Применение 64-х позиционной схемы дает некоторые преимущества в помехоустойчивости V.34. В то же время увеличение количества состояний кодера до 64-х увеличивает задержки на обработку данных в модеме. Размер этих задержек крайне невелик, однако, скорее всего, именно по этой причине во многих модемах на чипсете Conexant предусмотрен алгоритм, ограничивающий размер окна на передачу (до 4 кадров) в том случае, если удаленной стороной используется 64-х позиционная схема треллис-кодирования, и при этом в локальном модеме не включен режим SREJ (выборочного перезапроса поврежденных кадров). Это очень похоже на перестраховку, но, к сожалению, серьезных исследований, подкрепленных практическими опытами и открытых для широкого круга по данной теме, на сегодняшний день нет. Поэтому данный вопрос требует как дальнейшего изучения, так и выработки методологии для получения достоверных и сравнимых результатов.

Выводы по результатам теста

1. Заявленное рядом производителей увеличение скорости при использовании V.44 несколько не соответствует суровой действительности, по крайней мере, в рамках нашего опыта. Особенно, если сравнивать сжатие на "несжатой графике", а на чем-то более приземленном — например, тексте, а еще лучше, неоднородных данных (коими является большая часть web-страниц). Возможно, стоит сделать скидку на то, что на стороне провайдера — preview software.

2. В то же время нельзя отрицать того факта, что для любого типа данных протокол V.44 хоть и не намного, но все же эффективнее, чем V.42bis.

3. Расхожее утверждение о том, что "алгоритм V.44 обеспечивает улучшенную компрессию данных до 6:1 по сравнению с максимально возможной величиной 4:1 для V.42Bis" является абсолютно неверным, так как оно не соответствует действительности ни по сравнительным цифрам (50% разницы в эффективности протоколов); ни по оценке максимальной границы для рассмотренных протоколов — на самом деле, утверждать о каких-либо сравнительных цифрах можно только в отношении КОНКРЕТНОГО типа данных.

4. В V.42bis использование структур сжатия максимального размера (при их поддержке, как например, в новой модели USR Courier), в ряде случаев практического использования может быть весьма выгодным.

5. Разница между различными модемами при ПЕРЕДАЧЕ данных хотя и существует, но принимать в расчет эти отличия вряд ли стоит — слишком уж невелик разброс результатов.

6. Оценка разницы в различных схемах сжатия при работе на прием вряд ли позволяет однозначно называть кого-то из участников лидером, а кого-то — аутсайдером. С одной стороны, разброс показанных результатов на наиболее интересных с точки зрения пользователя интернет "неоднородных" данных весьма скромен. С другой стороны, оценивать модем или строить свой выбор, основываясь только на результатах данного теста и в отрыве от испытаний протоколов физического уровня, представляется недальновидным.

7. Как следствие, основной интерес с точки зрения конечного пользователя по-прежнему должны представлять уровень реализации традиционных протоколов физического уровня (V.34, V.90); качество и надежность работы модемов на этом уровне; глубина реализации протоколов коррекции ошибок; оптимальная взаимосвязь последних с протоколами физического уровня.

8. Возможно, в будущем появятся более гибкие и эффективные реализации V.44 (вспомним пример для V.42 у Omni 56K Pro). В таком случае можно будет вновь обратиться к данной теме.

9. Модемное сжатие, вне зависимости от реализации, значительно уступает по эффективности традиционным методам сжатия. Стоит помнить и о возможных альтернативах, которые не были освещены в рамках данной темы: это, в частности, "программное" сжатие данных, как на уровне ppp-протокола, так и на более высоких уровнях модели OSI.

Автор благодарит за техническое содействие, оказанное при проведении данного теста, инженера компании МТУ-Интел Андрея Зимина.