Re: comprehensive rsyncability test

On Sun, Jun 01, 2008 at 02:26:33AM +0400, Dmitry V. Levin wrote:
> > > Я ожидал, что rsyncable deflate не может показать лучший коэффициент
> > > сжатия, чем обычный deflate.  Однако в приложенном файле
довольно много
> > > случаев, когда rsyncable deflate сильнее...
> > 
> > Это связано с cpio hints -- дело в том, что мы пытаемся
начинать новый
> > deflate блок на границе файлов, когда начинается новый файл.
> 
> А, тогда понятно, откуда это берётся.  В других
реализациях rsyncable
> deflate не использовал этого "естественного"
разбиения, и результат,
> естественно, был хуже.

То есть более частое разбиение на блоки может
компенсироваться более
маленьким Huffman tree и более оптимальным частотным
кодированием внутри
блока.  Но для этого требуется дополнительная информация.

Вместе с тем, если файл (внутри cpio) достаточно большой,
то в пределах
файла будет работать rsync_next алгоритм, так что он
сможет отловить
совпадающие куски внутри этого файла (rsync_next делает
блок в среднем
раз в 8K).  То есть, в частности, для src.rpm сохраняется blind
rsyncability.

Re: rpm: rsyncable deflate vs LZMA

On Sat, May 31, 2008 at 07:59:30PM +0300, Kirill A. Shutemov wrote:
> On Sat, May 31, 2008 at 02:25:23PM +0400, Alexey Tourbin wrote:
> > А если заглатывать понемножку, долго переваривать
и какать понемножку,
> > то можно установить связь между входными и
выходными данными.  А это
> > и требуется для rsyncability.
> 
> В фортунки!

$ fortune -a -m rabelaisian
fortune: /usr/share/games/fortune/off: No fortune files in directory.
fortune:/usr/share/games/fortune/off not a fortune file or directory
zsh: segmentation fault  fortune -a -m rabelaisian
$

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: I: firefox3

Alexey Gladkov wrote:
> Привет!
> 
> Как я и обещал, после выхода firefox-3.0-RC1 выкладываю
пробную сборку:
> 
> ftp://ftp.altlinux.org/pub/people/legion/repo/

Сборка обновлена. Попробуйте. Должны работать
расширения и плагины. 
Виса при старте вроде тоже нет.

--

-- 
Rgrds, legion

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: comprehensive rsyncability test

On Sat, May 31, 2008 at 11:44:52PM +0400, Dmitry V. Levin wrote:
> On Sat, May 31, 2008 at 10:58:47PM +0400, Alexey Tourbin wrote:
> > Предварительное тестирование rsyncable gzdio показало,
что эффект
> > от rsyncable deflate есть, и лучше всего он проявляется при
> > незначительном изменении пакетов; кроме того,
пакет должен содержать
> > достаточно большие файлы (если пакет целиком
состоит из маленьких
> > файлов, то rsyncability резко падает).
> > 
> > Но одиночные тесты не выявляют "реального
положения вещей"; требуется
> > более широкое тестирование с привлечением
"реальных данных" за некоторый
> > промежуток времени.
> > 
> > Предлагаю протестировать rsyncability двух каталогов:
> > /ALT/archive/Sisyphus/2008/03/01/files/x86_64/RPMS
> > /ALT/archive/Sisyphus/2008/04/01/files/x86_64/RPMS
> > 
> > Методика тестирования следующая:
> > 1) Из каталогов парами выбираются файлы, у которых совпадает
> > имя пакета %{NAME}, но при этом не совпадает имя файла
> > %name-%version-%release.x86_64.rpm.
> > 2) Для каждой пары пакетов извлекается cpio архив и перепаковывается
> > с помощью rsyncable gzdio из нового rpmio.
> > 3) Отсекаются маленькие пакеты: оба перепакованных
архива должны быть
> > больше 32K.

Re: comprehensive rsyncability test

Перейду к инетпретации результатов тестирования.

1) Численный аспект тестирования отвечает на ворос,
какой объем нужно
скачать, чтобы синхронизировать новые x86_64 пакеты за
один месяц.

