Can Ryzen be benched on Windows 10?

[Jumper118]

Just now, websmile said:

I rather think they were bored because they faced no competition

Maybe. amd were too busy gaining Ipc and starting from scratch to fix it with zen but you would think they could have fixed it with zen+. Maybe zen 2 will have the fix. Tbh I like win 7 anyway windoge 10 is windows beta, early access simulator

[websmile]

Win 7 is eol, noone will give it decent support anymore, this is microsoft. Which is the main reason why the BIOS fix is needed to ensure the future also for amd at benching if they want to see their products being used for this. Funny enough leeghoofd now has to judge efficiency and guess about this with apus xd. I am looking forward to these being used at comps, happy cheatgames lol

[Strunkenbold]

Jesus, I think I'm a little bit late here but I just want to clear things up.

We're definitely not allowing Raven ridge APUs on win 10. Doing so would open just another door to hell and that's something we're definitely do not need. Due RTC bug, the scores are serious broken and can't be trusted at all. 

No one has the time to verify the integrity of every single result.

So just make it clear, Raven Ridge can be benched with the 3DMark suite but that's it.

[SecretDragoon]

I was going to make a separate thread about this but someone on /r/overclocking linked me over here.

So all Ryzen benches that can be RTC cheated are fucked now then? Even looking at the CB15 Leaderboard we can see very obvious skews in results that people are getting. At this point is there even a reason to bench ambient on Ryzen when someone's just gonna fake a higher result?

It takes ten minutes to set up Windows 7 for benching Ryzen. All someone has to do is grab a second hard drive and load it via USB. It is no different than benching any of the older archs on Windows XP.

[yosarianilives]

5 minutes ago, SecretDragoon said:

It takes ten minutes to set up Windows 7 for benching Ryzen. All someone has to do is grab a second hard drive and load it via USB. It is no different than benching any of the older archs on Windows XP.

Main issue here is that win 7 doesn't work at all on raven ridge for some reason, even though it works perfectly fine on pinnacle ridge. So the only way to sub rr cpu benches is on win 10. Obviously this is a huge issue if you want to sub something like cb15 or spi, but it's the current state of things. Perhaps updated microcode will fix whatever the problem is on raven ridge so that we can get some legit scores on the cpu.

[ajc9988]

So, I see a lot of bashing on AMD for this, but want to spell out some things on this topic to go into a little further depth and welcome being corrected with further information and sources.

1) RTC was traditionally in the motherboard or chipset (specifically the south bridge). It is one of many timers on the motherboard.
2) HPET was also traditionally integrated into the chipset or south bridge.
3) Some microprocessors incorporate the RTC on chip, but not all, as seen with ARM.
4) No one has specifically shown that the RTC is incorporated on the Zen SoC (exception: EPYC as the chipset is integrated, meaning that the HPET and RTC, if the RTC is on the chipset and not another component on the MB, are integrated and the CPU can be blamed), but I want more info on this (whitepaper or statement from AMD).
5) Windows 7 CAN read the RTC, whereas newer versions of the OS cannot, suggesting the problem is not the RTC, but rather it lies with the software that reads the RTC, which is the OS pointing to this being a M$ bull issue.
6) If the RTC, like the HPET, is on the MB, and specifically the chipset, then it is the chipset manufacturer that is to blame, and AMD so long as it is related to the chipset development, for not finding out the changes and implementations to avoid RTC since M$ shows little interest in correcting their OS, as always. 
6.a) If the RTC is not on the chipset, but is on the MB, then MB vendors would share the blame in selection of the components related to the RTC. This would actually absolve AMD, in part, of the criticism.
7) There are known differences between the versions of Windows, with performance varying between 7, 8, and 10. 
7.a) Since there is a difference, HPET, which does not seem to be effected like RTC, was implemented as a requirement on 8 and 10.
7.b) When HPET is turned on, it has been shown to cause latencies on some processes, but it levels the playing field to give accuracy.
7.c) HPET causes large slow downs with the Spectre and Meltdown patches, more disproportionately effecting Intel, although AMD is more effected by HPET compared to it being turned off and RTC being used.
7.d) Why, with all of these factors, does HWBot not have a program that can be loaded and is required for use with benches on win 10 for the CPUs effected, especially since it takes a reboot to switch HPET on/off?
7.e) Why are people here not making a bigger stink about M$'s role in the problem? 
7.f) Instead of a separate program, why not make them include opening a bench, like GPUPI, which has the timer resolution at the top so that HPET can be confirmed in Win 10 for those submitting Win 10 benches with these CPUs? 

