PC Processors

[ajc9988]

I was recently reviewing the document covering the presentation at ISSCC and noticed that the RTC for Zen dies is located on the South Bridge. It was discovered about a year ago that Microsoft incorrectly reads the timer on the RTC when a base clock change occurs, which then can throw off benchmark scores or timers related to how long a task took to accomplish, etc. I was wondering if this has been addressed in the upcoming Zen 2 architecture?

[waltc]

OK, not sure why you would think Windows getting the right clock might require changes in hardware to the Zen architecture...;)  It's just a Windows software configuration bug--and you'll be glad to know that in Windows 10x64, build 17692--the latest Insider's beta build I'm running--the issue is fixed!  Windows now reports the actual clock speed of the Zen cpu (I own the 14nm Zen, the first-year Zen) as opposed to its base reported speed.  When I right-click "This PC" and select properties to bring up the Win10 general info screen, my 3.8GHz clock is shown, whereas before now only my base clock of 3.2GHz was shown regardless of the cpu's actual clock.  Also, the Taskbar/Taskmanager/Performance/CPU tab now also shows 3.8GHz as "base clock."  Actually I believe this was corrected a couple of Insider builds back.  If you aren't running Insider beta builds of Win10x64 then it's possible Microsoft will fix this in a cumulative update for you--or else it will be fixed in the next RS-5 consumer release of Windows10 in the fall.  Yes, I was glad to see this fixed, myself.  Also, bug only affected benchmark/utility software that read its info directly from windows--if the benchmark software read directly from the hardware, instead, then there was no problem with getting the clocks right.

[ajc9988]

What you are talking about DOES NOT show whether the issue has been resolved and sounds like you are missing what the problem is.

To explain:
BCLK    Multiplier    Frequency     Task completed
100          40               4000               9.079
102.5       39               4000               9.282

97.5         41               4000               8.870

All should read as finishing a task at the same time, but were not because of the RTC bug in Windows. Instead, you are describing whether or not Windows recognizes the all core boost or just reports what clock you set the system to. Instead, I am discussing the problem of accuracy related to use of the RTC timer, not whether windows can recognize the set multiplier on a processor. Completely different things.

Edit: Also, it is not necessarily something that needs fixed in hardware, but having the hardware company work with Microsoft on a solution to the issue can help to get the issue resolved. If nothing else, I was asking whether this is getting any attention  by them while working on their new processors. My current processor is a Threadripper 1950X that I have had since August of last year. I would love if it is fixed on the current gen from working with Microsoft on a solution.

[waltc]

Well, seems somewhat of a coincidence, then...;)  What version of Windows are you on?  The bug that I mentioned was only recently fixed in Windows 10--that's why I mentioned it.  Hope you get it sorted.

[ajc9988]

So, did a little testing of my own this evening. I looked at using the ITSC, the HPET, and the RTC timers in Windows 10 Enterprise Build 1803, April version. I performed 10 runs using each timer running at 100bclk x 39.5 multiplier and 10 runs of 102bclk x 38.75. This wound up comparing about 3948.96 to 3951.55. That would guarantee that the higher bclk score should be slightly higher than using the 100MHz base (in this case, faster, meaning lower time for completion). I am sharing the avg score with the highest and lowest scores thrown out to try to control, in part, for outliers. Here are the results:

                     ITSC                  HPET          RTC
SPI 100       10.49975         10.51238    10.51063
SPI 102       10.48513         10.50463    10.53063
GPUPI 100  7.279375         7.313125    7.34025

GPUPI 102  7.281125         7.286875    7.30775

As we can see, the problem persists, but I find the results curious. If you look at the RTC timer, it is off in the wrong direction with SPi, but is correct on GPUPI (measurement in seconds). When examining the ITSC timer, we see the inverse, with SPI correct, but with GPUPI the inverse of what it should be. With HPET, we see the correct result with both programs. Granted, this needs further testing, as well as an examination of the latency effects with each program with different timer resolutions (and a verification that even though GPUPI at the time was reading a specific timer, that the timer specified was actually being used, except for HPET, which is forced when turned on in the BIOS and on the OS), but it is confirmation that the problem is there.

ITSC is the default for Win 10 on these chips when the BIOS has HPET turned on, but the OS has it turned off. When HPET is off in the BIOS, the RTC timer was used (I cannot remember if I turned HPET on in OS or not while off in the BIOS to turn on the RTC timer). Then, the HPET timer was used when turned on in both the BIOS and in the OS. This is to give information to the community so that they can see the bug on this platform with actual numbers for what is going on. This was a simple project I could do to show the issue with publicly available software. Related to this, there was a discussion of this issue, although in a different way, in this Anandtech article due to discrepancies in their benchmark results related to gaming on Intel CPUs (more related to the latency of HPET when HPET is turned on for Intel's platform). A Timely Discovery: Examining Our AMD 2nd Gen Ryzen Results. I am sure the timer agnostic programming of some software vendors may also play a role in the issue as well.

I hope that this clarifies what was being discussed to a degree with actual examples that can be examined and replicated. I will be sending the images to the creator of CPU-Z as well to inform them that their program does not correctly display the speed in MHz of the CPU when the OS is using the HPET and RTC timers. I think I saw that Ryzen Master my also display the frequency incorrectly when HPET is not being used (something to test for another night).

[ajc9988]

So, digging more, I found out that CPU-Z has a tool in the Tools drop down for Timers. When ran for almost 20 minutes, the clock drift can be seen to be about 2-3 seconds:

I shared this as another way to identify the issue on the RTC drifting when compared to the other timers. One more way to show the issue and the effects.