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

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

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

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

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

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

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

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

Ну пока хочу 100 Mbit , а там просто смотрю в перспективу
А алгоритм на gzip не подкинешь? Как он в плане аппаратного воплощения?

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

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

Абсолютно случайные данные особенно не сожмешь - теоретически - надо будет определять содержимое пакета данных, и для разных данных - разные упаковщики. Когда пакет относительно однороден - хорошо работает 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-мя словами. Эффективно сжимает повторяющиеся подстроки и цепочки одинаковых символов (можно забабахать цепочки бит).