On Mon, Oct 6, 2014 at 4:46 PM, Jaroslav Reznik <jreznik@xxxxxxxxxx> wrote: > ----- Original Message ----- >> >> >> >> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: >> > On 6 October 2014 09:41, Rahul Sundaram <metherid@xxxxxxxxx> 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. I am not convinced that "being fast" and "download less" are mutually exclusive when using deltas. So we should keep deltas *and* make them faster. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