$ perl -le 'print "|".("-"x(2434968/2434968*78))."|"'       
|------------------------------------------------------------------------------|
таков общий объем новых файлов, пожатых гзипом.

$ perl -le 'print "|".("-"x(1643033/2434968*78))."|"'
|----------------------------------------------------|
столько скачал бы rsync, если новые И старые файлы пожать
в rsyncable deflate.

$ perl -le 'print "|".("-"x(1960275/2434968*78))."|"'
|--------------------------------------------------------------|
столько пришлось бы скачать, если новые файлы пожать
с помощью 'lzma -2'.

$ perl -le 'print "|".("-"x(1819361/2434968*78))."|"'
|----------------------------------------------------------|
столько пришлось бы скачать, если новые файлы пожать
с помощью 'lzma -5'.

Таким образом, численно rsync сохраняет преимущество,
но наглядная
интерпретация показывает, что LZMA перекрывает
большую часть выгоды,

Re: rpm: rsyncable deflate vs LZMA

Alexander Bokovoy пишет:
> 30 мая 2008 г. 14:44 пользователь Anton Farygin <rider <at> altlinux.com> написал:
>>> Но, в общем, хорошо иметь выбор, и этот выбор
становится всё менее
>>> гипотетическим.  Можно будет сделать какую-нибудь статистику,
>>> перекрывает ли экономия от rsyncability экономию от LZMA
или нет
_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: rpm: rsyncable deflate vs LZMA

Twas brillig at 04:33:31 01.06.2008 UTC+04 when Alexey Tourbin did gyre and gimble:

 >> В фортунки!

 AT> $ fortune -a -m rabelaisian
 AT> fortune: /usr/share/games/fortune/off: No fortune files in directory.
 AT> fortune:/usr/share/games/fortune/off not a fortune file or directory
 AT> zsh: segmentation fault  fortune -a -m rabelaisian
 AT> $

В багзиллу!

--

-- 
JID: dottedmag@... / dottedmag@...

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: comprehensive rsyncability test

Alexey Tourbin пишет:
> 3) Конечно, есть ещё один аспект проблемы.  LZMA даёт прямое
> преимущество, потому что уменьшение размера файла
напрямую влияет
> на объем для скачивания; а rsyncability даёт только косвенное/
> гипотетическое преимущество.  Чтобы преимущество
rsync могло
> реализоваться, должны быть выполнены три условия: у
пользователя есть
> старые файлы; старые файлы пожаты в rsyncable deflate; и пользователь
> правильно организовал процесс синхронизации.
> 
> Этот аспект проблемы трудно оценить численно, но он
является достаточно
> важным.
> 
> Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA"
> ни один из вариантов не имеет решающих преимуществ.

Скорее - для каждой категориии пользователей
преимущество будет 
очевидным в том или ином случае.

Мне было бы удобнее rsyncable deflate (для зеркалирования
Sisyphus). 
Тем, кто собирает или качает дистрибутивы - LZMA. Всем,
кто не знает про 
rsync - LZMA

Re: comprehensive rsyncability test

Twas brillig at 16:18:58 01.06.2008 UTC+04 when Anton Farygin did gyre and gimble:

 AF> Дим, можешь сказать, по каким протоколам у нас
больше тянут с сервера -
 AF> rsync или группа ftp + http?

Это будет некорректное сравнение - по умолчанию в
дистрибутивах-то ftp, а
умолчание можно всегда сменить.

-- 
JID: dottedmag <at> altlinux.org / dottedmag <at> jabber.dottedmag.net

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel

Re: comprehensive rsyncability test

Mikhail Gusarov пишет:
> Twas brillig at 16:18:58 01.06.2008 UTC+04 when Anton Farygin did gyre and gimble:
> 
>  AF> Дим, можешь сказать, по каким протоколам у нас
больше тянут с сервера -
>  AF> rsync или группа ftp + http?
> 
> Это будет некорректное сравнение - по умолчанию в
дистрибутивах-то ftp, а
> умолчание можно всегда сменить.

Подозреваю, что в случае с apt'ом нам rsync не поможет.

Более того - нагрузка на сервер будет выше, чем сейчас с ftp.

_______________________________________________
Devel mailing list
Devel <at> lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel