быстро передать образ по сети

ssd почти в четыре раза быстрее гигабита.

не факт, что у тебя получится сжать свои данные в 4 раза. У меня не получается.

В данном случае упирается всё в гигабит (в идеале) и в запись на том винте. Поэтому сжатие имеет смысл для обоих вариантов.

в этом - возможно. Тебе конечно виднее.

Вот смотри как оно у меня:

# dd if=/dev/sda6 of=/dev/null bs=16M
715+1 записей получено
715+1 записей отправлено
 скопировано 12000651264 байта (12 GB), 35,5351 c, 338 MB/c

# dd if=/dev/sda6 bs=16M | gzip -1 | dd of=/dev/null bs=16M
715+1 записей получено
715+1 записей отправлено
 скопировано 12000651264 байта (12 GB), 259,891 c, 46,2 MB/c
0+258013 записей получено
0+258013 записей отправлено
 скопировано 4230791398 байт (4,2 GB), 259,892 c, 16,3 MB/c

Мою правоту (то, что не в cpu дело) подтверждает то, что загрузка примерно по 50% на каждое ядро из двух (попробуй, как оно у тебя). Слишком много штрафных тактов…

Я хоть смог убедить тебя что есть смысл в сжатии?

у тебя на принимающей стороне места нет. потому - в твоём случае - да. В других - не знаю.

Да. И я вижу ещё что в момент тормозов скорость на ssd падает до 0.5 метра в секунду на запись (сам в шоке).

есть у них такая болезнь. Даже на флешках. И у меня тоже так тупит. Но таки это не ощущается. 3.7.1 #2 SMP конфиг от Патрика.

Диск sandisk i100 распаяный на мамке. Да, это полное Г, но это не значит что приложения должны вешаться минут на пять при обновлении системы. Я создам тред на эту тему. Пока мучает вот эта проблема:

про диск - что-то с контроллером/мамкой. про проблему - не знаю.

ты для чего это написал?

потому-что 95% идиоты. Как думаешь, кто написал 95% постов в этих ваших интернетах? И ты что-то ИМИ пытаешься доказать? Более конструктивно опрос здесь устроить, на ЛОРе хоть тупых блондинок не слишком много.

но вот скорость МЕНЬШЕ - всего 46.2МБс.

Это в один поток. Теперь бьём исходный файл, скажем, на несколько частей и каждую сжимаем и передаём отдельно. Я думаю 8 имеющихся ядер вполне хватит чтобы в разы улучшить этот результат, пусть даже и не в 8 раз.

потому-что 95% идиоты

Окей. Не знаю вхожу ли я в эти 95%, но выбор алгоритма шифрования у меня сильно влияет при scp. По дефолту у меня не поднималось выше 40-50 метров в секунду на моём десктопе. С arcfour всё упёрлось в сеть.

Окей. Не знаю вхожу ли я в эти 95%, но выбор алгоритма шифрования у меня сильно влияет при scp. По дефолту у меня не поднималось выше 40-50 метров в секунду на моём десктопе. С arcfour всё упёрлось в сеть.

шифрование подразумевает и сжатие, а вместе со сжатием сильно падает скорость. Т.ч. надо пробовать, а не рассуждать. Само шифрование - достаточно лёгкий процесс, хотя многие считают иначе (не знаю почему считают. Власти скрывают?)

Я думаю 8 имеющихся ядер вполне хватит чтобы в разы улучшить этот результат, пусть даже и не в 8 раз.

а вот ты не думай, а попробуй. Только нули сжимать не нужно. Сжимай что-то другое. В моих опытах, хоть 1 ядро, хоть 8 - разницы нет. Причём IRL лучше одно, а остальные 7 ядер пригодятся другим процессам, дабы сжатие было в фоне и никому не мешало.

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

шифрование подразумевает и сжатие

это где такое написано?

само шифрование - достаточно лёгкий процесс, хотя многие считают иначе (не знаю почему считают. Власти скрывают?)

наверно потому что тут в треде кто-то даже шелл-снипет написал для измерения скорости?

Только нули сжимать не нужно. Сжимай что-то другое

сжимаю /dev/sda

А дают-ли они выигрыш в скорости? Не хочу быть категоричным, но похоже, что быстрее - не будет.

Казалось бы, есть куча тестов и бенчмарков всяких pbzip2, pxz итп, ан нет, drBaty всё мало, «лгут ваши интернеты».

это где такое написано?

где-то на первых страницах любого учебника по криптоанализу. Ну вспомни, как Холмс вскрыл шифр «пляшущие человечки», и что-бы он делал, если-бы энтропия всех символов была бы одинаковой?

Задача сжатия и задача криптоаналитика одинаковые - найти зависимости в файле, потому перед шифрованием файл всегда сжимают, дабы исходник для шифрования содержал белый шум, в котором каждый бит независим от всех остальных, и его энтропия в точности ½. Сжиматель как раз этим и занимается - если энтропия какого-то бита меньше ½, то он записывает этот бит меньшим числом битов.

