New Computer specification?

M

mefizto

Greetings all,

for while, I have been contemplating building a new computer. What prompted me to ask for the specification was the fact that I started compiling some packages to, e.g., having OSS for all audio devices, having the compiled packages consistently distributed on all the FreeBSD boxes, etc. I had a notion that such would take a lot of time and resources, but I was still surprised that e.g., rebuilding ports-mgmt/synth without the watchdog timer on a 4-cores, 3.0 GHz, 12 GB RAM, took close to 2 hours.

The other use will be general computing, i.e.,drafting documents, spreadsheet calculations, writing scripts, and audio and video processing. These, apart perhaps from the video processing, do not appear to be resource intensive, so the packages' building likely sets the resources' requirements.

At this point of time I do not anticipate building all the packages I use, though there are not many of them, but for future-proofing (if this term is not an oxymoron), perhaps a more powerful computer should be considered?

Any help regarding the resources' requirements, i.e., number of cores, amount of RAM, processor clock speed, and the interrelationship, e.g., more RAM vs more cores, would be appreciated. In that regard, given the current RAM prices, could adding an NVME drive in lieu of RAM be considered?

Kindest regards,

M
 
It really depends on the exact configuration. If you just watch top during the synth work, do you see a lot of idle CPU? Then you need faster storage because the system outruns it. If high swap usage is daily business, you need more RAM, and if the average system load is above 50% you might like a faster processor.

I personaaly take a good look at kernel and world build times and kind of use it as overall system performance indicator.
 
Hi MG,

thank you for the reply and, specifically, to look at the top statistics.

I have also looked at the logs and I now wonder if I have potential misconfiguration in the ports-mgmt/synth. I summarize my (mis)understanding of the configuration and post in a different thread to keep the issues separate.

At this time, I do not intend to build kernel and world.

Kindest regards,

M
.
 
  • Like
Reactions: MG
I replaced a 2012 Mac mini (quad core i7, 16G memory, 256G SSD) with this:
  • Beelink Ser 5 Pro MIni PC, AMD Ryzen 7 5825U 2 - 4.5GHz 8 core/16 thread CPU, 32GB DDR4 SODIMM RAM, Kingston NVMe 1TB SSD,
    AMD Radeon Graphics 8 core 2GHz, Intel AX200 WiFi, Bluetooth 5.2, 2.5Gbps Ethernet, 3x USB 3.2 Gen 2, USB 2.0, USB Type-C (data + video), HDMI 2.0, Display Port 1.4, Audio jack (HP + MIC).
for a tad under 500 AUD (deduct ~1/3rd for USD) from Amazon in July last year. The difference? Night and day. Firefox now builds in an hour compared with a full day.

Of course, this was before RAMageddon and SSDapocalypse. The closest machine now is:

Beelink SER5 MAX Mini PC, AMD Ryzen 7 7735HS(8C/16T, up to 4.75GHz), 24GB LPDDR5 RAM 500GB M.2 2280 PCIe SSD, Mini Computer Support 4K Triple Screen Display/WiFi6/BT5.4/2.5G LAN/USB3.2

for 753 AUD/469 USD. The 7735HS supposedly outperforms 5625U by 55%.
 
Hi trev,

thank you.

The problem with that solution, due to my failure to disclose additional information is, that I would like to add at least two 3.5 hard-drives (due to $/capacity), and have ECC memory, which these do not support. However, your suggestion is still valid, as the specifications give me an idea regarding the specification.

Hi richardtoohey2,

ROTFLMAO. In a thread https://forums.freebsd.org/threads/potential-ports-mgmt-synth-misconfiguration.103449/, I reported that a re-build of a single package built not only all the dependent packages, but in addition, e.g., gcc12, gcc14, rust-1.97.1, and so on, although they are not listed in the dependencies, and I used synth install [the specific port], which I understand should build only the particular port and its dependencies if they are affected by the changed options or downloaded if not.

Perhaps I am just too stupid for this.

Hi MG,

please see above.

Kindest regards,

M
 
mefizto said:
Any help regarding the resources' requirements, i.e., number of cores, amount of RAM, processor clock speed, and the interrelationship, e.g., more RAM vs more cores, would be appreciated. In that regard, given the current RAM prices, could adding an NVME drive in lieu of RAM be considered?
Click to expand...

