----- 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. Jaroslav > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
