Thanks Vyper, that list is great for showing the VRM capabilities and entirely reasonable considerations for each cpu class. Should answer Bill's question.

It does, thank you!

---

Seti@home classic: 1,456 results, 1.613 years CPU time

I like to keep the 2990 kit as up to date as possible in its operating environment so I upgraded Ubuntu to 1910 a few days ago. This went very smoothly and is in stark contrast with the WIN10 feature upgrades which NEVER work properly on all of my several Windows systems. However I then noted that the MB, Asus Zenith Rog Extreme, had a BIOS upgrade to 2001 and set about implementing that. After all, AMD have been working hard on the fundamental code to enhance TR performance so I reasoned I should instal the latest version produced by ASUS.
All went well and absolutely straghtforwardly until the 'completed' message came up and I think it started to say something about 'reset', then the screen went dead. There was still power to the system and some leds inside the case were lit but absolutely no response from the MB. I checked all cables and then power cycled twice with no result. I then got into a chat call with ASUS support lasting half an hour which ended with him saying I had to try removing the CMOS battery. As this would kill all the BIOS settings I wanted to think about it. This was about two hours after the system went dead. I was doing the 'thinking' sitting in front of the screen when suddenly - without me touching anything - the system came to life with the Ubuntu splash screen. NB this is a dual boot system and a startup should bring up the choose O/S screen first. Surely the kit was not working silently for two hours doing some AI upgrade!! I am absolutely mystified.
I am reluctant to go back nto the BIOS until I understad what is going on but I suspect that the frequency has dropped back to 2666 instead of the3000 I had it set to. Is there any Linux command or App that can tell me what frequency the memory is running at?
JSM

Is there any Linux command or App that can tell me what frequency the memory is running at?
JSM

Maybe this will help. I think the HWInfo might do it: https://www.google.com/search?client=ubuntu&channel=fs&q=linux+hardware+info&ie=utf-8&oe=utf-8

Tom

---

A proud member of the OFA (Old Farts Association).

Is there any Linux command or App that can tell me what frequency the memory is running at?
JSM

sudo lshw -C memory

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

thank you. the frequency had reverted to 2133 so i had to bite the bullet and reset the tweaking to 3000. fortunately this went ok without any blank screens. crunching is now back to the level it was before the upgrades if not a little faster.
jsm

Anytime you update the BIOS on a ASUS motherboard it will revert to out of the box defaults. That is why you save profiles in the BIOS and also on a USB stick to reload. Depending on how much of the BIOS was updated, you still might have Saved Profiles available to easily go back to what was running stable before like XMP memory settings. If the BIOS also flashes the core code, then it comes up with a blank slate and you will have to reenter all your BIOS settings. Saving to a .CMO file is the smart thing to do in that case and reload from a USB stick.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

OK I will remember that. Have you any idea what was going on with the 2001 BIOS upgrade?
jsm

OK I will remember that. Have you any idea what was going on with the 2001 BIOS upgrade?
jsm

As usual, ASUS is extremely sparse in saying anything about what a BIOS update does . . . if at all. This is all they mention.

Version 2001
2019/08/085.94 MBytes
ROG ZENITH EXTREME ALPHA BIOS 2001
1 Improve ezflash functionality
2 Improve memory stability

You never know what else under the covers they tweaked, updated or removed in the BIOS. The only way to know is to haunt the forums and read what the BIOS modders say about any one new BIOS release has changed.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I know it is Halloween but I found that a blank screen for two hours followed by a sudden wake up without me touching anything is pretty scary on a m/c costing big bucks (if you will excuse the colloquialism.)
jsm

Since I have been focusing on reducing the amount of electricity I use for cpu crunching while maintaining or increasing my core count....
Stipulate that I am running with Turbo-boost off.
Would upgrading to a 3700x from a 2700 use less electricity? Ditto 3900x?

Tom

---

A proud member of the OFA (Old Farts Association).

Cpu crunching is never good efficiencywise for your wallet. The only cpu that comes near is the new Threadripper with 64 cores. But the price is another thing. As usual its almost always better to have a latest gen Nvidia bang/buck wise.

Otherwise its always better to have a cpu enough to feed powerrestrained gpus for efficiency.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Cpu crunching is never good efficiencywise for your wallet. The only cpu that comes near is the new Threadripper with 64 cores. But the price is another thing. As usual its almost always better to have a latest gen Nvidia bang/buck wise.

Otherwise its always better to have a cpu enough to feed powerrestrained gpus for efficiency.

Very good point.

But when I compare a 2700 to a 3700x or even a 3900x would I be using less electricity for the same or more cores crunching?

I run a cpu-only project as my "other" project on my Seti@Home machine(s).

Tom

---

A proud member of the OFA (Old Farts Association).

