| 1 |
Apparently, though unproven, at 14:27 on Wednesday 01 December 2010, Peter |
| 2 |
Humphrey did opine thusly: |
| 3 |
|
| 4 |
> On Monday 29 November 2010 10:58:10 I wrote: |
| 5 |
> > ... it'll be tomorrow before I have any emerging to do ... |
| 6 |
> |
| 7 |
> Well, what strange results. Desktop responsiveness is drastically |
| 8 |
> improved. On the other hand: |
| 9 |
> |
| 10 |
> $ time (sudo emerge --sync) |
| 11 |
> [...] |
| 12 |
> real 10m3.185s |
| 13 |
> user 0m6.331s |
| 14 |
> sys 0m0.575s |
| 15 |
> |
| 16 |
> This is with a Gentoo rsync server on the same LAN segment. A P4 box on |
| 17 |
> the same segment recorded about 65s for the same command - nearly 10 |
| 18 |
> times as fast. |
| 19 |
> |
| 20 |
> On this box, calculating dependencies took about another 10 minutes, |
| 21 |
> though I couldn't time it accurately because it's only part of a |
| 22 |
> process. I was watching gkrellm and its display of CPU load while |
| 23 |
> simultaneously running four instances of BOINC clients (one per core) at |
| 24 |
> large niceness levels, and in the graphs I couldn't see any sign that |
| 25 |
> emerge was running at all. |
| 26 |
|
| 27 |
|
| 28 |
I get the same here. Flash and such things run nicely without hogging the rest |
| 29 |
of the machine, but dependency checking also takes ages. Except that I DO see |
| 30 |
high cpu usage in gkrell. I assume it's a simple I/O blocking issue as the |
| 31 |
machine is still quite responsive when it's doing a dep check. |
| 32 |
|
| 33 |
|
| 34 |
-- |
| 35 |
alan dot mckinnon at gmail dot com |
Archives