[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Change proposal discussion - Optimize SquashFS Size
From:       David_Schwörer <david08741 () gmail ! com>
Date:       2020-02-04 9:08:53
Message-ID: 0b89de6b-f338-37a3-e61b-3ff44a85c517 () gmail ! com
[Download RAW message or body]

On 2/4/20 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 03, 2020 at 05:22:55PM +0100, Nicolas Mailhot via devel wrote:
>> Le 2020-02-03 17:11, David Cantrell a écrit  :
>>
>> Hi,
>>
>>> We want input from the community on what the main goal should be and
>>> prioritize the rest.  For example, is ISO reduction size more
>>> important than
>>> improving installation time, for instance?  If so, why?
>>
>> This is a nonsensical question
> 
> Great start for constructive discussion ;(
> 
>> without defining the target hardware and connectivity.
> 
>> Hardware with weak CPU (chromebook) and high connectivity (fiber)
>> will want as low compression as possible.
>>
>> Hardware with low connectivity or low storage (chromebooks, vms)
>> will want the highest possible compression; because I/O limits will
>> wipe out any CPU win, and dnf/packagekit caches get expensive fast.
>>
>> (chromebooks are problematic in all cases)
> 
> Right. We produce just one image that has to serve all of those cases,
> i.e. the hardware we are targeting is "the average" of all Fedora
> users. (Producing more than one image with different compression
> settings was briefly discussed also, but it seems that the storage of
> multiple images is too "costly" to justify this.)  That is why we talk
> about prioritization of goals: we need to pick something that handles
> all cases and the question is which characteristics matter most to
> users.

I think that is the wrong question. It is not a question which of the
three is most important, the question is rather, to what extend are we
willing to sacrifice one for the other.

As storage has different units than installation time, they are
inherently not comparable. We should thus come up with a metric to make
them comparable.

The obvious way to make them comparable is by multiplying size by
"download speed" [MB/s]. Thus if we can agree on a speed, they are
comparable, and we can get closer to a solution.

However, the time it takes to install isn't a reproducible, well defined
quantity, but depends on the device. A way forward is to take an average
over several systems. The arithmetic average (sum all up, divide by n =
number of samples) will give skewed results towards the slowest device.
I think geometric average (multiply all, take the n-th root) could be
useful.


So if we choose this approach, which IMHO puts the discussion now on a
more technical ground, and allows to quantify how much speed we are
willing to sacrifice for size or vice versa, we need to choose:

a) Constant to convert size to speed
b) List of test systems

Concerning a)
We could again take the geometric average of several connection.

Concerning b)
Maybe 4 test systems:
high-end system with ssd (both install source and target) and high-end cpu
medium system 1: good usb drive + target ssd, medium cpu
medium system 2: cheap usb drive + target hdd, medium cpu
slow system: something like a chromebook


I have ignored composition time, because the end user does not care in
most cases. As long as it composes in a reasonable time frame, most
users don't care.

I would thus suggest trying to optimize the above to, and restrict the
possible to options, so that compose is still acceptable.

David

> 
> Zbyszek
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]