I could go on, but I think this might help the discussion along. @Leeghoofd I'd love your thoughts on this. 

Edit: This would be an example of what I'm talking about with having GPUPI only open to show the timer being used by the system (HPET on), which on every Ryzen is partially identifiable on Win 10 because it reads the bus speed as faster by almost 1MHz, but should be slightly slower than actually punching in 101MHz bus clock in the BIOS, but would be nice to have the HPET showing to remove all doubt. Just wanted to clarify 7.f.

 

Edited June 19, 2018 by ajc9988

[Strunkenbold]

This seems like a good idea. But it needs excessive testing on many platforms and the usage is quite limited. I dont own any Ryzen so somebody else would need to spend some time in this.

One major drawback is that while GPU PI provides results as a datafile, every other bench just uses screenshot verification. It should be no problem for someone who wants intentionally cheat to copy and paste such a GPU PI window or simply reclock his machine. The problem here is that the screenshot just shows the clock after the benchmark but we should actually need to know how the clock was during the run. So it would be no solution for competitions and global points.

It could be a solution for casual benchers but it would also mean additional steps for the screenshot and it seems that CPU-Z / GPU-Z is already problem, now we speak about people have to open GPU-PI to submit a SuperPI result.

All in all it is a bug which either AMD or MS needs to fix. I understand that this has ultra low priority for them but it basically makes benchmarking with Win10 a no go for us. 

[ajc9988]

6 hours ago, Strunkenbold said:

This seems like a good idea. But it needs excessive testing on many platforms and the usage is quite limited. I dont own any Ryzen so somebody else would need to spend some time in this.

One major drawback is that while GPU PI provides results as a datafile, every other bench just uses screenshot verification. It should be no problem for someone who wants intentionally cheat to copy and paste such a GPU PI window or simply reclock his machine. The problem here is that the screenshot just shows the clock after the benchmark but we should actually need to know how the clock was during the run. So it would be no solution for competitions and global points.

It could be a solution for casual benchers but it would also mean additional steps for the screenshot and it seems that CPU-Z / GPU-Z is already problem, now we speak about people have to open GPU-PI to submit a SuperPI result.

All in all it is a bug which either AMD or MS needs to fix. I understand that this has ultra low priority for them but it basically makes benchmarking with Win10 a no go for us. 

So, I'm going to address your points as presented.

1) Testing is needed, but I do not believe it is "excessive." This post already shows the problem, and it has already been shown that when HPET timer is used, the bug doesn't exist because it only effects two timers that windows uses and HPET is not one of them. http://hwbot.org/newsflash/2684_windows_10_affected_by_same_downclock_bug_like_windows_88.1_disallowed_for_now
This is why benches that contain a timer identifier can be used on Windows 8 and 10, because it verifies that the timer being used by the system is not one that has been effected. Now, I just booted into Win 10 with a 1950X without HPET on, opened GPUPI 3.2, and it gave the unsafe timer message. I let it turn on HPET, reboot, and it read as on. I then went to CMD prompt, did bcdedit /set useplatformclock false, and then closed and opened GPUPI 3.2 again. It still read as HPET being on. Why? Because it requires a reboot to change the timer being used to turn on or off HPET.
2) The usage isn't limited. Because of drivers and some changes in the OS, even with HPET on, Win 10 can on some benches give higher scores than Win 7, whereas Win 7 can still beat Win 10 on others, just like with Intel chips. AMD is gaining more market share per year, and if their chips do reach the 5GHz and above on the GF 7nm, which is advertised that 5GHz is the target for HPC/Server chips, and 14nm targeted 3GHz, and met that, for server chips, we could see AMD grab a lot more market share in around April of next year. That means now is the time to deal with this situation, not when it arrives about 9 months from now. That also goes with a GF official saying that AMD should be able to hit around 5GHz next year.

