|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 19 Oct 2006 23:39:37
To : Anton Shuko
Subject : Re: туннельный вопрос
--------------------------------------------------------------------------------
Anton Shuko -> Artem Chuprina @ Thu, 19 Oct 2006 11:00:29 +0400:
AS>>>>> вот бы к опенвпн ктонить чота типа bzip2 компресии на тцп
AS>>>>> прикрутил...
AC>>>> Hа bzip2 оно за эти 10% выигрыша по сравнению с zlib будет
AC>>>> ступорить канал намертво. Медленный он дюже, падла.
AS>>> там где жмут, мегобайты в секунду не гоняют :) обеспечит поток до
AS>>> 100кб/с на целероне 500-700 и этого за глаза.
AC>> Hе обеспечит. А если обеспечит, то с потерей в сжатии. bzip2,
AC>> сколь я помню, выигрывает у gzip именно за счет обработки большими
AC>> кусками.
AS> т.е. он не может поточно работать? ему нада заглотить сначала
AS> большой кусок, пережавать его и выплюнуть? собсно наверное. там же
AS> хафманом потом обрабатывается :( меня смутило, что в либе есть
AS> потоки и я их все таки подключил. правда тормозило все... не
AS> процессор жрало, а связь тормозила через такой тунель. ощущение
AS> было, что он собирает необходимый минимум пакетов и потом их
AS> выплевывает.
В принципе - может. Hо видимо, да, по возможности накапливает большой
кусок. Потому что иначе преимущества перед gzip у него не будет. И
так-то, прямо скажем, немного.
AS> а есть вариант библиотеки gzip с увеличенным объемом
AS> словаря/буфера, но при этом чтобы был поточным и мог данные
AS> сплевывать постепенно, а не большими кусками? LZxxxx алгоритмы ето
AS> могут... я юзаю архиватор rzip, он сука круто жмет за счет
AS> большего объема словаря. и быстро. но выковырять оттуда либу не
AS> получилось. давно не програмил, да и чужие сырцы ковырять всегда
AS> было сложно. в доке видел ссылку, что мол алгоритм был
AS> позаимствован у rsync, только размер буфера побольше сделал. хотя
AS> рсинк памяти тоже жрет мама не горюй :)
А rsync, кстати, жмет вроде как гзипом. Свой у него только алгоритм
сравнения, а вовсе не сжатия.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Если ты не боишься синего экрана, то почему боишься черного?
(c) Д.Белявский
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
