Jump to content

    

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

Recommended Posts

Maksim

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Maksim

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Harbour

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

khach

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

jeka

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

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

Share this post


Link to post
Share on other sites

acex2

Если содержание сжимаемых данных (т.е. мультимедиа, текст, 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 постоянно падают.

Share this post


Link to post
Share on other sites

Wilde

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

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

Share this post


Link to post
Share on other sites

Fast

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.