Gary Patton, CTO of GF: " Definitely. It is a big performance boost - we quoted around 40%. I don't know how that exactly will translate into frequency, but I would guess that it should be able to get up in the 5GHz range, I would expect."

This effects every AMD chip currently on the market, X370, X470, X399, and the lower chipsets that allow for overclocking. All of those will share compatibility moving forward to 7nm. Until AMD does a redesign on chipset, which it may be Asmedia's fault to begin with which is their chipset supplier, and also supplies many Intel chipsets, which all chips before Skylake are effected by this on the Intel side as well, making the problem larger than you just said, it would make sense trying to get on top of this now.

Also, I bring this up to have Christian Ney take a look at it and confirm the fix, just as he did for identifying the problem. As far as the community goes, we are members and contributors, but having specific people confirm it is what is needed for testing, along with identifying simple ways to verify, which I will identify in the next point.

3) The copy and paste comment on your part is malarkey. If that is the case, we need to throw out all scores not recorded with a video or a screen capture card. Is that what you are saying? Because copy and pasting theoretically can be done for any of those for screenshots.

Meanwhile, I wasn't thinking a data file, although asking for GPUPI to allow a screenshot data file for other benches for Win 10 isn't a bad idea, or asking to borrow the part of their program that identifies clocks and can do the screenshot to data file and submit to GPUPI would be good as well. As to clocks, refer to my first point. Otherwise, the dangers are no higher than those seen normally in the submission process. Also, if they borrowed that part from GPUPI or asked for a custom program similar, it could be asked they add a part that throws up the version of Windows below the timer.

4) We have rules on what is needed for submissions. This is just part of that. It can be automated, it can allow for scores to be addressed, and fixes a larger, looming problem coming next year with Intel's hitting a wall and not having 10nm ready until an undetermined quarter in 2019, having 14nm++ 8-core topping at around 5.2 without extreme cooling, going against a Ryzen 7nm that is clocking 5GHz plus in multi-threaded benches, where on a per clock basis AMD's SMT outperforms HT, and these will be run on chipsets without the fix due to backwards compatibility. Meanwhile, you'll have TR2 and TR3 being able to go toe to toe or beat that Cascade-X offerings, which top at 28-cores and won't be available until early 2019, with no clue when Icelake will arrive, needless to say volume 10nm cannon, which means the problem is coming whether you like to admit it or not. Intel's former CEO, BK, even said that their goal on the server side is to limit AMD to 14-20% market share or less, which AMD was still around 1-2%, meaning Intel is conceding they are about to face huge market share losses to AMD. This is to be proactive, not reactive.

5) It is a problem Windows needs to fix. If the RTC is in the Asmedia chipset, then it CANNOT be fixed until a new chipset arrives or potentially an AM4+ and sTR4+ hits the market, which is speculative at best. I do not think the RTC is on the chips themselves, but welcome being corrected if someone can show me otherwise. This also solves the hell on the AMUs from AMD as well, due to compatibility issues with Win 7.

So far, I have not seen this much thought being given to the issue by others. I addressed your concerns. If you can think of any other concerns, please, let me know as I do enjoy where this topic is headed and this may help with the entire issue as we all think through this together.

Edit: Also, if you would like, you can try turning off HPET on the Intel platform you have and check if it still uses HPET before the system is rebooted if you would like. That part of the question should be platform agnostic, meaning anyone can test it.

