[РЕШЕНО]Чем лучше сжимать ядро и инитрамфс?

vasek
нужно лезти в doc и смотреть нюансы декомпрессии и чтения
возможно, что это дилетантство, но лично я решил это вопрос эмпирически - просто проверил, сколько времени на моей машине занимает распаковка/чтение initramfs с применением разных алгоритмов сжатия и без сжатия вообще
победил cat
ssd с одним разделом
/boot в корне (комп старый, без uefi)
Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad
GitHub , BitBuket
vasek
Это я к тому, что не все так просто, как в этих расчетах ........ и слепо верить им нельзя.
И не зря по дефолту используется gzip ......... все остальное требует тщательной проверки, а обычные методы расчета тут, думаю, не совсем будут верными ....... в смысле отражения истинного положения вещей ...
ну то понятно что "отражения истинного положения вещей" может отличатся и на это может влиять много факторов, мы же пытается с нашей точки зрения выделить наиболее существенные и понятные факторы влияющие на скорость загрузки "ядра и инитрамфс".

Думаю что тема малость разрослась :) ТС, если не ошибаюсь, изначально хотел просто самый быстрый компрессор, но а мы(точнее я) ушли в дебри и решаем какой не компрессор а способ загрузки "ядра и инитрамфс" будет самым быстрым.
Haron_Prime
ssd с одним разделом

Haron_Prime
победил cat

я бы удивился если бы было иначе :))
red
последняя табличка показывает на сколько будут варьироваться данные относительно чистой декомпрессии(например беря данные с той программы что ты выложил ранее)
думается мне что лучше посчитать относительное отклонение между (времени считывания + распаковка со скоростью 80м/с) и (времени считывания + распаковка со скоростью 160м/с), это будет более наглядно и уместно в данном случае.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Haron_Prime, всегда был противником самосборки ядра и аналогичных тем, а выгода 1-2с для меня ничто, все устраивает по дефолту
Просто долго читал, читал топик и решил внести некоторую сумятицу в эти расчеты .......
Ошибки не исчезают с опытом - они просто умнеют
nafanja
думается мне что лучше посчитать относительное отклонение между (времени считывания + распаковка со скоростью 80м/с) и (времени считывания + распаковка со скоростью 160м/с), это будет более наглядно и уместно в данном случае.


vasek
Просто долго читал, читал топик и решил внести некоторую сумятицу в эти расчеты .......
провокатор :))
red, ну вот, уже видно что отклонения лишние )))
а мы все считаем, хотя можно было остановиться и на "чтение файла + декомпрессия" )))
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
red, ну вот, уже видно что отклонения лишние )))
ничего там не лишнее :) всё очень наглядно показывает что отклонения при учете только декомпрессии относительно чтения и декомпрессии могут достигать намного больше чем +/-5%; то есть в данном случае учет только одного параметра при описании картины будет заметно менее точен чем при двух параметрах
red
то есть в данном случае учет только одного параметра при описании картины будет заметно менее точен чем при двух параметрах
совершенно верно.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
немного изменил чтобы было нагляднее

 
Зарегистрироваться или войдите чтобы оставить сообщение.