Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-performance
Navigation:
Lists: gentoo-performance: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-performance@g.o
From: Cory Grunden <cory.grunden@...>
Subject: Re: Digest of gentoo-performance@g.o issue 6 (32-61)
Date: Mon, 23 Jan 2006 14:56:58 -0600
Shouldn't you be using sdparm, and not hdparm for your sata drives?<br><br><div><span class="gmail_quote">On 1/23/06, <b class="gmail_sendername"><a href="mailto:gentoo-performance+help@g.o">gentoo-performance+help@g.o
</a></b> &lt;<a href="mailto:gentoo-performance+help@g.o">gentoo-performance+help@g.o</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Topics (messages 32 throught 61):<br><br>[gentoo-performance]<br> &nbsp; &nbsp; &nbsp;32 - ??? &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:bolotov-bag@...">bolotov-bag@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance
<br> &nbsp; &nbsp; &nbsp;33 - Ken Robbins &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gatliffe@...">gatliffe@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;34 - lnxg33k &lt;
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:lnxg33k@...">lnxg33k@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;35 - Chris &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:chris@...">
chris@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;36 - lnxg33k &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:lnxg33k@...">lnxg33k@...</a>&gt;<br>
<br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;37 - Alex Efros &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:powerman@...">powerman@...</a>&gt;<br><br>
[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;38 - Kyle Lutze &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:kyle@...">kyle@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance
<br> &nbsp; &nbsp; &nbsp;39 - Christopher Bergström &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:cbergstrom@...">cbergstrom@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br>
 &nbsp; &nbsp; &nbsp;40 - Jeremy Brake &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoolists@...">gentoolists@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;41 - lnxg33k &lt;
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:lnxg33k@...">lnxg33k@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;42 - darren kirby &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:bulliver@...">
bulliver@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;43 - Michael Liesenfelt &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:mliesenf@...">mliesenf@...
</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;44 - Christopher Bergström &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:cbergstrom@...">cbergstrom@...</a>
&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;45 - Alec Warner &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:warnera6@...">warnera6@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance
<br> &nbsp; &nbsp; &nbsp;46 - Jeremy Brake &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoolists@...">gentoolists@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;47 - darren kirby &lt;
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:bulliver@...">bulliver@...</a>&gt;<br><br>[gentoo-performance] unsubscribe<br> &nbsp; &nbsp; &nbsp;48 - &quot;Matthew Coulson&quot; &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:MCoulson@...">
MCoulson@...</a>&gt;<br> &nbsp; &nbsp; &nbsp;53 - Alden Huang &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:alden.huang@...">alden.huang@...</a>&gt;<br> &nbsp; &nbsp; &nbsp;55 - Geisel Sierote &lt;
<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:geisel@...">geisel@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;49 - Bill Roberts &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:billbalt@...">
billbalt@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance<br> &nbsp; &nbsp; &nbsp;50 - Christopher Bergström &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:cbergstrom@...">cbergstrom@...
</a>&gt;<br><br>[gentoo-performance] gentoo-performance (sync speedups)<br> &nbsp; &nbsp; &nbsp;52 - lnxg33k &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:lnxg33k@...">lnxg33k@...</a>&gt;<br><br>
[gentoo-performance] <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a><br> &nbsp; &nbsp; &nbsp;54 - checl &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:check@...">
check@...</a>&gt;<br><br>[gentoo-performance] How to unsubscribe<br> &nbsp; &nbsp; &nbsp;56 - Oopsz &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:oopsz@...">oopsz@...</a>&gt;<br>
<br>[gentoo-performance] gentoo-performance (sync speedups)<br> &nbsp; &nbsp; &nbsp;57 - Alec Warner &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:warnera6@...">warnera6@...</a>&gt;<br><br>[gentoo-performance] gentoo-performance (sync speedups)
<br> &nbsp; &nbsp; &nbsp;58 - lnxg33k &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:lnxg33k@...">lnxg33k@...</a>&gt;<br><br>[gentoo-performance] How to get Maximum performance in Graphics on Nvidia Drivers
<br> &nbsp; &nbsp; &nbsp;59 - XFry &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:xfry@...">xfry@...</a>&gt;<br><br><br><br><br>










<div>

<p><font face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial;">&nbsp;</span></font></p>

</div>





<br><div>Hi my first gentoo performance came today but it way only a header no body what up with that?&nbsp;</div><br><br><div><font color="green"><strong>Powered by Gentoo Linux</strong></font><br> <span style="color: rgb(67, 128, 89);">
<span style="font-weight: bold;">Anything free is worth saving up for-Shadow the cat</span></span><br> </div><p>
		</p><hr size="1">Yahoo! Photos<br> 
Ring in the New Year with <a href="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&amp;.dir=" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Photo Calendars</a>. Add photos, events, holidays, whatever.
<p></p><br>Ken Robbins wrote:<br>&gt; Hi my first gentoo performance came today but it way only a header no body what up with that?<br>&gt;<br>&lt;snip&gt;<br><br>Mine too and I've been listening for a while. I think this ML may be dead ...
<br>*pokes the darkness*<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br>funny that a &quot;high performance linux&quot; has a dead performance ML... LOL
<br><br><br>lnxg33k wrote:<br><br>&gt; Ken Robbins wrote:<br>&gt;<br>&gt;&gt; Hi my first gentoo performance came today but it way only a header no<br>&gt;&gt; body what up with that?<br>&gt;<br>&gt; &lt;snip&gt;<br>&gt;<br>
&gt; Mine too and I've been listening for a while. I think this ML may be<br>&gt; dead ... *pokes the darkness*<br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>Chris wrote:<br>&gt; funny that a &quot;high performance linux&quot; has a dead performance ML... LOL<br>&lt;snip&gt;<br><br>Could be evidence that the &quot;ricer&quot; crowd doesn't read? (
i.e. they post to more<br>generic lists or use other mediums instead of something specific for their needs)<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o
</a> mailing list<br><br>Hi!<br><br>On Fri, Jan 20, 2006 at 03:30:29AM +0100, Chris wrote:<br>&gt; &gt; Mine too and I've been listening for a while. I think this ML may be<br>&gt; &gt; dead ... *pokes the darkness*<br>&gt; funny that a &quot;high performance linux&quot; has a dead performance ML... LOL
<br><br>It isn't dead because a lot of attentive listeners subscribed to it... :-)<br><br>--<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;WBR, Alex.<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>lnxg33k wrote:<br>&gt; Chris wrote:<br>&gt;<br>&gt;&gt; funny that a &quot;high performance linux&quot; has a dead performance ML... LOL<br>&gt;<br>&gt; &lt;snip&gt;<br>
&gt;<br>&gt; Could be evidence that the &quot;ricer&quot; crowd doesn't read? (i.e. they post<br>&gt; to more generic lists or use other mediums instead of something specific<br>&gt; for their needs)<br><br>Time to throw in a performance info post.
<br><br>Has anybody done any tests on the different between the one core and<br>dual core opteron processors? I currently have an opteron 242 and a gig<br>of ram on a tyan mobo, and I'm curious as to which would allow me to
<br>compile programs faster, as I lend the systems out to a lot of groups<br>that have slow systems<br><br>Kyle<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>lnxg33k wrote:<br><br>&gt; Chris wrote:<br>&gt;<br>&gt;&gt; funny that a &quot;high performance linux&quot; has a dead performance ML... LOL<br>&gt;<br>&gt; &lt;snip&gt;
<br>&gt;<br>&gt; Could be evidence that the &quot;ricer&quot; crowd doesn't read? (i.e. they post<br>&gt; to more generic lists or use other mediums instead of something<br>&gt; specific for their needs)<br><br>Since we're all here and saying hello.. Someone have a performance
<br>question or a good tip to add to the list?<br><br>The one thing that first pops to my head is some hdparm results I've had<br>and if maybe it's either my kernel setup or how I'm testing with hdparm...<br><br>Anyhow..<br>
<br>Raptors on SATA (Model Number: &nbsp; &nbsp; &nbsp; WDC WD360GD-00FNA0) (-c3 -u1 -A1<br>-W1 -d1 -a256 -M254 -m16 -X70 )<br>Kernel config<br>CONFIG_SCSI_SATA_SIL=y<br><br>There's an alternative driver, but haven't tested it...<br><br>
hdparm -tT /dev/hde<br><br>/dev/hde:<br>&nbsp;Timing cached reads: &nbsp; 956 MB in &nbsp;2.00 seconds = 477.02 MB/sec<br>&nbsp;Timing buffered disk reads: &nbsp;116 MB in &nbsp;3.03 seconds = &nbsp;38.26 MB/sec<br><br>hdparm -tT --direct /dev/hde<br><br>/dev/hde:
<br>&nbsp;Timing O_DIRECT cached reads: &nbsp; 244 MB in &nbsp;2.01 seconds = 121.26 MB/sec<br>&nbsp;Timing O_DIRECT disk reads: &nbsp;124 MB in &nbsp;3.01 seconds = &nbsp;41.17 MB/sec<br><br>Laptop 7k60 (Model Number: &nbsp; &nbsp; &nbsp; HTS726060M9AT00)<br>hdparm -tT /dev/hdc
<br><br>/dev/hdc:<br>&nbsp;Timing cached reads: &nbsp; 1980 MB in &nbsp;2.00 seconds = 989.94 MB/sec<br>&nbsp;Timing buffered disk reads: &nbsp;118 MB in &nbsp;3.04 seconds = &nbsp;38.81 MB/sec<br><br><br>hdparm -tT --direct /dev/hdc<br><br>/dev/hdc:<br>&nbsp;Timing O_DIRECT cached reads: &nbsp; 364 MB in &nbsp;
2.02 seconds = 180.54 MB/sec<br>&nbsp;Timing O_DIRECT disk reads: &nbsp;120 MB in &nbsp;3.04 seconds = &nbsp;39.42 MB/sec<br><br><br>I also can't set the raptors into UDMA6 tried -X70 with no luck..<br><br>Any suggestions?<br><br>Thanks<br><br>
C.<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br>How about speeding up the wait time on updating the portage cache after
<br>a sync.. even on my AMD 64 3500 it takes a number of minutes to chug<br>through..<br>are there any known ways to &quot;vrrmmm&quot; this up a little?<br><br>Jeremy<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>Jeremy Brake wrote:<br>&gt; How about speeding up the wait time on updating the portage cache after<br>&gt; a sync.. even on my AMD 64 3500 it takes a number of minutes to chug
<br>&gt; through..<br>&gt; are there any known ways to &quot;vrrmmm&quot; this up a little?<br>&gt;<br>&gt; Jeremy<br><br>Although not exactly what you're asking, you might want to look at<br>RSYNC_EXCLUDEFORM. Cuts down on what is checked during rsync. I assume that
<br>this could also cut down on the cache update time since there would be less to<br>check? Also cuts down on the amount of space eaten up by portage.<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>quoth the Jeremy Brake:<br>&gt; How about speeding up the wait time on updating the portage cache after<br>&gt; a sync.. even on my AMD 64 3500 it takes a number of minutes to chug
<br>&gt; through..<br>&gt; are there any known ways to &quot;vrrmmm&quot; this up a little?<br><br>+1<br><br>Mine sped up for all of a day, but is slow as molasses once again. If I did my<br>syncs during the day it might even peeve me...
<br><br>&gt; Jeremy<br><br>-d<br>--<br>darren kirby :: Part of the problem since 1976 :: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://badcomputer.org" target="_blank">http://badcomputer.org</a><br>
&quot;...the number of UNIX installations has grown to 10, with more expected...&quot;<br>- Dennis Ritchie and Ken Thompson, June 1972<br><br><br>lnxg33k wrote:<br><br>&gt; Although not exactly what you're asking, you might want to look at
<br>&gt; RSYNC_EXCLUDEFORM. Cuts down on what is checked during rsync. I assume<br>&gt; that this could also cut down on the cache update time since there<br>&gt; would be less to check? Also cuts down on the amount of space eaten up
<br>&gt; by portage.<br><br><br>I'll second RSYNC exclusions. It really does speed up syncing especially<br>on headless servers which don't need x11-*/*.<br><br>--<br>Michael Liesenfelt<br>University of Florida<br>Innovative Nuclear Space Power and Propulsion Institute
<br><br><br><br>


  
  


darren kirby wrote:
<blockquote cite="http://mid200601192143.34399.bulliver@..." type="cite">
  <pre>quoth the Jeremy Brake:<br>  </pre>
  <blockquote type="cite">
    <pre>How about speeding up the wait time on updating the portage cache after<br>a sync.. even on my AMD 64 3500 it takes a number of minutes to chug<br>through..<br>are there any known ways to &quot;vrrmmm&quot; this up a little?
<br>    </pre>
  </blockquote>
  <pre>+1<br><br>Mine sped up for all of a day, but is slow as molasses once again. If I did my <br>syncs during the day it might even peeve me...<br>  </pre>
</blockquote>
What kind of hardware are you guys running on?&nbsp; 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?<br>
<br>
What I am curious about is... what's it really doing when it says
51-52%.. That 1% seems to take forever..<br>
<br>
C.<br>


-- 
<a href="mailto:gentoo-performance@g.o" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gentoo-performance@g.o</a> mailing list
<br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Jeremy Brake wrote:<br>&gt; How about speeding up the wait time on updating the portage cache after<br>&gt; a sync.. even on my AMD 64 3500 it takes a number of minutes to chug
<br>&gt; through..<br>&gt; are there any known ways to &quot;vrrmmm&quot; this up a little?<br>&gt;<br>&gt; Jeremy<br><br>Well the current problem is that in the 2.0 portage branch the cache<br>code sucks. &nbsp;This is fixed in ~arch portage ( the 
2.1_pre series ). &nbsp;For<br>you users that don't want to upgrade to unstable, you should be able to<br>use cdb to speed up the process.<br><br>Setting RSYNC_EXCLUDES will not speed up the second half of the --sync (<br>the --metadata portion ).
<br><br>Explanation: &nbsp;The Portage Tree has a ton of ebuilds in it, when you do<br>something like emerge -pv &lt;blar&gt; portage used to have to go read each<br>ebuild and be like &quot;oh what are the USE flags, the dependencies, etc..&quot;
<br>This takes a lot of time, especially for something like emerge -uD world<br>that may touch thousands of packages.<br><br>So to mitigate this issue portage has a &quot;metadata cache&quot; where it stores<br>the ebuild metadata so it doesn't have to source each ebuild every time.
<br>&nbsp;This gives performance increases ( reportedly ) of 100x speed-ups.<br><br>However, generating the metadata is time consuming, even on decent<br>hardware it will probably take 30-45 minutes. &nbsp;To not piss the users<br>
off, Gentoo calculates this metadata serve-side and serves it to you<br>during sync.<br><br>The Rsync portion of emerge --sync is pretty much everything before the<br>&quot;updating metadata cache&quot;. &nbsp;This should be pretty standard as far as
<br>time goes on all boxes. &nbsp;However the second portion is where portage has<br>to take the generated server-side cache and kind of &quot;meld&quot; it into your<br>already existant local cache ( stored in /var/cache/edb/dep for those of
<br>you whom are curious ). &nbsp;This didn't used to take a bunch of time..until<br>&nbsp;KDE split their packages from KDE-monolith to KDE-meta. &nbsp;The <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://X.org" target="_blank">
X.org</a><br>switch probably won't help much in this area either. &nbsp;Particularly the<br>slowdown at 50-52% is due to this portion of the tree.<br><br>There is a new cache system in the 2.1 branch of portage, or using cdb,<br>
or perhaps even an sqlite back-end (patches and modules are out there),<br>will help until such time as the 2.1 branch is stablized ( probably not<br>too soon ).<br><br>- -Alec Warner (antarus)<br><br>Disclaimer: I'm not a developer (yet) but I've worked with the portage
<br>team for some time. &nbsp;Release dates, features, and other things are not<br>gauranteed to be correct just because I said so :)<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.2 (GNU/Linux)<br>Comment: Using GnuPG with Thunderbird - 
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br><br>iQIVAwUBQ9CExWzglR5RwbyYAQLJEhAAj7i2cRVgv1iBfi61mGkn9q1t/K5JEJcv<br>zK07bTmMDirviessdKiZVSufXdWV79tW0MDEVqmGI9t+V+uwM77aFbge1VSkEaQB
<br>RWetuQL8tQRUX1KvQ+ItScVtbqKIAQe/Jn+BwSim05jF3+fF15Z6EpPPKypNLQxK<br>2ef/bcJ91Gctv0xcd6j943uOPFDCt05Ahe06/pQ0wgGdnAcKLOy/RVwDOVfprXim<br>AwiVsU4aCxRI056RkEj1VuSwSYQEa91WKpTGv81lZVkRW8LRxkgc7UAydMYGjOY5<br>1prjv2Koyly5ycVvxshKVmLfuaqByY9bBnlklyKDdFW1ZD1udCflCLxmz3GuTCsm
<br>/FHce+Y9smqq3sF1wV7DYXu9vTnLdBqVBlDq4cEtd5XdgQm3TJ5rUGF2Mepicyhg<br>Bg4ibDExDB5eKWCnGU3ioSCd8TY9cdR9ZXxpm6JLGfr9ztog0/vScsIZbj3dS4RH<br>WqGklvW0F9N6NjP26WJwtQsmSIZpSJU4yPxneZOdQxGOUfdNPQap+qO+rZaitPKW<br>yWaikaiSuecPSul0ithpGnCFttPHrBLyNKNl7aom04Bht4KSdaqzriIL/RylWzHW
<br>OgazUV9RuVdI8oEx+q3zKzOgvG3dXeL7HNdhH+j9noIyGVa8ouNHWMGfFUc1baxV<br>7eyB1buSeQY=<br>=vWqe<br>-----END PGP SIGNATURE-----<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>Alec Warner wrote:<br><br>&gt;-----BEGIN PGP SIGNED MESSAGE-----<br>&gt;Hash: SHA1<br>&gt;<br>&gt;Jeremy Brake wrote:<br>&gt;<br>&gt;<br>&gt;&gt;How about speeding up the wait time on updating the portage cache after
<br>&gt;&gt;a sync.. even on my AMD 64 3500 it takes a number of minutes to chug<br>&gt;&gt;through..<br>&gt;&gt;are there any known ways to &quot;vrrmmm&quot; this up a little?<br>&gt;&gt;<br>&gt;&gt;Jeremy<br>&gt;&gt;<br>
&gt;&gt;<br>&gt;<br>&gt;Well the current problem is that in the 2.0 portage branch the cache<br>&gt;code sucks. &nbsp;This is fixed in ~arch portage ( the 2.1_pre series ). &nbsp;For<br>&gt;you users that don't want to upgrade to unstable, you should be able to
<br>&gt;use cdb to speed up the process.<br>&gt;<br>&gt;Setting RSYNC_EXCLUDES will not speed up the second half of the --sync (<br>&gt;the --metadata portion ).<br>&gt;<br>&gt;Explanation: *snip*<br>&gt;<br>&gt;<br>Thanks Alec, thats a really awesome explaination :)
<br><br>My server runs a 5am script which does this, so i'm not too worried<br>about that machine. For those who are curious, its an Athlon 1800+ on a<br>10Mbit link, and it takes between 1 and 10 mins to process &quot; emerge
<br>--sync --quiet; emerge -upvD world; glsa-check -t all &quot;<br><br>My home pc is on a 2Mbit link, so I only sync when i feel like checking<br>for updates, or when I want to install something new. This will take<br>minimum of 10 mins just to update the cache most times, sometimes more.
<br>Being a home pc, I'm happy to have some unstable stuff installed. How<br>messy would it be to just run ~amd64 portage? would this work, or do I<br>ideally need to make the entire base system ~amd64? (ugh).<br><br>Jeremy
<br><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br>quoth the Christopher Bergström:<br>&gt; &nbsp;darren kirby wrote:
<br>&gt; quoth the Jeremy Brake:<br>&gt;<br>&gt; How about speeding up the wait time on updating the portage cache after<br>&gt; a sync.. even on my AMD 64 3500 it takes a number of minutes to chug<br>&gt; through..<br>&gt; are there any known ways to &quot;vrrmmm&quot; this up a little?
<br>&gt;<br>&gt;<br>&gt; +1<br>&gt;<br>&gt; Mine sped up for all of a day, but is slow as molasses once again. If I did<br>&gt; my syncs during the day it might even peeve me...<br>&gt;<br>&gt; &nbsp;What kind of hardware are you guys running on? My laptop isn't on cron
<br>&gt; and I do it every couple days or so and it finishes in around 15-30<br>&gt; minutes.. I've never really paid any attention.. How long is yours taking?<br><br>It doesn't make a difference what hardware. I have 4 boxes that run gentoo
<br>(Athlon 2200, Athlon 3200, Apple G4, Sparc U60) and they all run the actual<br>sync quite fast, but the 50%-51% takes from 5 minutes on the 3200 to 30<br>minutes on the G4 and U60.<br><br>As I mentioned though, I don't let this bother me as I generally sync ~4:00am
<br>whilst sleeping.<br><br>&gt; &nbsp;What I am curious about is... what's it really doing when it says 51-52%..<br>&gt; That 1% seems to take forever..<br>&gt;<br>&gt; &nbsp;C.<br>&gt; &nbsp; &nbsp;-- <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br>-d<br>--<br>darren kirby :: Part of the problem since 1976 :: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://badcomputer.org" target="_blank">http://badcomputer.org
</a><br>&quot;...the number of UNIX installations has grown to 10, with more expected...&quot;<br>- Dennis Ritchie and Ken Thompson, June 1972<br><br><br>unsubscribe<br><br>_____________________________________________________________________
<br>Please Note: This e-mail is confidential and may be protected by law. &nbsp;This e-mail is intended solely for the named recipient(s). &nbsp;If you receive this e-mail in error, please destroy the copy in your possession immediately. &nbsp;Please do not disclose the contents to any other person, use information contained in it for any purpose, store or copy it. &nbsp;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.
<br>Copyright in this e-mail and any attachments remains with us. &nbsp;Express Reinforcements Ltd. Registered in England No.1808624. Head Office: Fordwater Trading Estate, Ford Road, Chertsey, Surrey &nbsp; KT16 8HG<br>To Visit our website go to 
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.ExpressReinforcements.co.uk" target="_blank">http://www.ExpressReinforcements.co.uk</a><br><br>This message has been checked for all known viruses by UUNET delivered
<br>through the MessageLabs Virus Control Centre. For further information visit<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.uk.uu.net/products/security/virus/" target="_blank">http://www.uk.uu.net/products/security/virus/
</a><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br>&gt;<br>&gt; The one thing that first pops to my head is some hdparm results I've had
<br>&gt; and if maybe it's either my kernel setup or how I'm testing with hdparm...<br>&gt;<br>&gt; Anyhow..<br>&gt;<br>&gt; Raptors on SATA (Model Number: &nbsp; &nbsp; &nbsp; WDC WD360GD-00FNA0) (-c3 -u1 -A1<br>&gt; -W1 -d1 -a256 -M254 -m16 -X70 )
<br>&gt; Kernel config<br>&gt; CONFIG_SCSI_SATA_SIL=y<br>&gt;<br>&gt; There's an alternative driver, but haven't tested it...<br>&gt;<br>&gt; hdparm -tT /dev/hde<br>&gt;<br>&gt; /dev/hde:<br>&gt; Timing cached reads: &nbsp; 956 MB in &nbsp;
2.00 seconds = 477.02 MB/sec<br>&gt; Timing buffered disk reads: &nbsp;116 MB in &nbsp;3.03 seconds = &nbsp;38.26 MB/sec<br>&gt;<br>Your times for the raptor seem awfully slow.<br><br>Here the SATA settings for my kernel and my hdparm times.
<br><br>antec ~ # grep SATA /usr/src/linux/.config<br># CONFIG_BLK_DEV_IDE_SATA is not set<br>CONFIG_SCSI_SATA=y<br>CONFIG_SCSI_SATA_AHCI=y<br># CONFIG_SCSI_SATA_SVW is not set<br># CONFIG_SCSI_SATA_MV is not set<br># CONFIG_SCSI_SATA_NV is not set
<br># CONFIG_SCSI_SATA_QSTOR is not set<br># CONFIG_SCSI_SATA_PROMISE is not set<br># CONFIG_SCSI_SATA_SX4 is not set<br># CONFIG_SCSI_SATA_SIL is not set<br># CONFIG_SCSI_SATA_SIL24 is not set<br># CONFIG_SCSI_SATA_SIS is not set
<br># CONFIG_SCSI_SATA_ULI is not set<br># CONFIG_SCSI_SATA_VIA is not set<br># CONFIG_SCSI_SATA_VITESSE is not set<br>CONFIG_SCSI_SATA_INTEL_COMBINED=y<br>antec ~ # hdparm -tT /dev/md0<br><br>/dev/md0:<br>&nbsp;Timing cached reads: &nbsp; 2776 MB in &nbsp;
2.00 seconds = 1387.91 MB/sec<br>&nbsp;Timing buffered disk reads: &nbsp;398 MB in &nbsp;3.00 seconds = 132.48 MB/sec<br>antec ~ #<br><br>Note that this is a RAID0 with two disks, so the buffered disk read time<br>is double what you should expect on a normal install.
<br><br>Good luck.<br><br>Bill Roberts<br><br><br>


  
  


Bill Roberts wrote:
<blockquote cite="http://mid20060120135137.GA4610@..." type="cite">
  <blockquote type="cite">
    <pre>The one thing that first pops to my head is some hdparm results I've had <br>and if maybe it's either my kernel setup or how I'm testing with hdparm...<br><br>Anyhow..<br><br>Raptors on SATA (Model Number:       WDC WD360GD-00FNA0) (-c3 -u1 -A1 
<br>-W1 -d1 -a256 -M254 -m16 -X70 )<br>Kernel config<br>CONFIG_SCSI_SATA_SIL=y<br><br>There's an alternative driver, but haven't tested it...<br><br>hdparm -tT /dev/hde<br><br>/dev/hde:<br>Timing cached reads:   956 MB in  
2.00 seconds = 477.02 MB/sec<br>Timing buffered disk reads:  116 MB in  3.03 seconds =  38.26 MB/sec<br><br>    </pre>
  </blockquote>
  <pre>Your times for the raptor seem awfully slow.<br><br>Here the SATA settings for my kernel and my hdparm times.<br><br>antec ~ # grep SATA /usr/src/linux/.config<br># CONFIG_BLK_DEV_IDE_SATA is not set<br>CONFIG_SCSI_SATA=y
<br>CONFIG_SCSI_SATA_AHCI=y<br># CONFIG_SCSI_SATA_SVW is not set<br># CONFIG_SCSI_SATA_MV is not set<br># CONFIG_SCSI_SATA_NV is not set<br># CONFIG_SCSI_SATA_QSTOR is not set<br># CONFIG_SCSI_SATA_PROMISE is not set<br># CONFIG_SCSI_SATA_SX4 is not set
<br># CONFIG_SCSI_SATA_SIL is not set<br># CONFIG_SCSI_SATA_SIL24 is not set<br># CONFIG_SCSI_SATA_SIS is not set<br># CONFIG_SCSI_SATA_ULI is not set<br># CONFIG_SCSI_SATA_VIA is not set<br># CONFIG_SCSI_SATA_VITESSE is not set
<br>CONFIG_SCSI_SATA_INTEL_COMBINED=y<br>antec ~ # hdparm -tT /dev/md0<br><br>/dev/md0:<br> Timing cached reads:   2776 MB in  2.00 seconds = 1387.91 MB/sec<br> Timing buffered disk reads:  398 MB in  3.00 seconds = 132.48
 MB/sec<br>antec ~ # <br><br>Note that this is a RAID0 with two disks, so the buffered disk read time<br>is double what you should expect on a normal install.<br><br>  </pre>
</blockquote>
I guess I should add that 2nd disk in there then..&nbsp; Anyhow, I'm bound
to what appears to be a not-so-friendly controller..<br>
<pre>CONFIG_SCSI_SATA_SIL is not set</pre>
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..<br>
<br>
Cheers,<br>
<br>
C.<br>


-- 
<a href="mailto:gentoo-performance@g.o" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gentoo-performance@g.o</a> mailing list
<br>Thanks Alec Warner for the great explanation. It still seems like by not having<br>portions of the tree by using EXCLUDEFORM and deleting the local dirs that<br>you'd save some time in the --metadata part of sync as less ebuilds are
<br>available to be checked. Is this simply a wrong misconception?<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list
<br><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>unsubscribe<br><br><br><br>Okay guys, stop mailing &quot;unsubscribe&quot; to the list. &nbsp;Instead, send a<br>blank message to <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance+unsubscribe@g.o">
gentoo-performance+unsubscribe@g.o</a><br><br>alright?<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list
<br><br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>lnxg33k wrote:<br>&gt; Thanks Alec Warner for the great explanation. It still seems like by not<br>&gt; having portions of the tree by using EXCLUDEFORM and deleting the local
<br>&gt; dirs that you'd save some time in the --metadata part of sync as less<br>&gt; ebuilds are available to be checked. Is this simply a wrong misconception?<br><br>The portion that &quot;updates metadata cache&quot; has nothing to do with what
<br>ebuilds are in the tree. &nbsp;It simply takes the server-side caches (<br>pregenerated ) and sync them into your local cache. &nbsp;You could RSYNC<br>exclude the whole tree and this will still happen for every package,<br>since the metadata is generated on the server ( and the server has the
<br>whole tree ).<br><br>Now if you were to rsync exclude metadata/ you would reduce the<br>- --metadata portion...because it wouldn't happen ;)<br><br>- -Alec Warner (antarus)<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG 
v1.4.2 (GNU/Linux)<br>Comment: Using GnuPG with Thunderbird - <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br><br>iQIVAwUBQ9GCJ2zglR5RwbyYAQLajw/+Mvfu9+0Sfo8nHo7gbNytHRNL1jVI61RD
<br>/EIiZZwV067X77IP72o0Y7SICRvnooEqtLvQW+rd2c/Kb6W4EtDga94X8EbOrHIm<br>0/IFqg7OqUa/psU6IkaPk959u7UJTnqlWmzluLbqRTx/X03lpjk6n+V4BOTRhcTA<br>WHa80quSpd5EkfdFAJ1oWVMn9ck7xSTn3ulzmlznCkLdWK6iR+m+r+wAWMPlcRFG<br>xE/Ik5uMVemlWuAElhMoB4xr/2hKfcsu/Egw9F+zVL5+3mGMyygHhELAvTVHU/C9
<br>jLX3noNFC+xSOesmC0e+l88Uyz2AYPuhg8S+3qciC+4Ax2QkDhhRxwM7lLF6yPBx<br>UpDNnTecT1iVuFUhHP08T2GPq8Nyvtzj4oqgjzKq1+l2RdehDM8j0KZrq5ZwDszb<br>CdKakVUrVXmMOEp16E48k5/66sulgJ5fNdVubJYNdPwsY2dNJ5MC7wbxSwIT46TD<br>88tYAgco4cH9o4whwL2KZIjCQodKgvNwCnvW3qeXOdD/WqRSvuVbFIZh/+YZMHXi
<br>KVnWrePS2kwukMiL28oB9fwsJomQpwxCJlhZxuLto7kM1vBhlKLOeFfoZ8gm6mrF<br>gBkDwiyV7aNHL4tFgAGtvDPReQhRS4DcN61EVEOYxMxQIKh1lDSFR1UW+j538S9c<br>J/7XGJI9CxQ=<br>=Qike<br>-----END PGP SIGNATURE-----<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">
gentoo-performance@g.o</a> mailing list<br><br>Alec Warner wrote:<br>&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>&gt; Hash: SHA1<br>&gt;<br>&gt; lnxg33k wrote:<br>&gt;&gt; Thanks Alec Warner for the great explanation. It still seems like by not
<br>&gt;&gt; having portions of the tree by using EXCLUDEFORM and deleting the local<br>&gt;&gt; dirs that you'd save some time in the --metadata part of sync as less<br>&gt;&gt; ebuilds are available to be checked. Is this simply a wrong misconception?
<br>&gt;<br>&gt; The portion that &quot;updates metadata cache&quot; has nothing to do with what<br>&gt; ebuilds are in the tree. &nbsp;It simply takes the server-side caches (<br>&gt; pregenerated ) and sync them into your local cache. &nbsp;You could RSYNC
<br>&gt; exclude the whole tree and this will still happen for every package,<br>&gt; since the metadata is generated on the server ( and the server has the<br>&gt; whole tree ).<br>&gt;<br>&gt; Now if you were to rsync exclude metadata/ you would reduce the
<br>&gt; - --metadata portion...because it wouldn't happen ;)<br>&gt;<br>&lt;snip&gt;<br><br>Ah, ok. Hearing it again makes it sound more reasonable. I'll have to watch my<br>rsync output a bit more closely. Thanks again for the explanation.
<br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br>How to get Maximum performance in Graphics on Nvidia Drivers????
<br><br><br>--<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:gentoo-performance@g.o">gentoo-performance@g.o</a> mailing list<br><br><br clear="all"></blockquote></div><br>
Navigation:
Lists: gentoo-performance: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
How to unsubscribe
Next by thread:
More portage questions
Previous by date:
Re: How to get Maximum performance in Graphics on Nvidia Drivers
Next by date:
Re: [gentoo-performance] How to get Maximum performance in Graphics on Nvidia Drivers


Updated Jun 17, 2009

Summary: Archive of the gentoo-performance mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.