Compilation runs at unlimited speed, so you buy as fast a computer as possible.

As far as RAM is concerned you need about 700 MB per core (plus hyperthreading if you turn that on) for the base system, but things like Chromium can have up to 1300-1400 compilation processes.

Swapping is not recommended even with a NVMe. It is overall faster to limit the number of parallel processes so that things fit except for rare swapping e.g. during linking.

A 16-core 5950x is still doing quite nicely and uses DDR4, which costs half as much as DDR5.
 
Hi cracauer@,

thank you very much, the breakdown of required memory per core is extremely helpful.

Yes, I am looking for a DDR4 based system, as a friend gave me 32GB of such a memory. UNfortunatelly, it is not ECC, so I am looking at a motherboard that supports registered RAM, as the prices are quite lower, I would think due to the fact that they are pulls form server farms.

I really like Supermicro, I have the X9 generation that I have never had any problems with. I have rcommnded Supermicro to several of my friends, and all are satisfied.

Kindest regards,

M
 
Unless money is no object I think you should give some serious consideration to how much benefit you will get. You could easily end-up spending several times what you needed for just running the software. I gave up building ports years ago and all that happened was everything went more smoothly. Nothing was noticeably slower, and I've never missed a feature - don't fall into the trap of building a port just to get a dependency that could be added manually.

There's also the question of how fast you really need the build to be. If the computer can be run 24/7, you might just run it in the background for a few days. If you aren't a developer there's not much downside to this anymore.
 
Hi bob2112,

thank you for your perspective.

I do need to replace my computer anyway as some of the peripherals, e.g., USB ports, HDMI port, are no longer working, or flaky. Second, your advise does not account for the scenario that I need a feature that is turned off, e.g., audio/jack.

And yes, I am in no rush so running in background is not a problem.

Kindest regards,

M
 
mefizto said:
Hi cracauer@,

thank you very much, the breakdown of required memory per core is extremely helpful.

Yes, I am looking for a DDR4 based system, as a friend gave me 32GB of such a memory. UNfortunatelly, it is not ECC, so I am looking at a motherboard that supports registered RAM, as the prices are quite lower, I would think due to the fact that they are pulls form server farms.

I really like Supermicro, I have the X9 generation that I have never had any problems with. I have rcommnded Supermicro to several of my friends, and all are satisfied.

Kindest regards,

M
Click to expand...

Running an old Xeon is always an option. My server is a dual Broadwell (DDR4 registered). But idle power is not great on an DDR4 reg platforms I am aware of.
 
I can understand ECC in a data center environment.
Over my many decades in the business, I have seen very few true memory failures.
Counted on one hand... Corsair being the chronic offender.

Yesterdays tech with a decent OS still performs very well.
I would count FBSD in this arena, along with Win7 and terminal or XFCE based Linux distros.

My big machine is an obsolete Xeon with 16 cores and 128gb of ECC, probably DDR3 IIRC.
This runs just fine. These Xeons were medical system throw-aways and came with ECC and Blu-Ray drives.
They are SATA-3 and are fast enough.

Wring out your RAM with MemTestPlus (freeware) for 24 hours, and you are good to go.
If in doubt, take a soft pencil eraser to the gold contacts, then alcohol to wipe clean.
Reseat a few times if need be.

The biggest exposure with old hardware are cheap electrolytic caps on the boards from the last century.
Yesterday's tech may be obsolete, but most still have solid polymer caps.
My ABit (recapped) has been running 15 years as my daily driver, until replaced by the Xeon.
 
HI bgavin,

thank you for the reply.

As noted supra, I have Supermicro X9 generation that has been working flawlessly. Regarding the "cheap electrolytic caps", I am looking at the Supermicro X12 generation motherboard.

Could you please clarify your statement "I have seen very few true memory failures"? Are you suggesting that RAM in general does not fail or that ECC is not needed?

Kindest regards,

M
 
I’m retired from the service business.
My experience is my personal one with client and commercial machines.

My opinion based on this experience is you have nothing to fear with non-ECC memory. Wring it for 24 hours before trusting to production.

If you have reliable PSU you should have reliable RAM.
 
bgavin said:
I’m retired from the service business.
My experience is my personal one with client and commercial machines.

My opinion based on this experience is you have nothing to fear with non-ECC memory. Wring it for 24 hours before trusting to production.

