I thought maybe the latest beta (5.28) might fix this, but so far no go: SIV64x is an excellent program and I have been using it ever since I read HH's endorsement of it several months back...and when my MSI Gaming Pro Carbon AC /R5 1600 is running at default clocks it reports everything admirably--it's right on the nose. The problems begin when I overclock my R5 1600 to any value above AUTO (3.2GHz.) For some reason this throws SIV64X off the track--and reports the bus running at 84MHz instead of the 100MHz it is running; the cpu at 3.2GHz instead of the 3.8GHz it is running, my ram @ 2.69GHz instead of the 3.2GHz it is running, etc. This held true through multiple reinstalls and through trying differing versions of SIV64X. I'm sure it is something simple and maybe HH can report it--although I feel sure the author may already be working on a fix as I speak. Indeed, this beta version is supposed to contribute to better Ryzen-system detections, but hasn't solved this problem yet. I didn't really see an easy way to report the bug myself, so I thought I might post here in the hopes that the author of this really nice program might see it...CPU-Z, however, reports the true values, as does HWinfo, and some other program I use the name of which I cannot recall atm. Here's something I have noticed, however, about the MSI GPC AC UEFI. If you try and experiment with several different overclocks sequentially in one sitting the UEFI bios somehow gets "confused" and starts reporting all kinds of wonky numbers to *all* the monitoring programs running under Win10x64--not just SIV64X! For instance, say after a round of setting different overclocks, you wind up with 3.8GHz as your last attempted boot--and it succeeds. But then you see that the monitoring programs are all reporting 3.2GHz even thought the UEFI is reporting the correct 3.8GHz when you go in and look at it. So the bios is correctly reporting 3.8GHz but all the monitoring programs, including SIV64X, are reporting 3.2GHz under Win10x64, version 1709, builds 17101 (and earlier!) There is a very simple workaround for it, though... When the bogus numbers start showing up everywhere, simply boot back into the UEFI and reset the cpu clock to AUTO, reboot. Then enter the UEFI once more, set the clock to your desired speed, and reboot and everything is fine with the results of the monitoring programs (except for SIV64X, which doesn't like any overclocking at all.) Because of this, I think that maybe there is a bug in the MSI UEFI that is causing this situation with SIV64X, possibly. The weird thing is that if you just do two or maybe three overclock experiments the bug doesn't manifest--it's when you do more than that, or when you go back and forth testing different overclocks that the bug that throws all the monitoring programs off manifests--until you "reset" it as I mention here. That's why I'm wondering if anyone else has seen this themselves. EDIT: MSI has a bios entry entitled "Core Performance Boost." I wanted to add that I have noticed that when I overclock I must disable it manually in order to get accurate reads from *any* of the monitoring programs--not just SIV64X. The theory is that when the cores are overclocked above stock this setting is automatically ignored--however, something is going on that confuses the monitoring programs when overclocking is invoked--and unless I have manually disabled this option in the UEFI bios they will all give readings that contradict the actual speeds at which the hardware is running. Everything is fine once I turn off this option, in all of the monitoring programs, save for SIV64X, which consistently reports the same values (listed above) no matter what overclocked speed the cpu is running. Seems like a bios bug to me...
Sounds like a similar issue ASUS is trying to cope with. Seems to boil down to the AGESA code itself. I reverted back to version 3008 for my C6H board. Since version iirc version 1501 the readout, even from within the bios itself, the readout on the left half of the screen is based on the cpu base speed. Since my bclk is set to 100.6, that left part shows the cpu running at 34 x 100.6=3420MHz. The right side of the same screen shows what the cpu is actually running at 39.25 x 100.6 = 3948MHz. Appears AMD and the monitoring programs need to talk with each other. I swear by HWiNFO64. It reports the speeds dead on.
Thanks much for the input...! I do not think either of us should rest until "the case is solv-ed" as Clouseau would say!... Yes, I use HWinfo64, too--it is accurate with overclocked values--so is Ryzen Master, AIDA 64 Extreme, CPU-Z...all accurate with an overclocked multiplier. Except for SIV64X. It really invites investigation, imo! So, I gather you haven't tried SIV64x? If you get some time and the desire, install it: http://www.rh-software.com/ It really is a dandy little program, as long as we're dealing with the stock Ryzen multiplier. I've actually been using it for awhile, now. (HH turned me on to it!) SIV64X seems so far the most sensitive to misreading the sensors when only the base CPU multiplier is changed--setting it from 32 to 33 (or to any number other than Auto--the MSI UEFI is capable of altering the cpu clock in .25 increments--so 38.5X, or 38.25 or 38.75 are all legal multiplier numbers, etc.) will cause the SIV64X utility to misread, from the bus speed on up--perhaps the 3rd-party programs are simply using incorrect offsets themselves?...hmmm...that seems like a distinct possibility, now that I think of it. SIV64X never had so much as a hiccup with my earlier system, an MSI AMD3+ 970a chipset supporting an FX-8320e cpu. A fully UEFI bios, too, the MSI 970 Gaming was not prone to error by overclocking utilities in the slightest, whether by overclocking the front-side bus or the cpu multiplier or both. No problems there at all through several versions of SIV64X. The strange thing is (as I see it) that the MSI Ryzen AMD 4 boards do not allow any tinkering with bclk...none at all. As advanced as this MSI bios is (and this board is as advanced as the Ryzen MSI UEFI code gets ,apparently) BCLK is locked away from the end user--even in "advanced" UEFI interface mode for the bios. But I see from your post--and I had seen this before, too, elsewhere IIRC--that the BCLK values are exposed to you and, I would guess, editable by you to some extent. There must be some reason why the fsb speed through BCLK is exposed by Asus but buried by MSI in these Ryzen boards--apparently, some characteristic of AMD's Ryzen chipset UEFI code that is interpreted differently by each OEM in their respective user interfaces. It seems likely the differences between the AMD 3/+ core logic chipsets and the AMD 4/+ core logic code have put off the 3rd-party chipset utility program authors to some extent, else we'd not see these strange results from these programs. I think it's also telling that when I switch on the core boost option in the UEFI that most if not all of these clockspeed utilities begin reporting the *wrong* clockspeeds--but only when the cpu multiplier is raised above default values. I'll have to check these readings again to make sure, but somehow these "boost" settings in the UEFI are throwing these 3rd-party programs off. As far as the AGESA values themselves...the latest version included in the 2.8 UEFI bios version for the MSI Gaming Pro Carbon AC is the best one yet for me--my 3.2GHz ram is finally running at 3.2GHz... And, my system is running like a top, elsewhere. An enduring enigma, this...
Minor Update: Now on SIV64X beta 28, version 23--still no go. Again, all other utilities are reporting the correct overclocked speed, fsb speed, and system ram speeds--except for SIV64X, which is still reporting the incorrect values listed in my first post when the system is overclocked--overclocked only, I might add, by a raised multiplier (eg, 38 instead of 32 or Auto). Thought Ray might like to know. When it's fixed I'll report back. Looks like SIV64X is simply extracting the values straight out of Win10x64, and I note that even the Taskmanager/performance clock for the CPU is in error. Now I'm thinking that Microsoft is using some sort of offsets, which in turn are feeding the wrong data to SIV64X when it queries.
I've contacted Ray about this and invited him to post about this himself, as it's very easy to correct. I'd rather he actually post in his own words about the simple fix; but in case he declines he has given me permission to mention the easy fix for this! I'm writing him now with the link to this thread.
All these problems stem from the TSC clock running at the incorrect speed on overclocked Ryzen CPUs after an AMD AGESA update. On such as the Ryzen 5 1600 when the multiplier is changed from the default of 32 to say 38 the TSC clock should run at 3.80 GHz, but still runs at 3.20 GHz. Compensating for this is quite easy, but I have been trying to find a reliable way to do this and thus far not found one so decided to add a command line qualifier to tell SIV what ratio the TSC clock is running at. It has been there since SIV 5.27 and the SIV 5.28 release changes document this specifing: Added -TSC-RATIO=<nn> qualifier to compensate for the TSC clock running at the incorrect speed on overclocked AMD Ryzen CPUs with some AGESA releases. If SIV reports the FSB speed as less that then 100MHz then use this qualifier to compensate for the AGESA bug. The value to use for <nn> is the reported CPU speed in MHz / 100 with typical values being 30 (Ryzen 7 1700) and 32 (Ryzen 5 1600). Once the AGESA has been fixed the reported FSB speed will be > 100 MHz and you will need to remove this qualifier.
OK, Ray--thanks! The the command line value -TSC-RATIO=32 worked perfectly for me. To note, you can place this value in your SIV64X shortcut and it works perfectly!
Nice to see you over here Ray Use yours SIV64 exclusively, still would love if yours SIV64 is supported by Aquacomputer and Aquasuite as well for monitoring etc But still its one awesome SW for monitoring which is running on my PC 24/7 Thanks, Jura