Edited June 23, 2018 by ajc9988

[yosarianilives]

4 hours ago, ajc9988 said:

>lots of words

the end point is that whoever's job it is to fix it, it's not worth anyone's time to try to allow the OS until it is actually fixed beyond a work around

[ajc9988]

34 minutes ago, yosarianilives said:

the end point is that whoever's job it is to fix it, it's not worth anyone's time to try to allow the OS until it is actually fixed beyond a work around

Considering M$ is the one who created the problem (why it works fine on Win 7 not on Win 8 or 10), and we know they have no intention of fixing their problem, it is a ticking time bomb of problems coming up next year. If it is the chipset, because of backwards compatibility, if you try saying by chip like it was said with Intel before Skylake, then you are going to have a lot of people submitting Zen 2 (Ryzen 3000 series) results without the issue being resolved, which is going to be a pain.

Either getting GPUPI to license freely a cut down program that just looks at timer, windows version, and does a screenshot to data file or just requiring it being open during a screenshot can address this before it becomes a problem. With the cut down program, it could even identify or have a bench drop down to select, that way for submissions.

Either way, I think much of not wanting to think about it comes from assumptions that bias toward Intel. Looking at trends in the market, Intel may not have the top chips next year, instead not coming back to top until 2020 or 2021. If that occurs, you could see a shift in platform submissions, making it harder to get ahead of than it is now is the point I'm making.

Edit: To be clear, if the problem is in the chipset, you would have to add the mainboard tab in CPU-Z to Ryzen screenshots to verify which chipset is being used because AMD allows backwards compatibility. That means, even if resolved in a newer chipset, people that just replace their chips in the old boards may submit it without realizing that the chipset, not the chip, is the problem. At that point, if they think the APU benches are hell, etc., wait until that comes. With Intel, they market segmented with board partners having new chipsets for most chips. That made the clear line divide easier when this was a problem on Intel. Depending on where the timer is with the AMD chips, this is going to be a lot more difficult. This is why I'm trying to get people thinking of it now, not 9-10 months from now when Ryzen 3000 hits. Right now, there is time to take whatever actions need taken, whether adding the CPU-Z tab for mainboard for Ryzen as a requirement, adding GPUPI to identify the timer in screenshots, or coming up with a program similar to what GPUPI does to capture the needed info and screenshot for submission. When those chips drop, it may become more problematic if they do have 5GHz about stock or can outperform the upcoming 8-core Intel chips. That is when points and records shift, and when headaches start.

Here is my analysis of TR2 32 core for the speculative CB15 benchmark:
"[A] stock TR 1950X with stock mem is between 2900 and 3100, with all core on 3.7GHz with 2133 loose timings. That is 26.18points per thread per ghz. If you take that, then a perfect linear scaling of the 3100 score would give you 6904 for the CB15 score for 32 Cores at 4.12GHz. The 6399 score is 7.3% slower than perfect linearity. At 2900 we get 24.49 points per thread per GHz, which would scale to 6458 points. So ... this [may be] just a very non-tuned rig the reporter examined. That means it is losing 1%-7.7% score due to the extra dies having no IMC and having to always jump die, which is not outside of the realm of possibility. So ... the ram [could be] slow as **** and it isn't tuned, and we are seeing that, whereas a person that can tune it could toss another 1,000 points on the score, potentially (going from people getting in the 3400-3600 range on CB15 scores, and depending on base, with having double the cores, so just a doubling of the spread from 500 to the 1,000 point number)."

Try running a similar estimate with Intel's chips. It suggests the 2200 score for the Intel 8-core was about 5.2GHz.

Edited June 23, 2018 by ajc9988
explaining further

[ajc9988]