Что-бы это понять, посмотри на файл /dev/zero? Какова энтропия(ценность) каждого бита? Очевидно 0, ибо мы и так знаем, какие там биты. А стало быть, ценность всего файла тоже почти 0, вместо записи этого файла нам достаточно сказать: «мы взяли 100500 битов из /dev/zero», и реципиент в точности восстановит исходник.

А теперь подумай, что произойдёт, если Алиса снимет себя своей фоткой, и поXORит ей /dev/zero? Сможем-ли мы взломать её шифр? Очевидно - сможем, ибо глядя на фотку мы всё поймём. А если она фоткой сожмёт белый шум? Очевидно - нет, ибо мы, злоумышленники, увидим только белый шум. Не такой как в оригинале. Но белый шум всегда одинаково выглядит, что-бы им не XORили. Ибо каждый бит в нём имеет максимально возможную стоимость ½.

В итоге, если алгоритм сжатия идеален, мы можем использовать _ЛЮБУЮ_ схему шифрования, даже очень простую, и очень слабую.

Единственное, что нужно сделать - убрать всякие заголовки и прочую служебную информацию из архива, ибо используя её злоумышленник может успешно взломать наш файл атакой по открытому тексту (ибо служебная информация известна и/или её можно предсказать). Потому использовать gzip|ssh нельзя, а нужно использовать просто ssh, которая использует zlib, и никаких заголовков НЕ добавляет. Ну и кроме того, если ssh уже использует сжатие, то второй раз сжимать не нужно, ибо сжатый файл не сжимается.

наверно потому что тут в треде кто-то даже шелл-снипет написал для измерения скорости?

ну и что? дефрагментатор для EXT4 тоже есть, и не один. Что это доказывает?

сжимаю /dev/sda

Ну если у тебя SSD, если там свободное место, и если TRIM работает так, как я думаю, то сжатие будет из-за фонового стирания SSD, которое пишет 0x00 или 0xFF. И то и другое отлично жмётся. /usr тоже жмётся, ибо программы невыгодно хранить в сжатом виде. Особенно в Linux, где их надо часто и много запускать.

А вот что у тебя там кроме программ и пустоты - я не знаю.

Казалось бы, есть куча тестов и бенчмарков всяких pbzip2, pxz итп, ан нет, drBaty всё мало, «лгут ваши интернеты».

ну я, блин, выше сам тест проводил. Перепроверь.

Только /dev/sda не надо, оно меняется, причём ещё и само по себе. Возьми какой-нить файл, скажем linux-source.tar, ну и сожми. Меня результат как-то не вдохновил.

вот что пишет автор xz в мане:

      -T threads, --threads=threads
              Specify  the number of worker threads to use.  The actual number of threads can be less than threads if using more
              threads would exceed the memory usage limit.

              Multithreaded compression and decompression are not implemented yet, so this option has no effect for now.

              As of writing (2010-09-27), it hasn't been decided if threads will be used by default on  multicore  systems  once
              support  for  threading  has  been implemented.  Comments are welcome.  The complicating factor is that using many
              threads will increase the memory usage dramatically.  Note that if multithreading will be  the  default,  it  will
              probably  be  done  so  that single-threaded and multithreaded modes produce the same output, so compression ratio
              won't be significantly affected if threading will be enabled by default.

тоже «неосилятор»?

Я взял первый гиг своего корня, скопировал в /tmp/input. Потом разбил на чанки по одному метру и пожал в несколько потоков питоновским lzma в формат xz. Результаты: в один поток 1m58.196s, в два за 1m17.570s, в четыре (тут уже используетсяht): real 1m1.030s. Камень i7-3517. Размер на выходе 571 метр. Многопоточное архивирование? GIL? Не, не слышал.

Теперь что выдал xz:

3$ time xz -0 /tmp/input 

real	1m58.160s
user	1m57.410s
sys	0m0.510s$ ls -lah /tmp/input.xz 
-rw-r--r-- 1 loh loh 570M Mar  5 10:17 /tmp/input.xz

Проблемы криптографии я не буду обсуждать пока с этим не закончим.

пытался померять, сходу непонятно. Поэтому я тупо оставил копирование пока обедал. Сейчас уже всё скопировалось, проверять не хочется.

А жаль, было бы интересно. Я когда делал бэкап с ноута на core-i2xxx на USB2-винт (всего около 28 МБ/с запись), тоже думал, если сжимать, будет быстрее. Оказалось наоборот.

lzop, я думаю, поможет. Он у меня жмёт со скоростью чуть ли не со скоростью 430 метров в секунду. На странице автора можно посмотреть как его распаралелить консольными утилитками. Первый гиг корня он зажал в 606 метров. Результат не ахти, но ускорение будет.

Интересно, спасибо. Хотелось, чтоб хотя бы не медленнее было. Попробую.