1 |
"Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted |
2 |
200605162027.21948.volker.armin.hemmann@××××××××××××.de, excerpted below, |
3 |
on Tue, 16 May 2006 20:27:21 +0200: |
4 |
|
5 |
> So I bet it is a) the ram b) overheating of the CPU or c) your PSU. |
6 |
> In that order. |
7 |
> |
8 |
> bzip2 needs a lot of CPU power, so overheating could be the reason. |
9 |
> Overheating or undervolting, as soon as it has an increased load. |
10 |
|
11 |
I'll second that. I've experienced bunzip2 issues before due both to |
12 |
over-clocking and to memory issues. Most recently due to memory issues, |
13 |
due to some generic memory I had. |
14 |
|
15 |
bzip2 is high compression, which stresses the CPU. It can also stress |
16 |
memory with larger tarballs. One characteristic of good compression is |
17 |
that the compressed form appears random -- no duplication or pattern |
18 |
visible, or further compression is possible. In such a situation, |
19 |
transmission or storage errors become possible and the reliability of the |
20 |
data is thus suspect. To account for and counteract this, bzip2 performs |
21 |
a pretty intensive integrity check. If your computer has unreliable |
22 |
parts, memory, CPU, etc, bunzip2 is very often the canary in the coal mine |
23 |
in terms of spotting them, due in part to this intensive integrity check |
24 |
and its sensitivity to memory or CPU errors. |
25 |
|
26 |
Despite the fact that you don't provide the specific errors, which could |
27 |
have been quite useful, I'd lay money on the problem being unreliable |
28 |
hardware, either CPU or memory. If it's possible with your motherboard, |
29 |
declock one or both a notch or two. Here, the memory error I had at the |
30 |
rated PC3200 (DDR-400) entirely disappeared when an upgraded BIOS gave me |
31 |
the ability to declock the generic memory from 200 (doubled to 400) MHz to |
32 |
183 (doubled to 366) MHz, from PC3200 to PC3000 equivalent. At the lower |
33 |
speed, the system was rock stable. |
34 |
|
35 |
Likewise in an earlier generation, when I was overclocking my (then |
36 |
Athlon-C) CPU from 1.2 to 1.33 GHz. For about a year and a half, I ran |
37 |
Distributed.net, thus 100% CPU on the overclocked. It ran fine, but it |
38 |
DID shorten the life of my CPU, such that at about 18 months in, I started |
39 |
getting various errors and ended up declocking back to 1.2 GHz. Even |
40 |
there, however, I had to keep the increased voltage, as the system was no |
41 |
longer stable without it, and even with the increased voltage, still |
42 |
wasn't absolutely stable. It was while I was on that system that MS put |
43 |
out eXPrivacy, and after waiting literally years for an NT based full |
44 |
32-bit system, I realized I couldn't accept the privacy and other |
45 |
compromises that MS was demanding. As a result, there was simply no way I |
46 |
could legally run eXPrivacy, because I couldn't agree to the EULA or the |
47 |
authentication scheme. Fortunately, I had been scoping out Linux for some |
48 |
time and ensuring all the hardware I purchased was Linux compatible, so I |
49 |
upgraded to Linux rather than go illegal with MSWormOS eXPrivacy. I've |
50 |
never looked back, but one thing I DID find out right away was that the |
51 |
system wasn't stable enough (due to my previous overclocking) to reliably |
52 |
do certain things (including using bunxip2). Fortunately, I had chosen |
53 |
Mandrake, a binary distribution, so it wasn't as bad as it would have been |
54 |
on Gentoo, but I got used to having to redo things like bunzip2 calls 2 or |
55 |
3 times to get them to work properly. |
56 |
|
57 |
I switched to AMD64 (and to the previously mentioned problem with generic |
58 |
memory) before I switched to Gentoo. Fortunately, the problem with the |
59 |
memory wasn't as bad as yours seems to be, but I still had to babysit |
60 |
emerges, and do some of them several times over to finish them |
61 |
successfully, until that BIOS upgrade gave me the ability to declock the |
62 |
memory just that one notch, and one notch made all the difference! |
63 |
|
64 |
So... Try declocking your system, either memory or CPU. Something's not |
65 |
running stable. If you can't or doing so doesn't help on amd64, chances |
66 |
are you'll have difficulty with x86 Gentoo on that computer as well, |
67 |
unless you can do the compiles on other x86 computers and just do the |
68 |
binary package thing on that one. Even then, if it won't do bunzip2, |
69 |
since the binary package thing uses bzip2 packages, you might be out of |
70 |
luck. If you can't declock something, you are most likely looking at |
71 |
either a memory replace or a CPU replace to get reasonable stability. |
72 |
Unfortunately... but that's dealing with real life, and I have the |
73 |
real life experiences demonstrating the fact. |
74 |
|
75 |
-- |
76 |
Duncan - List replies preferred. No HTML msgs. |
77 |
"Every nonfree program has a lord, a master -- |
78 |
and if you use the program, he is your master." Richard Stallman |
79 |
|
80 |
-- |
81 |
gentoo-amd64@g.o mailing list |