----- Original Message -----
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
> On 6 October 2014 09:41, Rahul Sundaram <metherid(a)gmail.com> wrote:
> > Hi
> >
> > One of the long standing features that were enabled by default in yum is
> > support for delta rpms. dnf developers have disabled this and I think
> > this
> > change deserves a broader discussion
> >
> >
https://bugzilla.redhat.com/show_bug.cgi?id=1148208
> >
>
> "I have an internet flatrate at 150 mbs, and downloading the full rpms
> is ALOT faster than the the work that the delta rpms requires."
>
> Wow. Good to see normal users are taken into account. The main
> argument from a distro point of view is reducing load on servers, but
> I don't know many people on 150Mbs either. Heck, I've just tested my
> work janet connection and that's <100Mbs in our office. At home 8Mbps
> is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit
> seconds, where the very slow transfer speed declines exponentially as
> the connection progresses.)
The deltarpms were meant to serve two purposes
1) (lesser) Address the needs of users in developing countries (where
Fedora is fairly popular) and bandwidth concerns are very considerable.
Many of these users have connections that are either metered or
extremely slow, so deltarpms provides a way to get the data to them more
economically. This of course can be handled with a non-default option,
so we can talk about making that more discoverable if we disable them by
default.
This is a good point but even in developing countries internet access is
getting better and better. A few years ago installation DVD was the only
way how to access Fedora repo. It's not requested anymore. But yeah, I do
not live there.
2) (Major) Deltarpms significantly (Kevin, can you comment with
numbers?) reduces the load on the Fedora update servers and mirrors,
thereby reducing hosting costs as well as increasing the efficiency of
the available bandwidth (since smaller downloads mean you will be tying
up the line for a shorter amount of time).
It would be nice to see if we can find ways to improve the performance
of the deltarpm reconstruction instead. Much of the time is spent on
compression/decompression tasks which *should* be massively parallel; we
should be able to speed this up by taking advantage of additional cores
(and hyperthreading) on the system, for example. Another option might be
not to bother recompressing the RPMs but instead just install an
uncompressed RPM (and possibly recompress it out of band if we needed to
keep it in the cache).
One idea - could we do some measurements in presto code? Aka remember
download speed for drpms, then try to rebuild a few drpms and compare
speed. If internet connection is significantly faster, offer full rpms
re-download. If not, continue with rebuild. I don't have really fast
net connection, just VDSL limited to 16 mbit due to distance from DSLAM
but still using older netbook - the first thing I had to do, was to disable
drpms. Same my wife's laptop - any bigger update means she can't really
work.
That's one option. And I agree delta rpms optimization would be great
first step.
Jaroslav