tips: 1. look for a local mirror - for reliability not speed. 2. if you get the chance, download the required binaries elsewhere and burn to CD. Copy to /usr/portage/distfiles so they are already present.
3. if you have a local rsync service, use that instead. For large files, copy the previous version over to the new name and rsync it. gains vary wildly, but in some cases can be very worthwhile. Also corrupted files seem to occur occasionally over http/ftp: rsync fixes them. However, rsync has an overhead on new files that can be unacceptable, so I experimented with setting resume to rsync, but it failed as portage does not seem to use smart URL service allocation. 4. there was a "delta" project going, but I havent heard of it for awhile (just updates differences) 5. bandwidth limit the connection, either in rsync or wget: --limit-rate=4k gives me ~1.5kb for surfing etc. As the rate limiting is very "chunky", this works well. Rsync can really choke a modem connection if there is little load on the far end. 6. use emerge -f to download all required files ahead of time and then build at once. While this seems like it will take the same time, it makes supervising the process easier and less troublesome I have a couple of machines including a laptop that I keep up to date at work. When I get home, the tar.bzips drain onto my main machine which nfs (though recently I had to serve via rsync due to network probs - bad cable somewhere) serve them out to the home network. One limitation that I have found is that portage leaves URL interpretation (http, ftp, rsync) up to the download application. So if you want to use either rsync, ftp or http, depending on what the mirror allows, you are out of luck. BillK On Wed, 2003-09-10 at 18:20, Joshua Banks wrote: > Hello, > > I was wondering if anyone had any tips on the use of emerge when emerging with a > ppp/dialup > connection. Any best practices with a dialup connection to use either help speed up > downloads or > at a minimum make the emerging process as efficient as possible would be helpful. > > Right now I have uncommented ACCEPT_KEYWORDS="~x86" in make.conf as a suggestion > from someone else > saying that this would allow me to get more of the dev packages. > > When I did a "emerege -uD world" I shouldn't of. > > There are 99 packages that are going to be emerged. I started yesterday and it is > now almost 24 > hrs. later and I've only downloaded and emerged 30 of those pkgs. > > So now I see that this is not only downloading and doing a -D "deep" but is > compiling as well then > going back out to grab the next pkg. > > Would it be smarter to do an "emerge -uDf world" so that I atleast get the needed > sources faster? > > After doing an "emerge -uDf world" and say I got all 99 files, what would be the > next thing I > should do? > > Where are those files kept so that I can view the list and what would be the command > to emerge > them in the order that they were downloaded? > > What happens if I've downloaded half of those files and and my internet connection > dies? Or I > decide that I don't want my ppp connection up for 5 days emerging files and want to > disconnect. Is > this safe? > > > > I live in Washington State so it seems that mirror at Oregon should be fine unless > somebody knows > of a beefier site in WA state. I did notice that I usually average a 4.2Kb to 4.5Kb > transfer rate > anytime that I'm downloading off the internet. But for some reason I've been > averging 2.5Kb to > 3.0Kb rates the last 24hrs when using emerge. Is this because the Oregon site is > getting hammered > or could this have something to do with the fact that I recompiled my kerenel to add > some > Netfilter modules? > > Is there anything that I can do to speed up downloads via ppp or at a minimum make > the process as > efficient as possible. > > Thanks for any suggestions. Much appreciated. > > JBanks > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > -- > [EMAIL PROTECTED] mailing list -- William Kenworthy <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