To run an analysis, if current Zen chips (2700X) can regularly get 1925@4.3GHz, you have a standardized 27.98 points per thread per GHz. If the chips next year on 7nm are at 5GHz and achieve the same points per thread per GHz, you get about 2238 points in CB15 as being fairly regular. Intel's 8 core chip, which is based on 14nm++, using the 8700K for the comparative performance per thread, would have had to be clocked at 5.2GHz to get 2212 in the CB15 leak. That means it will be way closer, and that means this could be a large problem, especially if the die shrink brings other changes to help this  exceed what people are accomplishing with the 2700X aside from just the frequency boost (such as latency changes, IMC changes, cache changes, etc.).

[yosarianilives]

1 hour ago, ajc9988 said:

>more words

ability to get records has nothing to do with anything, its an issue of ability to verify a result and it's not possible unless we create a wrapper for every benchmark. If you'd like this to be a thing then I suggest you get right on coding it. Otherwise you're asking others to put a lot of effort into something for you.

[ajc9988]

1 minute ago, yosarianilives said:

ability to get records has nothing to do with anything, its an issue of ability to verify a result and it's not possible unless we create a wrapper for every benchmark. If you'd like this to be a thing then I suggest you get right on coding it. Otherwise you're asking others to put a lot of effort into something for you. 

The issue of ability to verify is going to be there. It is like you are not understanding what the backwards compatibility issue is going to mean. This is already a headache, and my point is this is going to get worse. Your response is that this is only for me. That isn't what this is about, just one person. I'm trying to sound a warning when it is easier to work on and solve an upcoming issue. I wish I was a coder. I'm not. I'm just an attorney who enjoys overclocking as a hobby. Instead, what I am good at is seeing potential problems and trying to devise solutions before an event occurs.

Here, it effects ALL AMD MODERN CPUs, not just me. When those CPUs may be able to beat Intel's scores on equivalent core and thread count, then verification of the accuracy of the scores from AMD CPUs becomes a larger issue for the entire community. What that means is if you don't want to deal with the validation headaches later, you start strategically planning for it now, while there is still enough time to have a fix done, tested, and fully implemented before the event occurs. It is called foresight.

[yosarianilives]

The only way is to create a wrapper like has been done for aquamark and some other benchmarks. My suggestion is that you get coding, because that's the only way it's gonna get made.

[ajc9988]

39 minutes ago, yosarianilives said:

The only way is to create a wrapper like has been done for aquamark and some other benchmarks. My suggestion is that you get coding, because that's the only way it's gonna get made.

Question: are you one of the people that is connected with HWBot? Meaning are you a paid employee or one of the people that is a decision maker within the entity? Or are you an overclocker that uses the platform and are saying this because that is your opinion separate from the entity?

[Strunkenbold]

Some points:

1. Yes Im aware that the exclusion of Windows 10 is a big problem. This already hurts this platform for sure. And of course the issue is getting bigger and bigger and can be potentially mean the death of hwbot in the long run.

2. Christian Ney basically makes a longer break for some time now and its even uncertain if he ever returns. He had the most knowledge on this issue. So everyone else from the team has to get in touch with problem first and as I already said, I dont even have the hardware. So testing different platforms and looking for loopholes will take time and money (and Im actually quite sure nobody has the time).

3. We are in no way interested in harming the competition between Intel and AMD. The whole idea of overclocking is to get more for less. AMD has products again who follows this idea. You spoke a lot about AMD gaining market share because they finally have good products again and thats fine. I really do appreciate that. But they are responsible if they want to compete here on hwbot. Basically it means they have to find a solution. That doesnt mean we hate them. But of course we were left alone here and their ignorance costs us time and money. And both is something the bot doesnt have anymore.

4. I appreciate your input on this issue. But its really problematic. And its actually like @yosarianilives already said, you would need to build wrappers around a lot of benchmarks, which costs extreme amount of money. There were already plans to do something like that btw but the costs were considered as too high.

5. The addition of GPU-PI in the screenshot verification would complicate the rules even more and I really fear that its too much for the user. There are already so many subs without any sign of CPU-Z or GPU-Z and I really dont know how it could help here to add one more thing on the list of needed apps to have a valid screenshot for hwbot.

