Перейти к содержанию
    

Сжатие потока в 100 М/Бит

Кто-нибудь пробовал делать сжатие данных на скорости от 100 до 1000 Мбит/с? Какие алгоритмы используются? Или ссылки на них. Кроме V.42 bis ничего пока не нарыл :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кто-нибудь пробовал делать сжатие данных на скорости от 100 до 1000 Мбит/с? Какие алгоритмы используются? Или ссылки на них. Кроме V.42 bis ничего пока не нарыл :(

А сжимать как? С потерями, без потерь, во сколько раз сжимать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сжимать без потерь :) . Данные очень разнородные, поэтому не которые пакеты данных надо сжимать, а не которые нет(ну если они получатся больше исходного B) )

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Посмотри библиотечку LZO, она как раз для этого предназначена

 

http://www.oberhumer.com/opensource/lzo

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

gzip тоже должен быть не плох - тут все зависит какой у тебя проц

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

gzip тоже должен быть не плох - тут все зависит какой у тебя проц

Проц некатит :( Нужно чтобы это потом запичать в ПЛИС :cranky:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А че за трабла - у меня altera ep1c6 с CPU nios - gzip реализует на ура, проблема только в том что nios тормоз по жизни и такой поток не потянет. А 1000Mbit это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм простым - иначе можешь не успеть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А че за трабла - у меня altera ep1c6 с CPU nios - gzip реализует на ура, проблема только в том что nios тормоз по жизни и такой поток не потянет.  А 1000Mbit это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм простым - иначе можешь не успеть.

Ну пока хочу 100 Mbit ;) , а там просто смотрю в перспективу :)

А алгоритм на gzip не подкинешь? :) Как он в плане аппаратного воплощения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сжимать в ПЛИС, то вопрос поставлен некорректно. Сколько есть ОЗУ для словаря и как долго можно собирать статистику для словаря? Если словарь можно сделать один раз при разработке, на этом можно очень выиграть. Нужно ли (имеет ли смысл) изменять словарь динамически?

Описание сжимаемых данных в студию. Тогда рекомендации будут более существенными.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сжимать в ПЛИС, то вопрос поставлен некорректно. Сколько есть ОЗУ для словаря и как долго можно собирать статистику для словаря? Если словарь можно сделать один раз при разработке, на этом можно очень выиграть.  Нужно ли (имеет ли смысл) изменять словарь динамически?

Описание сжимаемых данных в студию. Тогда рекомендации будут более существенными.

Данные которые надо сжимать могут быть любыми - это локальная сеть и что пользователь будет передавать мне неизвестно (видео, текст, звук и т.д.) :(

Ресур по ПЛИС пока ничем неограничен :w00t:

Я только начал этим заниматься - вот и возник вопрос -> есть у кого какой-нибудь готовый алгоритм (без кучи начальной математики :biggrin: - что-то типа: A+B 10 десять раз, найти i-ый бит и т.д. - чтобы можно было оценить в какую ПЛИС ен-то всё влезет). Но данные к сожалению - РАЗНАРОДНЫ :wacko:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но данные к сожалению - РАЗНАРОДНЫ

 

Абсолютно случайные данные особенно не сожмешь - теоретически - надо будет определять содержимое пакета данных, и для разных данных - разные упаковщики. Когда пакет относительно однороден - хорошо работает RLE - алгоритм простой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

если сжимать пакеты tcp/ip по отдельности, то много не выиграешь из-за их размера. здесь возникает проблема сжатия отдельно заголовков, отдельно содержимого пакетов. причем наилучшее сжатие будет достигаться если каждое ip соединение будет сжиматься как поток со своим динамическим словарем. вообщем, это задача не из легких. Большинство провайдеров предпочитают поставить более производительные трансиверы на оптику, увеличив пропускную способность на порядок, чем заниматься сжатием со средней эффективностью в районе 1.5:1.

и гораздо проще оборудовать под эти цели например персоналку с юниксами, чем изобретать новое изделие.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если содержание сжимаемых данных (т.е. мультимедиа, текст, bin и т.д.) неизвестно, то основной проблемой будет выбор алгоритма сжатия.

 

Из более-менее универсальных алгоритмов для высокоскоростного сжатия на аппаратном уровне больше всего подходят LZW и LZ77. Однако на одной FPGA здесь не "выехать". Так как основой и того и другого алгоритма служит быстрый поиск в динамическом словаре или в скользящем пост-окне, то лучше всего для этого задействовать внешнюю CAM (Content-Addressable Memory), благо их сейчас выпускают многие фирмы, например Cypress, ISSI, SyberLogic и др. CAM используется для поиска соответствий IP<->MAC в быстрых роутеров и обычно называются NSE (Network-Search Engine) - по этому ключевому слову их и стоит искать. Мне приходилось заниматься такими разработками и скорость сжатия можно получить вплоть до нескольких Гбит/сек для LZW и немного меньше для LZ77. Стоимость производства одной PCI платы пару лет назад получалась в пределах 150-200$. Сейчас скорее всего еще меньше, так как из-за конкуренции цены на CAM и быстрые FPGA постоянно падают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

>>это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм >>простым - иначе можешь не успеть.

Плис на таких внутренних частотах пока не работают, а вот внешние каналы связи, например у VIRTEX4 запросто. Все уже будет зависить от алгоритма. И внутренние частоты порядка сотни МГЦ тебя вполне устроят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

acex2 дело говорит

модемное сжатие, сжатие на уровне PPP (Ван Якобсон, LZS, BSD LZW...) - все разновидности LZW. Внешняя CAM бы легла, наверное. LZ77 словарный двухпроходный - отпадает.

Я вот что подумал, может V44 попробуешь адаптировать? Я ее софтово делал - (правда декодер только) неплохая комбинация LZW и RLE, если 2-мя словами. Эффективно сжимает повторяющиеся подстроки и цепочки одинаковых символов (можно забабахать цепочки бит).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...