1 |
On Friday, December 30, 2016 01:57:53 AM Dale wrote: |
2 |
> J. Roeleveld wrote: |
3 |
> > On Friday, December 30, 2016 12:24:36 AM CET Dale wrote: |
4 |
> >> J. Roeleveld wrote: |
5 |
> >>> As for the specs: |
6 |
> >>> |
7 |
> >>> - 8 core CPU: nice |
8 |
> >> |
9 |
> >> Makes me drool a bit here. I want a 8 core CPU. The only downside, |
10 |
> >> gkrellm won't have enough screen to show each core separately. That's a |
11 |
> >> problem there. lol It already takes up the whole right side on one |
12 |
> >> desktop. I guess I could make the thing shorter to fit them all in. |
13 |
> > |
14 |
> > I know what you mean. What I miss is an option to have gkrellm on 1 side |
15 |
> > of |
16 |
> > the screen and when I maximize a window, that doesn't hide gkrellm. |
17 |
> > I limited some of the sensors to be able to fit all 12 virtual cores. |
18 |
> > (Or if there is, where do I set it) |
19 |
> |
20 |
> I wish we could divide it in half. Have some sensors on the left side |
21 |
> and some on the right. Dang, 12 cores. That does take up a lot of |
22 |
> room. To have it all show up, one would about have to turn their |
23 |
> monitor on its side and make it tall instead of wide. |
24 |
> |
25 |
> >>> - mSATA SSD: Make sure it fits your mainboard. NVMe is faster, but also |
26 |
> >>> more expensive. |
27 |
> >>> The Samsung EVO series are good for normal work-loads. The performance |
28 |
> >>> does |
29 |
> >>> tend to drop when the write-cache starts to fill up. With multiple VMs |
30 |
> >>> using disk and swap, that can happen quicker then you think. Check your |
31 |
> >>> requirements. |
32 |
> >>> |
33 |
> >>> - memory: Personally, I would increase this to 32GB with the fastest |
34 |
> >>> spec |
35 |
> >>> that matches the CPU and mainboard. It helps a lot, especially with |
36 |
> >>> Virtualbox. What isn't used by applications/VMs will be available for |
37 |
> >>> disk-cache. |
38 |
> >> |
39 |
> >> Same here. Putting portage's work directory on tmpfs does make it |
40 |
> >> measurably faster. Bad thing is, if Firefox and LibreO needs to update |
41 |
> >> at the same time, I have to go back to spinning rust or do them by |
42 |
> >> themselves. It runs out of memory pretty fast. |
43 |
> > |
44 |
> > I have 32GB in my desktop and I can run a "emerge -e @world" without |
45 |
> > issues |
46 |
> > and portages work directory is on tmpfs. |
47 |
> > And that is with the following parallel-settings in make.conf: |
48 |
> > MAKEOPTS="--jobs 12 --load-average 14" |
49 |
> > EMERGE_DEFAULT_OPTS="--jobs 12 --load-average 14" |
50 |
> > (Using a 6-core i7) |
51 |
> > |
52 |
> > -- |
53 |
> > Joost |
54 |
> |
55 |
> My settings: |
56 |
> |
57 |
> EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j8 |
58 |
> --quiet-build=n -1" |
59 |
> |
60 |
> I forgot I had that set to 8 jobs. Wonder why I did that? Given your |
61 |
> experience, I want to get more ram and more cores. |
62 |
|
63 |
More RAM, yes. More cores aren't always necessary. |
64 |
With regards to your options, the " --load-average .... " setting is important |
65 |
to keep the system responsive. |
66 |
|
67 |
With mine, it is possible to have 12*12 GCC-processes running. The load- |
68 |
average prevents that from happening. |
69 |
|
70 |
-- |
71 |
Joost |