6. The bot lacks human resources. I just can tell you that Im not in favor of any additional screenshot verification because we have not the staff anymore to reproduce questionable results. And its really too easy to cheat here. Copy & Paste a shot of GPU-PI and Photoshop your result on a black background is basically a 2 mins job. So things are simply not safe enough for competitions. 

So in the end I dont need to ask for a complex verification screenshot if I cant trust the result anyway. Im really sorry but in the current situation the bot is not able to to take even more work on his and its staff. We actually have to simplify things and reduce workload. So the only real solution is that everybody should get in touch with AMD and report this bug to them. The more people the better.
 

 

 

[ajc9988]

5 hours ago, Strunkenbold said:

Some points:

1. Yes Im aware that the exclusion of Windows 10 is a big problem. This already hurts this platform for sure. And of course the issue is getting bigger and bigger and can be potentially mean the death of hwbot in the long run. 

2. Christian Ney basically makes a longer break for some time now and its even uncertain if he ever returns. He had the most knowledge on this issue. So everyone else from the team has to get in touch with problem first and as I already said, I dont even have the hardware. So testing different platforms and looking for loopholes will take time and money (and Im actually quite sure nobody has the time). 

3. We are in no way interested in harming the competition between Intel and AMD. The whole idea of overclocking is to get more for less. AMD has products again who follows this idea. You spoke a lot about AMD gaining market share because they finally have good products again and thats fine. I really do appreciate that. But they are responsible if they want to compete here on hwbot. Basically it means they have to find a solution. That doesnt mean we hate them. But of course we were left alone here and their ignorance costs us time and money. And both is something the bot doesnt have anymore. 

4. I appreciate your input on this issue. But its really problematic. And its actually like @yosarianilives already said, you would need to build wrappers around a lot of benchmarks, which costs extreme amount of money. There were already plans to do something like that btw but the costs were considered as too high. 

5. The addition of GPU-PI in the screenshot verification would complicate the rules even more and I really fear that its too much for the user. There are already so many subs without any sign of CPU-Z or GPU-Z and I really dont know how it could help here to add one more thing on the list of needed apps to have a valid screenshot for hwbot.

6. The bot lacks human resources. I just can tell you that Im not in favor of any additional screenshot verification because we have not the staff anymore to reproduce questionable results. And its really too easy to cheat here. Copy & Paste a shot of GPU-PI and Photoshop your result on a black background is basically a 2 mins job. So things are simply not safe enough for competitions.  

So in the end I dont need to ask for a complex verification screenshot if I cant trust the result anyway. Im really sorry but in the current situation the bot is not able to to take even more work on his and its staff. We actually have to simplify things and reduce workload. So the only real solution is that everybody should get in touch with AMD and report this bug to them. The more people the better.
 

 

 

Thank you for the thoughtful and lucid response. Since we last talked, I have dug into the issue a bit more and have begun writing to AMD on social media and in their support forums. I would like to address some of my inaccuracies above as I have now found clarifying information in regards to some of the unclear parts mentioned above, as well as found an interesting article from April of this year by Ian Cutress and Ryan Smith examining this very issue in relation to his benchmark comparisons between AMD and Intel which I would like to give to the community to further the discussion.