Its not that you reduce energy but your cpu can produce more for the same amount of energy.

But if you only use the cpu to feed the gpus you're soo much better of using the mutex version instead sucking up almost the same cpu wattage and the performance difference would be almost none. Mutex version had helped me alot because i have slower cpu to feed the gpus.

In my case running solely s@h on the gpu and as only project its a clear win for me to run mutex and use the cpus as slaves only with almost the same amount of powerusage.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

But if you only use the cpu to feed the gpus you're soo much better of using the mutex version instead sucking up almost the same cpu wattage and the performance difference would be almost none. Mutex version had helped me alot because i have slower cpu to feed the gpus.

In my case running solely s@h on the gpu and as only project its a clear win for me to run mutex and use the cpus as slaves only with almost the same amount of powerusage.

I am sorry. I am not clear what you mean by "Mutex". Are you talking about driving multiple gpus with one core/thread?

Tom

---

A proud member of the OFA (Old Farts Association).

But if you only use the cpu to feed the gpus you're soo much better of using the mutex version instead sucking up almost the same cpu wattage and the performance difference would be almost none. Mutex version had helped me alot because i have slower cpu to feed the gpus.

In my case running solely s@h on the gpu and as only project its a clear win for me to run mutex and use the cpus as slaves only with almost the same amount of powerusage.

I am sorry. I am not clear what you mean by "Mutex". Are you talking about driving multiple gpus with one core/thread?

Tom

Go to this thread and read about: https://setiathome.berkeley.edu/forum_thread.php?id=84685

It explain in detail how the mutex builds works and the pros and cons of use them.

---

Juan - the thread you link to is only visible to members of one team so most folks won't be able to see it.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Correct, its a beta and very sensitive for its functions. And has limitations aswell. Due to that it isnt available todate for masses.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Juan - the thread you link to is only visible to members of one team so most folks won't be able to see it.

Sorry i forget about that, but Tom (who ask) can see as he is from our team.

Out of the thread topic so only a fast explanation to all folks. Please forgive my bad english.

The Mutex builds is an experimental crunching code development by some mates to try to squeeze a little more from the GPU.

It works in Linux only and on the latest NVidia GPU's since it comes from the latest Petri CUDA code.

What it does is use the Mutex properties of the OS, more info: https://en.wikipedia.org/wiki/Mutual_exclusion

It works by loading 2 or more WU at the same time on the GPU, but crunch only in 1 at a time. Then when it finish the crunch on the first WU it immediately start the crunch on the next one since the second is already on the memory and start loading the next WU. Rinse & repeat.

What it is his goal is to avoid the delay time when the GPU does nothing while the WU is DL from the cache.

In the real world the tests shows a gain of 1-4 secs gained on this process. So in a host who crunch 1000 GPU WU per day you gain about 1000-4000 secs of additional crunching time. Or 10-40 more WU per day per GPU. Never the YMMV will be more present than with them.

Apparently the gain is bigger in slow CPU hosts who runs fast GPU's or large mining host with a large number of GPU's who runs basically on slower CPU's too, but that is not a rule. The PCIe, HDD & SSD speed plays a big rule with them too.

No crunching speed gain is achieved because is exactly the same crunching code available on the AIO from TBar.

But they have 2 big limitations:

1 - It uses 2 X or more GPU & main memory (to store the WU) So not works on low memory GPU's or low main memory hosts.
2 - It works on SETI only crunchers, because the task switch control must be present on all the running programs and AFAIK no other project uses this method.

Very few uses this builds (maybe 4 or 5 only, yes i'm one of them if you wish to see the results) and was not released to the general folks exactly because this limitations, mainly the second one. Sure all the other projects admins will complain about them because they prevent the others projects running in the short term.

Hope that helps.

---

Forget to mention.

If you wish to follow my host to see how the Mutex works, be aware, forget about the GPU crunching time compare the CPU crunching time instead. With the Mutex builds the GPU crunching time almost doubles because the WU is stored on the memory and the timer not stop. Because the way it works, you can't see the actual time gain on the stderr. In my host the gain is in the range of 3 secs per WU. Since it does about 1440 WU per day per GPU it's a total gain of about 170 WU/Day crunched for the 4 GPU's. Not bad, about the same it gain with -nobs (around 3%).

But i use a SETI only dedicated cruncher. And i do no AP on it, there are no AP Mutex crunching program available to be compatible.

---

Thanks Juan.
Some of the basic principals may be applicable to lesser devices, but would need some very careful testing across a wide range of GPU/CPU combinations to find the exact limits. So it is wise to heavily restrict its availability to a small pool of trusted people just in case there is a problem
One question - has anyone tried, in a controlled way, to see what happens if the GPU has too little memory to hold both tasks concurrently? I'm guessing memory conflicts and consequent data corruption, but I could be a mile out.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?