If you have reliable PSU you should have reliable RAM.
Click to expand...
I'd add to that a UPS, I've had so many fewer HDD fail after I started using one. I'm not sure that SSD is as susceptible to it as HDDs, but it's definitely worth having. I need to get back on trying to get mine talk to my FreeBSD computer as last attempt at it was a failure.
 
bgavin said:
I can understand ECC in a data center environment.
Over my many decades in the business, I have seen very few true memory failures.
Counted on one hand... Corsair being the chronic offender.
Click to expand...
From a pragmatic point of view you are right: non-ECC systems are widespread, and I don't know if the additional cost of ECC RAM is justified in the case of the OP.

But non-ECC RAM is showing its limits. They estimated that 10% of Firefox bug reports are caused by non-ECC RAM flips. An old DDR4 system, can have many silent problems monthly, because the PSU and/or the motherboard can have more electrical instabilities. They are "silent" in the sense that they hard to notice and often they have no real effects, but if you are unlucky they can damage important data on disk, or return wrong results during computer usage.

DDR5 has a mandatory ECC correction logic. Respect full ECC systems, only errors caused by the DIMM modules are recognized, but not the bus transmission errors. I don't know how frequents they are.
 
If you don't have ECC (and that means real ECC, not the DDR5 nonsense) you don't only miss error correction, you also miss error reporting. So you can't know whether you need ECC memory or not.
 
Hi OpenFreeNet,

OpenFreeNet said:
. . . and I don't know if the additional cost of ECC RAM is justified in the case of the OP.
Click to expand...

Could you please elaborate? Since the computer will be a "maser" in the sense that all files will originate therein by, e.g., download, compilation, or other processing, an (uncorrected) memory error will be propagated in storing them on a ECC protected server/backup server, and the ZFS will not save the file.

Kindest regards,

M
 
mefizto said:
Hi OpenFreeNet,



Could you please elaborate? Since the computer will be a "maser" in the sense that all files will originate therein by, e.g., download, compilation, or other processing, an (uncorrected) memory error will be propagated in storing them on a ECC protected server/backup server, and the ZFS will not save the file.

Kindest regards,

M
Click to expand...
Long story: when Intel had nearly all CPU market decided to not support ECC RAM on CPU of desktop computers, for selling its server CPU with ECC RAM support, at a premium price. AMD choose (more responsibly) to support also ECC from the beginning. Intel was nearly a monopoly, and so the majority of produced RAM DIMMs were non-ECC.

But, the more bit you store in a RAM DIMM, the more errors there can be, because they are more dense. So, if non-ECC RAM can be a good choice for systems with DIMM of 256MB, it starts to become risky with > 1GB DIMMs. Google and other players tested this, and found that there were uncomfortable number of errors, expecially if the RAM DIMMs were not top-notch quality and/or older and/or PSU and/or motherboard capacitors have problems. These errors can cause corruption of the file systems, in worst case scenario. But they are silent errors: memtest does not notice them, and RAM DIMM corrupts some bit, one time every week or month.

ZFS is a file system that uses all the available free RAM as cache. So, if the RAM corrupts data, ZFS is very sensible to this, because it does not insert CRC checks in the RAM buffers. By the way: a faulty RAM can corrupt also run-time instructions, so the file system can start writing 0 everywhere and/or the compiler will emit bad instructions. There is no safety belt, in case of RAM corruptions, if you are unlucky.

As my main home-lab server (that is also a build server), I opted for a very old XEON rack server. It was very cheap. It has 32GB of DDR4 ECC-RAM, and a 10 core CPU, and it can be expanded with another 10 core CPU and a lot of additional DDR4 RAM. For many tasks it is fast enough, because hardware made a lot of progress in last years.

EDIT: this is true for DDR4. As already said, I don't know if non-ECC-DDR5 DIM are instead reliable enough, because they have at least some internal check.
 
Hi OpenFreeNet,

as much as I appreciate your time writing both the "long" and "short" stories, it appears to me that they contradict the original assertion that ". . . [you] don't know if the additional cost of ECC RAM is justified in the case of the OP".

I any event my question has been and academic one, in the sense that my paranoia forces me to invest buying the ECC.

Kindest regards,

M
 
You must log in or register to reply here.
Back
Top