First is that the RTC is usually found on the South Bridge/Chipset. HPET is the same. At the ISSCC conference of 2018, in discussing the die and MCM of their products, AMD disclosed that the RTC was in fact on the South Bridge, which is included on the die. (https://fuse.wikichip.org/news/1064/isscc-2018-amds-zeppelin-multi-chip-routing-and-packaging/). So, the question of where the timer was located has been resolved, but led to an interesting examination of the changes Microsoft included in Windows 8 and 10. With those editions, Microsoft moved to a larger inclusion for embedded devices, with those devices not usually including a timer of that type on their chips (modern example is the Arduino ARM processors). Also, with the movement away from the original TSC on processors, this has slowly evolved as timing on the system is relative.

In April of this year, Cutress and Smith released benchmark reviews of the 2700X. In this review, they were lambasted afterword due to their Intel scores being markedly lower than other reviews, leading to a five page article examining the problem, which all boiled down to timers used by the platforms. I include the article here for informational purposes. (https://www.anandtech.com/show/12678/a-timely-discovery-examining-amd-2nd-gen-ryzen-results). Granted, they use a different benchmark suite and do not perform the tests related to the problems resulting from the base clock offset and multiplier, but are discussing the underlying issue which is the same. This, then, can be used to raise awareness with the hardware and software vendors as a secondary examination of the issue, along with the note added at the end of the article showing the problems related to latency in using the HPET which is located on the chipset, which injects latency into the timer access and can result in drastic drops in performance due to this, which is a known issue that is re-emerging, thankfully (was discussed more heavily during the time period of initial discovery with Intel processors and is seen heavily and clearly with Performance Test 9 from Passmark, in which HPET drops the scores on both Integer Math and Floating point, which I discovered a week or two ago and need to post in their forums shortly, as their current recommendation is to reinstall Windows when it occurs, which the problem has been seen on Threadripper, the 8700K, and I believe the 6700K, if I recall correctly).

I can both understand and respect the thought you have given to this topic, including the lack of resources, both time and financial, to be able to address the concerns of validity in relation to this problem. It is that type of thoughtfulness that I was trying to illicit in this thread, rather than the more simplistic answers given prior to this point, as well as a discussion on different types of solutions. Even if one person, or a group of people, cannot solve the problem, by using collective wisdom on the topic to identify other solutions, we may be able to arrive at a more fitting solution that another person who comes along and has the knowledge, skills, and abilities may then take on this type of project on his or her or a group's accord in an attempt to address it moving forward.

I can be aggressive in my writing and tone, and do apologize if I have given offense. I assure you, it was trying to gather more information on the issue to move toward better solutions and to gather the full concerns related so that certain solutions may be ruled out leaving only those solutions that are acceptable to remain. As I said, I'm just an overclocking enthusiast. I love it as a hobby. In the same way, I would like to think there are other hobbyists out there with a similar passion. Because of that, even though the organization itself is currently unable to enact what it would like to further the interests of the community in all the ways that it would like, the promotion of the ideas for improvement to the community may allow for those with the abilities to do so gratis, so to speak, just as other open source projects have come to fruition in the past, while noting that there would still be extensive testing of any of these solutions before implementation.

So, this is why I tried to take a more formulaic manner in writing responses, so that if an underlying statement or fact is shown to not be the case, anything based on that is shown to need modified or to be faulty, all so that solutions can be formulated. Such things as showing that HPET, when forced in BCD, cannot be changed during use of the benchmark is one such item that needs shown. What that can lead to is instead of requiring wrappers for each benchmark, a separate program can be created showing the clock used which doubles as taking the screenshot, creating a data file, and allowing for the upload of that file or saving it locally for future upload. This would decrease the work needed in order to create the wrapper per benchmark used, reducing cost and time requirements for such a project. What I would like to do is generate ideas for solutions, such as that one, which may be able to be open sourced or created by a die hard which possesses the coding abilities necessary to create such solutions. Having the discussions of the issues and what are unacceptable, the reasons why, etc. may allow for such things to occur.

With that said, I absolutely also agree with consumers putting the onus on the corporations involved, even if not at fault, so that more weight is put behind the issue to generate a solution. That would mean trying to get the attention of AMD, Microsoft, Intel related to latency on their HPET implementation (which also effects AMD), so that they may address it, solving the problem closer to the root. Articles like the one from Anandtech are helpful in this regard, as it, as well as Christian Ney's prior work on the issue, and others, can be used to elevate the issue. This includes communities like Overclockers.at contacting Cutress and Smith to make sure HPET latency entered the discussion, as seen in this thread later attached to their article. https://www.overclockers.at/articles/the-hpet-bug-what-it-is-and-what-it-isnt

I hope this gives a better understanding of what is trying to be accomplished here, as I do feel this is an issue that will potentially continue cropping up as time goes on.

[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 lower 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 y ou 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.




Edit: I also wanted to point out that in Windows 10, CPU-Z incorrectly reads the frequency as about 25MHz higher when using HPET and RTC timers. It reads it correctly when using the ITSC timer. I will check if this is present in Windows 7 this evening. You can see GPUPI correctly reads what frequency is being used with those timers.

Edited June 26, 2018 by ajc9988
Pointing out an error in CPUID in Windows 10. I will check in Windows 7 tonight for CPUID error.

[ajc9988]

        Continuing the exploration of the issue, I found the timer tool in the CPU-Z Tools drop down. Once open, select Timer. You can hit start and it will start running clocks which are measured by their respective timers. After almost 20 minutes, this was seen with a 1950X:


You can see a clear drift falling back on the RTC clock. This was using the 100 BCLK x 39.5 multiplier, was run almost 20 minutes (short by 79 seconds), and resulted in about a 2-3 second drift in time. If nothing else, a quick and easy way to identify the issue. Once again, this test was run on Win 10 Enterprise 1803 build.

So, I'll be gathering data points of running this with different BCLK soon to see if the timing becomes more exacerbated with that type of tuning. To be clear, I am digging in to learn more about the issue and posting here for others to see so that if they care to, they can take the journey as well. Considering it was mentioned the best person on this is unavailable, I figured going through so others can see different ways of testing for and identifying the issue would be nice. Considering taking apart my skylake build (deprecated purpose) to load an OS and test there as a comparative baseline. This way it is a compare/contrast situation to show the difference in behavior on the different platforms.

Edit:


For comparison purposes, this is an 8700K at 4.7GHz with spread spectrum off.

Edited June 27, 2018 by ajc9988
adding a comparison point for this post

[flanker]

very interesting post!

[OCX.Chile]

Well according to rules you can use Win8/8.1/10 for GPU PI and x265, just you need to enable HPET for that Windows. You can also do some 3DMark (all) if run is valid, with no time measurement issue and valid ORB link.

The above only applies (according to rules) to MBs with bus block capabilities (those that have an external refClock) to increase 100 MHz for stock Bus Speed (shown in CPUz). With such MBs that dont have thar refClock stuff, should be permitted to use any Windows to submit any benchmark.

I would recommend patching Windows 7 for Ryzen. Then you can run all platforms with a CH6/CH7, Gigabyte X370 K5/K7, X370/X470 Taichi, etc

Regards

 

Edited July 12, 2018 by OCX.Chile

[speed.fastest]

We dont know about future CPU if the CPU can't use Windows 7 like Ryzen APU, thats the problem in this case @OCX.Chile, Windows 7 is not supported anymore by Intel or AMD. And actually i tested Threadripper on Geekbench 3, Windows 10 is score much better than Windows 7 does.

[flanker]

I think, win7 is "dead" for future platforms

[ajc9988]

Update: Windows 1903 has decreased the RTC drift issue from a preliminary check to likely be negligible. Benchmark scores are WAY lower (like 200 points in CB15 and 300 points in CB20 on my 1950X), but I also did not do a clean install yet nor have I slimmed down the new build yet. But I wanted to share in the event anyone else wants to take a look before I am able to run the gamut of tests I did above.



@speed.fastest@unityofsaints@flanker@Strunkenbold - this might be something of interest for you guys.

Edited May 23, 2019 by ajc9988
Wanted to tag a couple people for them to look into this as well.

[flanker]

Windows are full of bugs, I do not like updates of Win10. Because score in win7 and win10 I had very similar for Cinebench...

Edited May 24, 2019 by flanker