Gentoo Archives: gentoo-performance

From: Cory Grunden <cory.grunden@×××××.com>
To: gentoo-performance@l.g.o
Subject: [gentoo-performance] Re: Digest of gentoo-performance@gentoo.org issue 6 (32-61)
Date: Mon, 23 Jan 2006 20:59:31
Message-Id: 177b81ff0601231256v4666ef73s2771324ad006cf21@mail.gmail.com
Shouldn't you be using sdparm, and not hdparm for your sata drives?

On 1/23/06, gentoo-performance+help@g.o <
gentoo-performance+help@g.o> wrote:
> > Topics (messages 32 throught 61): > > [gentoo-performance] > 32 - ??? <bolotov-bag@×××××××.ru> > > [gentoo-performance] gentoo-performance > 33 - Ken Robbins <gatliffe@×××××.com> > > [gentoo-performance] gentoo-performance > 34 - lnxg33k <lnxg33k@×××××.com> > > [gentoo-performance] gentoo-performance > 35 - Chris <chris@×××××××××××.net> > > [gentoo-performance] gentoo-performance > 36 - lnxg33k <lnxg33k@×××××.com> > > [gentoo-performance] gentoo-performance > 37 - Alex Efros <powerman@××××××××××××××××××.com> > > [gentoo-performance] gentoo-performance > 38 - Kyle Lutze <kyle@×××××××××××.com> > > [gentoo-performance] gentoo-performance > 39 - Christopher Bergström <cbergstrom@×××××××××.com> > > [gentoo-performance] gentoo-performance > 40 - Jeremy Brake <gentoolists@×××××××××××.nz> > > [gentoo-performance] gentoo-performance > 41 - lnxg33k <lnxg33k@×××××.com> > > [gentoo-performance] gentoo-performance > 42 - darren kirby <bulliver@×××××××××××.org> > > [gentoo-performance] gentoo-performance > 43 - Michael Liesenfelt <mliesenf@×××××××××.edu> > > [gentoo-performance] gentoo-performance > 44 - Christopher Bergström <cbergstrom@×××××××××.com> > > [gentoo-performance] gentoo-performance > 45 - Alec Warner <warnera6@×××××××.edu> > > [gentoo-performance] gentoo-performance > 46 - Jeremy Brake <gentoolists@×××××××××××.nz> > > [gentoo-performance] gentoo-performance > 47 - darren kirby <bulliver@×××××××××××.org> > > [gentoo-performance] unsubscribe > 48 - "Matthew Coulson" <MCoulson@××××××××××××××××××××××××.uk> > 53 - Alden Huang <alden.huang@×××××.com> > 55 - Geisel Sierote <geisel@×××××××.br> > > [gentoo-performance] gentoo-performance > 49 - Bill Roberts <billbalt@×××××××××××××.com> > > [gentoo-performance] gentoo-performance > 50 - Christopher Bergström <cbergstrom@×××××××××.com> > > [gentoo-performance] gentoo-performance (sync speedups) > 52 - lnxg33k <lnxg33k@×××××.com> > > [gentoo-performance] gentoo-performance@l.g.o > 54 - checl <check@×××××××××.cx> > > [gentoo-performance] How to unsubscribe > 56 - Oopsz <oopsz@××××××××××.com> > > [gentoo-performance] gentoo-performance (sync speedups) > 57 - Alec Warner <warnera6@×××××××.edu> > > [gentoo-performance] gentoo-performance (sync speedups) > 58 - lnxg33k <lnxg33k@×××××.com> > > [gentoo-performance] How to get Maximum performance in Graphics on Nvidia > Drivers > 59 - XFry <xfry@××××××.ru> > > > > > > > Hi my first gentoo performance came today but it way only a header no body > what up with that? > > > *Powered by Gentoo Linux* > Anything free is worth saving up for-Shadow the cat > > ------------------------------ > Yahoo! Photos > Ring in the New Year with Photo Calendars<http://us.rd.yahoo.com/mail_us/taglines/photos/*http://pa.yahoo.com/*http://us.rd.yahoo.com/mail_us/taglines/photos/evt=38087/*http://pg.photos.yahoo.com/ph//page?.file=calendar_splash.html&.dir=>. > Add photos, events, holidays, whatever. > > > Ken Robbins wrote: > > Hi my first gentoo performance came today but it way only a header no > body what up with that? > > > <snip> > > Mine too and I've been listening for a while. I think this ML may be dead > ... > *pokes the darkness* > -- > gentoo-performance@g.o mailing list > > funny that a "high performance linux" has a dead performance ML... LOL > > > lnxg33k wrote: > > > Ken Robbins wrote: > > > >> Hi my first gentoo performance came today but it way only a header no > >> body what up with that? > > > > <snip> > > > > Mine too and I've been listening for a while. I think this ML may be > > dead ... *pokes the darkness* > > -- > gentoo-performance@g.o mailing list > > Chris wrote: > > funny that a "high performance linux" has a dead performance ML... LOL > <snip> > > Could be evidence that the "ricer" crowd doesn't read? (i.e. they post to > more > generic lists or use other mediums instead of something specific for their > needs) > -- > gentoo-performance@g.o mailing list > > Hi! > > On Fri, Jan 20, 2006 at 03:30:29AM +0100, Chris wrote: > > > Mine too and I've been listening for a while. I think this ML may be > > > dead ... *pokes the darkness* > > funny that a "high performance linux" has a dead performance ML... LOL > > It isn't dead because a lot of attentive listeners subscribed to it... :-) > > -- > WBR, Alex. > -- > gentoo-performance@g.o mailing list > > lnxg33k wrote: > > Chris wrote: > > > >> funny that a "high performance linux" has a dead performance ML... LOL > > > > <snip> > > > > Could be evidence that the "ricer" crowd doesn't read? (i.e. they post > > to more generic lists or use other mediums instead of something specific > > for their needs) > > Time to throw in a performance info post. > > Has anybody done any tests on the different between the one core and > dual core opteron processors? I currently have an opteron 242 and a gig > of ram on a tyan mobo, and I'm curious as to which would allow me to > compile programs faster, as I lend the systems out to a lot of groups > that have slow systems > > Kyle > -- > gentoo-performance@g.o mailing list > > lnxg33k wrote: > > > Chris wrote: > > > >> funny that a "high performance linux" has a dead performance ML... LOL > > > > <snip> > > > > Could be evidence that the "ricer" crowd doesn't read? (i.e. they post > > to more generic lists or use other mediums instead of something > > specific for their needs) > > Since we're all here and saying hello.. Someone have a performance > question or a good tip to add to the list? > > The one thing that first pops to my head is some hdparm results I've had > and if maybe it's either my kernel setup or how I'm testing with hdparm... > > Anyhow.. > > Raptors on SATA (Model Number: WDC WD360GD-00FNA0) (-c3 -u1 -A1 > -W1 -d1 -a256 -M254 -m16 -X70 ) > Kernel config > CONFIG_SCSI_SATA_SIL=y > > There's an alternative driver, but haven't tested it... > > hdparm -tT /dev/hde > > /dev/hde: > Timing cached reads: 956 MB in 2.00 seconds = 477.02 MB/sec > Timing buffered disk reads: 116 MB in 3.03 seconds = 38.26 MB/sec > > hdparm -tT --direct /dev/hde > > /dev/hde: > Timing O_DIRECT cached reads: 244 MB in 2.01 seconds = 121.26 MB/sec > Timing O_DIRECT disk reads: 124 MB in 3.01 seconds = 41.17 MB/sec > > Laptop 7k60 (Model Number: HTS726060M9AT00) > hdparm -tT /dev/hdc > > /dev/hdc: > Timing cached reads: 1980 MB in 2.00 seconds = 989.94 MB/sec > Timing buffered disk reads: 118 MB in 3.04 seconds = 38.81 MB/sec > > > hdparm -tT --direct /dev/hdc > > /dev/hdc: > Timing O_DIRECT cached reads: 364 MB in 2.02 seconds = 180.54 MB/sec > Timing O_DIRECT disk reads: 120 MB in 3.04 seconds = 39.42 MB/sec > > > I also can't set the raptors into UDMA6 tried -X70 with no luck.. > > Any suggestions? > > Thanks > > C. > -- > gentoo-performance@g.o mailing list > > How about speeding up the wait time on updating the portage cache after > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > through.. > are there any known ways to "vrrmmm" this up a little? > > Jeremy > -- > gentoo-performance@g.o mailing list > > Jeremy Brake wrote: > > How about speeding up the wait time on updating the portage cache after > > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > > through.. > > are there any known ways to "vrrmmm" this up a little? > > > > Jeremy > > Although not exactly what you're asking, you might want to look at > RSYNC_EXCLUDEFORM. Cuts down on what is checked during rsync. I assume > that > this could also cut down on the cache update time since there would be > less to > check? Also cuts down on the amount of space eaten up by portage. > -- > gentoo-performance@g.o mailing list > > quoth the Jeremy Brake: > > How about speeding up the wait time on updating the portage cache after > > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > > through.. > > are there any known ways to "vrrmmm" this up a little? > > +1 > > Mine sped up for all of a day, but is slow as molasses once again. If I > did my > syncs during the day it might even peeve me... > > > Jeremy > > -d > -- > darren kirby :: Part of the problem since 1976 :: http://badcomputer.org > "...the number of UNIX installations has grown to 10, with more > expected..." > - Dennis Ritchie and Ken Thompson, June 1972 > > > lnxg33k wrote: > > > Although not exactly what you're asking, you might want to look at > > RSYNC_EXCLUDEFORM. Cuts down on what is checked during rsync. I assume > > that this could also cut down on the cache update time since there > > would be less to check? Also cuts down on the amount of space eaten up > > by portage. > > > I'll second RSYNC exclusions. It really does speed up syncing especially > on headless servers which don't need x11-*/*. > > -- > Michael Liesenfelt > University of Florida > Innovative Nuclear Space Power and Propulsion Institute > > > > darren kirby wrote: > > quoth the Jeremy Brake: > > How about speeding up the wait time on updating the portage cache after > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > through.. > are there any known ways to "vrrmmm" this up a little? > > +1 > > Mine sped up for all of a day, but is slow as molasses once again. If I did my > syncs during the day it might even peeve me... > > What kind of hardware are you guys running on? My laptop isn't on cron > and I do it every couple days or so and it finishes in around 15-30 > minutes.. I've never really paid any attention.. How long is yours taking? > > What I am curious about is... what's it really doing when it says 51-52%.. > That 1% seems to take forever.. > > C. > -- gentoo-performance@g.o mailing list > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeremy Brake wrote: > > How about speeding up the wait time on updating the portage cache after > > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > > through.. > > are there any known ways to "vrrmmm" this up a little? > > > > Jeremy > > Well the current problem is that in the 2.0 portage branch the cache > code sucks. This is fixed in ~arch portage ( the 2.1_pre series ). For > you users that don't want to upgrade to unstable, you should be able to > use cdb to speed up the process. > > Setting RSYNC_EXCLUDES will not speed up the second half of the --sync ( > the --metadata portion ). > > Explanation: The Portage Tree has a ton of ebuilds in it, when you do > something like emerge -pv <blar> portage used to have to go read each > ebuild and be like "oh what are the USE flags, the dependencies, etc.." > This takes a lot of time, especially for something like emerge -uD world > that may touch thousands of packages. > > So to mitigate this issue portage has a "metadata cache" where it stores > the ebuild metadata so it doesn't have to source each ebuild every time. > This gives performance increases ( reportedly ) of 100x speed-ups. > > However, generating the metadata is time consuming, even on decent > hardware it will probably take 30-45 minutes. To not piss the users > off, Gentoo calculates this metadata serve-side and serves it to you > during sync. > > The Rsync portion of emerge --sync is pretty much everything before the > "updating metadata cache". This should be pretty standard as far as > time goes on all boxes. However the second portion is where portage has > to take the generated server-side cache and kind of "meld" it into your > already existant local cache ( stored in /var/cache/edb/dep for those of > you whom are curious ). This didn't used to take a bunch of time..until > KDE split their packages from KDE-monolith to KDE-meta. The X.org > switch probably won't help much in this area either. Particularly the > slowdown at 50-52% is due to this portion of the tree. > > There is a new cache system in the 2.1 branch of portage, or using cdb, > or perhaps even an sqlite back-end (patches and modules are out there), > will help until such time as the 2.1 branch is stablized ( probably not > too soon ). > > - -Alec Warner (antarus) > > Disclaimer: I'm not a developer (yet) but I've worked with the portage > team for some time. Release dates, features, and other things are not > gauranteed to be correct just because I said so :) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQIVAwUBQ9CExWzglR5RwbyYAQLJEhAAj7i2cRVgv1iBfi61mGkn9q1t/K5JEJcv > zK07bTmMDirviessdKiZVSufXdWV79tW0MDEVqmGI9t+V+uwM77aFbge1VSkEaQB > RWetuQL8tQRUX1KvQ+ItScVtbqKIAQe/Jn+BwSim05jF3+fF15Z6EpPPKypNLQxK > 2ef/bcJ91Gctv0xcd6j943uOPFDCt05Ahe06/pQ0wgGdnAcKLOy/RVwDOVfprXim > AwiVsU4aCxRI056RkEj1VuSwSYQEa91WKpTGv81lZVkRW8LRxkgc7UAydMYGjOY5 > 1prjv2Koyly5ycVvxshKVmLfuaqByY9bBnlklyKDdFW1ZD1udCflCLxmz3GuTCsm > /FHce+Y9smqq3sF1wV7DYXu9vTnLdBqVBlDq4cEtd5XdgQm3TJ5rUGF2Mepicyhg > Bg4ibDExDB5eKWCnGU3ioSCd8TY9cdR9ZXxpm6JLGfr9ztog0/vScsIZbj3dS4RH > WqGklvW0F9N6NjP26WJwtQsmSIZpSJU4yPxneZOdQxGOUfdNPQap+qO+rZaitPKW > yWaikaiSuecPSul0ithpGnCFttPHrBLyNKNl7aom04Bht4KSdaqzriIL/RylWzHW > OgazUV9RuVdI8oEx+q3zKzOgvG3dXeL7HNdhH+j9noIyGVa8ouNHWMGfFUc1baxV > 7eyB1buSeQY= > =vWqe > -----END PGP SIGNATURE----- > -- > gentoo-performance@g.o mailing list > > Alec Warner wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Jeremy Brake wrote: > > > > > >>How about speeding up the wait time on updating the portage cache after > >>a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > >>through.. > >>are there any known ways to "vrrmmm" this up a little? > >> > >>Jeremy > >> > >> > > > >Well the current problem is that in the 2.0 portage branch the cache > >code sucks. This is fixed in ~arch portage ( the 2.1_pre series ). For > >you users that don't want to upgrade to unstable, you should be able to > >use cdb to speed up the process. > > > >Setting RSYNC_EXCLUDES will not speed up the second half of the --sync ( > >the --metadata portion ). > > > >Explanation: *snip* > > > > > Thanks Alec, thats a really awesome explaination :) > > My server runs a 5am script which does this, so i'm not too worried > about that machine. For those who are curious, its an Athlon 1800+ on a > 10Mbit link, and it takes between 1 and 10 mins to process " emerge > --sync --quiet; emerge -upvD world; glsa-check -t all " > > My home pc is on a 2Mbit link, so I only sync when i feel like checking > for updates, or when I want to install something new. This will take > minimum of 10 mins just to update the cache most times, sometimes more. > Being a home pc, I'm happy to have some unstable stuff installed. How > messy would it be to just run ~amd64 portage? would this work, or do I > ideally need to make the entire base system ~amd64? (ugh). > > Jeremy > > > -- > gentoo-performance@g.o mailing list > > quoth the Christopher Bergström: > > darren kirby wrote: > > quoth the Jeremy Brake: > > > > How about speeding up the wait time on updating the portage cache after > > a sync.. even on my AMD 64 3500 it takes a number of minutes to chug > > through.. > > are there any known ways to "vrrmmm" this up a little? > > > > > > +1 > > > > Mine sped up for all of a day, but is slow as molasses once again. If I > did > > my syncs during the day it might even peeve me... > > > > What kind of hardware are you guys running on? My laptop isn't on cron > > and I do it every couple days or so and it finishes in around 15-30 > > minutes.. I've never really paid any attention.. How long is yours > taking? > > It doesn't make a difference what hardware. I have 4 boxes that run gentoo > (Athlon 2200, Athlon 3200, Apple G4, Sparc U60) and they all run the > actual > sync quite fast, but the 50%-51% takes from 5 minutes on the 3200 to 30 > minutes on the G4 and U60. > > As I mentioned though, I don't let this bother me as I generally sync > ~4:00am > whilst sleeping. > > > What I am curious about is... what's it really doing when it says > 51-52%.. > > That 1% seems to take forever.. > > > > C. > > -- gentoo-performance@g.o mailing list > -d > -- > darren kirby :: Part of the problem since 1976 :: http://badcomputer.org > "...the number of UNIX installations has grown to 10, with more > expected..." > - Dennis Ritchie and Ken Thompson, June 1972 > > > unsubscribe > > _____________________________________________________________________ > Please Note: This e-mail is confidential and may be protected by law. > This e-mail is intended solely for the named recipient(s). If you receive > this e-mail in error, please destroy the copy in your possession > immediately. Please do not disclose the contents to any other person, use > information contained in it for any purpose, store or copy it. Although > this e-mail and any attachments are believed to be free of any virus, which > might affect a computer system into which it is received and opened, Express > Reinforcements Ltd. can not guarantee this and does not accept > responsibility for any damage resulting from the use of this e-mail. > Copyright in this e-mail and any attachments remains with us. Express > Reinforcements Ltd. Registered in England No.1808624. Head Office: > Fordwater Trading Estate, Ford Road, Chertsey, Surrey KT16 8HG > To Visit our website go to http://www.ExpressReinforcements.co.uk > > This message has been checked for all known viruses by UUNET delivered > through the MessageLabs Virus Control Centre. For further information > visit > http://www.uk.uu.net/products/security/virus/ > > -- > gentoo-performance@g.o mailing list > > > > > The one thing that first pops to my head is some hdparm results I've had > > and if maybe it's either my kernel setup or how I'm testing with > hdparm... > > > > Anyhow.. > > > > Raptors on SATA (Model Number: WDC WD360GD-00FNA0) (-c3 -u1 -A1 > > -W1 -d1 -a256 -M254 -m16 -X70 ) > > Kernel config > > CONFIG_SCSI_SATA_SIL=y > > > > There's an alternative driver, but haven't tested it... > > > > hdparm -tT /dev/hde > > > > /dev/hde: > > Timing cached reads: 956 MB in 2.00 seconds = 477.02 MB/sec > > Timing buffered disk reads: 116 MB in 3.03 seconds = 38.26 MB/sec > > > Your times for the raptor seem awfully slow. > > Here the SATA settings for my kernel and my hdparm times. > > antec ~ # grep SATA /usr/src/linux/.config > # CONFIG_BLK_DEV_IDE_SATA is not set > CONFIG_SCSI_SATA=y > CONFIG_SCSI_SATA_AHCI=y > # CONFIG_SCSI_SATA_SVW is not set > # CONFIG_SCSI_SATA_MV is not set > # CONFIG_SCSI_SATA_NV is not set > # CONFIG_SCSI_SATA_QSTOR is not set > # CONFIG_SCSI_SATA_PROMISE is not set > # CONFIG_SCSI_SATA_SX4 is not set > # CONFIG_SCSI_SATA_SIL is not set > # CONFIG_SCSI_SATA_SIL24 is not set > # CONFIG_SCSI_SATA_SIS is not set > # CONFIG_SCSI_SATA_ULI is not set > # CONFIG_SCSI_SATA_VIA is not set > # CONFIG_SCSI_SATA_VITESSE is not set > CONFIG_SCSI_SATA_INTEL_COMBINED=y > antec ~ # hdparm -tT /dev/md0 > > /dev/md0: > Timing cached reads: 2776 MB in 2.00 seconds = 1387.91 MB/sec > Timing buffered disk reads: 398 MB in 3.00 seconds = 132.48 MB/sec > antec ~ # > > Note that this is a RAID0 with two disks, so the buffered disk read time > is double what you should expect on a normal install. > > Good luck. > > Bill Roberts > > > Bill Roberts wrote: > > The one thing that first pops to my head is some hdparm results I've had > and if maybe it's either my kernel setup or how I'm testing with hdparm... > > Anyhow.. > > Raptors on SATA (Model Number: WDC WD360GD-00FNA0) (-c3 -u1 -A1 > -W1 -d1 -a256 -M254 -m16 -X70 ) > Kernel config > CONFIG_SCSI_SATA_SIL=y > > There's an alternative driver, but haven't tested it... > > hdparm -tT /dev/hde > > /dev/hde: > Timing cached reads: 956 MB in 2.00 seconds = 477.02 MB/sec > Timing buffered disk reads: 116 MB in 3.03 seconds = 38.26 MB/sec > > Your times for the raptor seem awfully slow. > > Here the SATA settings for my kernel and my hdparm times. > > antec ~ # grep SATA /usr/src/linux/.config > # CONFIG_BLK_DEV_IDE_SATA is not set > CONFIG_SCSI_SATA=y > CONFIG_SCSI_SATA_AHCI=y > # CONFIG_SCSI_SATA_SVW is not set > # CONFIG_SCSI_SATA_MV is not set > # CONFIG_SCSI_SATA_NV is not set > # CONFIG_SCSI_SATA_QSTOR is not set > # CONFIG_SCSI_SATA_PROMISE is not set > # CONFIG_SCSI_SATA_SX4 is not set > # CONFIG_SCSI_SATA_SIL is not set > # CONFIG_SCSI_SATA_SIL24 is not set > # CONFIG_SCSI_SATA_SIS is not set > # CONFIG_SCSI_SATA_ULI is not set > # CONFIG_SCSI_SATA_VIA is not set > # CONFIG_SCSI_SATA_VITESSE is not set > CONFIG_SCSI_SATA_INTEL_COMBINED=y > antec ~ # hdparm -tT /dev/md0 > > /dev/md0: > Timing cached reads: 2776 MB in 2.00 seconds = 1387.91 MB/sec > Timing buffered disk reads: 398 MB in 3.00 seconds = 132.48 MB/sec > antec ~ # > > Note that this is a RAID0 with two disks, so the buffered disk read time > is double what you should expect on a normal install. > > I guess I should add that 2nd disk in there then.. Anyhow, I'm bound to > what appears to be a not-so-friendly controller.. > > CONFIG_SCSI_SATA_SIL is not set > > I'm going to change the sata_sil.c file to enable UDMA6 and I've seen some > other minor patches as well.. If it all proves stable.. Maybe someone will > actually get it sent upstream. What's further.. I'm on hardened.. So I think > you might have some kernel config options I don't have.. I have to look > again.. > > Cheers, > > C. > -- gentoo-performance@g.o mailing list > Thanks Alec Warner for the great explanation. It still seems like by not > having > portions of the tree by using EXCLUDEFORM and deleting the local dirs that > you'd save some time in the --metadata part of sync as less ebuilds are > available to be checked. Is this simply a wrong misconception? > -- > gentoo-performance@g.o mailing list > > > -- > gentoo-performance@g.o mailing list > > > -- > gentoo-performance@g.o mailing list > > unsubscribe > > > > Okay guys, stop mailing "unsubscribe" to the list. Instead, send a > blank message to gentoo-performance+unsubscribe@l.g.o > > alright? > -- > gentoo-performance@g.o mailing list > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > lnxg33k wrote: > > Thanks Alec Warner for the great explanation. It still seems like by not > > having portions of the tree by using EXCLUDEFORM and deleting the local > > dirs that you'd save some time in the --metadata part of sync as less > > ebuilds are available to be checked. Is this simply a wrong > misconception? > > The portion that "updates metadata cache" has nothing to do with what > ebuilds are in the tree. It simply takes the server-side caches ( > pregenerated ) and sync them into your local cache. You could RSYNC > exclude the whole tree and this will still happen for every package, > since the metadata is generated on the server ( and the server has the > whole tree ). > > Now if you were to rsync exclude metadata/ you would reduce the > - --metadata portion...because it wouldn't happen ;) > > - -Alec Warner (antarus) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQIVAwUBQ9GCJ2zglR5RwbyYAQLajw/+Mvfu9+0Sfo8nHo7gbNytHRNL1jVI61RD > /EIiZZwV067X77IP72o0Y7SICRvnooEqtLvQW+rd2c/Kb6W4EtDga94X8EbOrHIm > 0/IFqg7OqUa/psU6IkaPk959u7UJTnqlWmzluLbqRTx/X03lpjk6n+V4BOTRhcTA > WHa80quSpd5EkfdFAJ1oWVMn9ck7xSTn3ulzmlznCkLdWK6iR+m+r+wAWMPlcRFG > xE/Ik5uMVemlWuAElhMoB4xr/2hKfcsu/Egw9F+zVL5+3mGMyygHhELAvTVHU/C9 > jLX3noNFC+xSOesmC0e+l88Uyz2AYPuhg8S+3qciC+4Ax2QkDhhRxwM7lLF6yPBx > UpDNnTecT1iVuFUhHP08T2GPq8Nyvtzj4oqgjzKq1+l2RdehDM8j0KZrq5ZwDszb > CdKakVUrVXmMOEp16E48k5/66sulgJ5fNdVubJYNdPwsY2dNJ5MC7wbxSwIT46TD > 88tYAgco4cH9o4whwL2KZIjCQodKgvNwCnvW3qeXOdD/WqRSvuVbFIZh/+YZMHXi > KVnWrePS2kwukMiL28oB9fwsJomQpwxCJlhZxuLto7kM1vBhlKLOeFfoZ8gm6mrF > gBkDwiyV7aNHL4tFgAGtvDPReQhRS4DcN61EVEOYxMxQIKh1lDSFR1UW+j538S9c > J/7XGJI9CxQ= > =Qike > -----END PGP SIGNATURE----- > -- > gentoo-performance@g.o mailing list > > Alec Warner wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > lnxg33k wrote: > >> Thanks Alec Warner for the great explanation. It still seems like by > not > >> having portions of the tree by using EXCLUDEFORM and deleting the local > >> dirs that you'd save some time in the --metadata part of sync as less > >> ebuilds are available to be checked. Is this simply a wrong > misconception? > > > > The portion that "updates metadata cache" has nothing to do with what > > ebuilds are in the tree. It simply takes the server-side caches ( > > pregenerated ) and sync them into your local cache. You could RSYNC > > exclude the whole tree and this will still happen for every package, > > since the metadata is generated on the server ( and the server has the > > whole tree ). > > > > Now if you were to rsync exclude metadata/ you would reduce the > > - --metadata portion...because it wouldn't happen ;) > > > <snip> > > Ah, ok. Hearing it again makes it sound more reasonable. I'll have to > watch my > rsync output a bit more closely. Thanks again for the explanation. > -- > gentoo-performance@g.o mailing list > > How to get Maximum performance in Graphics on Nvidia Drivers???? > > > -- > gentoo-performance@g.o mailing list > > >