Maksim 0 29 января, 2005 Опубликовано 29 января, 2005 · Жалоба Кто-нибудь пробовал делать сжатие данных на скорости от 100 до 1000 Мбит/с? Какие алгоритмы используются? Или ссылки на них. Кроме V.42 bis ничего пока не нарыл :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
irum4 0 29 января, 2005 Опубликовано 29 января, 2005 · Жалоба Кто-нибудь пробовал делать сжатие данных на скорости от 100 до 1000 Мбит/с? Какие алгоритмы используются? Или ссылки на них. Кроме V.42 bis ничего пока не нарыл :( <{POST_SNAPBACK}> А сжимать как? С потерями, без потерь, во сколько раз сжимать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maksim 0 29 января, 2005 Опубликовано 29 января, 2005 · Жалоба Сжимать без потерь :) . Данные очень разнородные, поэтому не которые пакеты данных надо сжимать, а не которые нет(ну если они получатся больше исходного B) ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 30 января, 2005 Опубликовано 30 января, 2005 · Жалоба Посмотри библиотечку LZO, она как раз для этого предназначена http://www.oberhumer.com/opensource/lzo Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 11 февраля, 2005 Опубликовано 11 февраля, 2005 · Жалоба gzip тоже должен быть не плох - тут все зависит какой у тебя проц Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maksim 0 12 февраля, 2005 Опубликовано 12 февраля, 2005 · Жалоба gzip тоже должен быть не плох - тут все зависит какой у тебя проц <{POST_SNAPBACK}> Проц некатит :( Нужно чтобы это потом запичать в ПЛИС :cranky: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 12 февраля, 2005 Опубликовано 12 февраля, 2005 · Жалоба А че за трабла - у меня altera ep1c6 с CPU nios - gzip реализует на ура, проблема только в том что nios тормоз по жизни и такой поток не потянет. А 1000Mbit это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм простым - иначе можешь не успеть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maksim 0 12 февраля, 2005 Опубликовано 12 февраля, 2005 · Жалоба А че за трабла - у меня altera ep1c6 с CPU nios - gzip реализует на ура, проблема только в том что nios тормоз по жизни и такой поток не потянет. А 1000Mbit это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм простым - иначе можешь не успеть. <{POST_SNAPBACK}> Ну пока хочу 100 Mbit ;) , а там просто смотрю в перспективу :) А алгоритм на gzip не подкинешь? :) Как он в плане аппаратного воплощения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 12 февраля, 2005 Опубликовано 12 февраля, 2005 · Жалоба Если сжимать в ПЛИС, то вопрос поставлен некорректно. Сколько есть ОЗУ для словаря и как долго можно собирать статистику для словаря? Если словарь можно сделать один раз при разработке, на этом можно очень выиграть. Нужно ли (имеет ли смысл) изменять словарь динамически? Описание сжимаемых данных в студию. Тогда рекомендации будут более существенными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maksim 0 12 февраля, 2005 Опубликовано 12 февраля, 2005 · Жалоба Если сжимать в ПЛИС, то вопрос поставлен некорректно. Сколько есть ОЗУ для словаря и как долго можно собирать статистику для словаря? Если словарь можно сделать один раз при разработке, на этом можно очень выиграть. Нужно ли (имеет ли смысл) изменять словарь динамически? Описание сжимаемых данных в студию. Тогда рекомендации будут более существенными. <{POST_SNAPBACK}> Данные которые надо сжимать могут быть любыми - это локальная сеть и что пользователь будет передавать мне неизвестно (видео, текст, звук и т.д.) :( Ресур по ПЛИС пока ничем неограничен :w00t: Я только начал этим заниматься - вот и возник вопрос -> есть у кого какой-нибудь готовый алгоритм (без кучи начальной математики - что-то типа: A+B 10 десять раз, найти i-ый бит и т.д. - чтобы можно было оценить в какую ПЛИС ен-то всё влезет). Но данные к сожалению - РАЗНАРОДНЫ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vovic 0 14 февраля, 2005 Опубликовано 14 февраля, 2005 · Жалоба Но данные к сожалению - РАЗНАРОДНЫ Абсолютно случайные данные особенно не сожмешь - теоретически - надо будет определять содержимое пакета данных, и для разных данных - разные упаковщики. Когда пакет относительно однороден - хорошо работает RLE - алгоритм простой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jeka 0 15 февраля, 2005 Опубликовано 15 февраля, 2005 · Жалоба если сжимать пакеты tcp/ip по отдельности, то много не выиграешь из-за их размера. здесь возникает проблема сжатия отдельно заголовков, отдельно содержимого пакетов. причем наилучшее сжатие будет достигаться если каждое ip соединение будет сжиматься как поток со своим динамическим словарем. вообщем, это задача не из легких. Большинство провайдеров предпочитают поставить более производительные трансиверы на оптику, увеличив пропускную способность на порядок, чем заниматься сжатием со средней эффективностью в районе 1.5:1. и гораздо проще оборудовать под эти цели например персоналку с юниксами, чем изобретать новое изделие. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
acex2 0 16 февраля, 2005 Опубликовано 16 февраля, 2005 · Жалоба Если содержание сжимаемых данных (т.е. мультимедиа, текст, 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 постоянно падают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Wilde 0 18 марта, 2005 Опубликовано 18 марта, 2005 · Жалоба >>это типа 1ГГц выходит - FPGA должна быть довольно быстрой а алгоритм >>простым - иначе можешь не успеть. Плис на таких внутренних частотах пока не работают, а вот внешние каналы связи, например у VIRTEX4 запросто. Все уже будет зависить от алгоритма. И внутренние частоты порядка сотни МГЦ тебя вполне устроят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Fast 0 31 марта, 2005 Опубликовано 31 марта, 2005 · Жалоба acex2 дело говорит модемное сжатие, сжатие на уровне PPP (Ван Якобсон, LZS, BSD LZW...) - все разновидности LZW. Внешняя CAM бы легла, наверное. LZ77 словарный двухпроходный - отпадает. Я вот что подумал, может V44 попробуешь адаптировать? Я ее софтово делал - (правда декодер только) неплохая комбинация LZW и RLE, если 2-мя словами. Эффективно сжимает повторяющиеся подстроки и цепочки одинаковых символов (можно забабахать цепочки бит). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться