TWEAK: Enable HPET (in BIOS and OS) for better performance and FPS

[snaphat (Myles Landwehr) Member]

  On 10/02/2014 at 22:54, WonG. said:

But I already saw way lower latencies on other screenshot, for example in post #60. Without HPET activated my latency was about 60-90?s. And believe me, the difference is huge (especially in video games). I saw people with latencies about 20-50 with HPET activated. A stable latency (around 100?s) should work for me. Otherwise I'll have to deactivate HPET again, because the disadvantages outbalance the advantages. That's not what I'm aiming for, I don't want to miss the advantages I already acquired :(

Sorry, I'm not going to believe you without evidence because it wouldn't be very scientific of me. If you are seeing improvements in some tasks with either HPET enabled or disabled, then please provide benchmark evidence showing the FPS or other application improvements. Every claim thus far has been said anecdotally without evidence, but we do have some evidence showing that HPET doesn't result in tangible differences. Until someone provides evidence otherwise, I'm of the presumption that claims of better performance in either case are simply the result of placebo effect and logically this checks out because as I said before, these latency ranges are so low that the processing speed of a deferred call would still provide smooth playback of real-time audio or video. I mean at the end of the day, a typical GPU target framerate is 1 frame every 16666.7 microseconds (60 hertz). The deferred call latency you are seeing is orders of magnitude lower than that. Or to put it another way, a deferred GPU call would be handled 33 times that rate at the minimum (Or if we were targeting 30 hertz, it is 66 times faster than that rate). Note: anyone feel free to check my math.

 

In any case, there isn't going to be a magic bullet to bring the latency in-line with what you are seeing with HPET disabled. And like I said before, it may not even be accurately reported results in any case. I think this whole thing is largely splitting hairs over something that isn't an issue. If you were seeing large spikes then that would be different story, but you aren't. If you are having performance issues, it has to be elsewhere from DPCs based on your own results.

[WonG.]

I didn't want to make anyone believe anything. I just asked for some help. If you aren't able to deliver, just don't reply, thanks a lot! That's why a question can't be answered by a countering one. Or do I have to justify before why I'm aiming for a special goal?

 

I really don't care about your maths. You should just be happy for being one of these persons, who aren't sensitive to things like that. I'm not able to see a mistake in your calculation, but maybe you didn't consider every single aspect? Who knows, just an example: Have you ever seen a Film set up for PAL (50Hz) on a 60Hz display? Many people would say, having more Hz/s than needed can't be worse. Of course it can: The asynchronism forces the display to double some frames (nearly every 10th or 11th), this makes the picture unsmooth and micro stuttering appears.

 

I am not the one who sees some numbers and measured "facts", and subsequently my cognition changes... For example, I had to decide bewteen two TVs a few days ago and I took the one representing worse facts than the other one. Believe it or not, it had the better picture. Just for my cognition, it was better than the other one. I don't give a sh... how experts or benchmarks think about this decision, because I have to watch TV on this device, no one else.

 

With my current system settings, I got some issues like micro stuttering and input lag in some cases. I don't care, if i reach 300 or 350fps in a game, but with 300fps or more, it should be displayed smooth, not stuttering... And there are some parallels between these effects and my dpc latency. That's the only reason, why I'm trying to lower it.

[Athernar]

  On 11/02/2014 at 01:05, WonG. said:

I didn't want to make anyone believe anything. I just asked for some help. If you aren't able to deliver, just don't reply, thanks a lot! That's why a question can't be answered by a countering one. Or do I have to justify before why I'm aiming for a special goal?

 

I really don't care about your maths. You should just be happy for being one of these persons, who aren't sensitive to things like that. I'm not able to see a mistake in your calculation, but maybe you didn't consider every single aspect? Who knows, just an example: Have you ever seen a Film set up for PAL (50Hz) on a 60Hz display? Many people would say, having more Hz/s than needed can't be worse. Of course it can: The asynchronism forces the display to double some frames (nearly every 10th or 11th), this makes the picture unsmooth and micro stuttering appears.

 

I am not the one who sees some numbers and measured "facts", and subsequently my cognition changes... For example, I had to decide bewteen two TVs a few days ago and I took the one representing worse facts than the other one. Believe it or not, it had the better picture. Just for my cognition, it was better than the other one. I don't give a sh... how experts or benchmarks think about this decision, because I have to watch TV on this device, no one else.

 

With my current system settings, I got some issues like micro stuttering and input lag in some cases. I don't care, if i reach 300 or 350fps in a game, but with 300fps or more, it should be displayed smooth, not stuttering... And there are some parallels between these effects and my dpc latency. That's the only reason, why I'm trying to lower it.

 

You don't care about maths when discussing a piece of hardware that does nothing but maths in the first place? :rolleyes:

 

The placebo effect works both ways, just ask anyone that has had panic/anxiety disorders, if you think hard enough that something is going to happen, your brain will make it happen.

 

This is why we have maths and facts, so we aren't ruled by silly placebo effects and snake oil.

[snaphat (Myles Landwehr) Member]

  On 11/02/2014 at 01:05, WonG. said:

I didn't want to make anyone believe anything. I just asked for some help. If you aren't able to deliver, just don't reply, thanks a lot! That's why a question can't be answered by a countering one. Or do I have to justify before why I aim for a special goal?

:rolleyes: This is a forum, it's perfectly valid to ask questions, provide discussion, etc. I've provided help and expert opinion for you in all of my posts up to this point. You don't need to be rude just because I'm disagreeing with you are saying and asked for evidence. 

 

  On 11/02/2014 at 01:05, WonG. said:

I really don't care about your maths. You should just be happy for being one of these persons, who aren't sensitive to things like that. I'm not able to see a mistake in your calculation, but maybe you didn't consider every single aspect? Who knows, just an example: Have you ever seen a Film set up for PAL (50Hz) on a 60Hz display? Many people would say, having more Hz/s than needed can't be worse. Of course it can: The asynchronism forces the display to double some frames (nearly every 10th or 11th), this makes the picture unsmooth and micro stuttering appears.

This PAL discussion is a digression, but I'm going to assume you are talking about a TV that accepts a PAL signal and then does a poor job converting that to a NTSC signal.

 

In any case, this is neither her nor there w.r.t. to what I said regarding the processing differences between DPC and monitors. Your statement is just: 'you could be wrong because for example some people incorrectly believe that video frame rate conversation can't result in stuttering.' Sure, they are wrong, but people can be wrong about many things.

 

  On 11/02/2014 at 01:05, WonG. said:

I am not the one who sees some numbers and measured "facts", and subsequently my cognition changes... For example, I had to decide bewteen two TVs a few days ago and I took the one representing worse facts than the other one. Believe it or not, it had the better picture. Just for my cognition, it was better than the other one. I don't give a sh... how experts or benchmarks think about this decision, because I have to watch TV on this device, no one else.

It's fine if you don't care. I'm not here to make you agree with me. I'm just providing comment and help for you because you asked in your posts. Again, these are perfectly normal on a discussion forum.

 

 

  On 11/02/2014 at 01:05, WonG. said:

With my current system settings, I got some issues like micro stuttering and input lag in some cases. I don't care, if i reach 300 or 350fps in a game, but with 300fps or more, it should be displayed smooth, not stuttering... And there are some parallels between these effects and my dpc latency. That's the only reason, why I'm trying to lower it.

If you are seeing micro-stuttering caused by DPC issues it would be showing up in the graph results for DPC latencies, that's all I'm saying. If the latencies aren't spiking and they are consistent then that can't be the cause of the stuttering.

 

 

  On 11/02/2014 at 01:50, WonG. said:

Yes, but this maths is way higher than you could ever do this. Not the math is the problem, we are the problem. Often we aren't able to use math so complex, to cover things from every angle we could watch. Maths often only works in models, in a special frame of reference.

 

Or is there any math to display "micro stuttering"? It's like: "You don't need more than 60Hz, your eye isn't able to recognize more than 24 pictures a second..." Unfortunately the math isn't as easy as it seems to be! Anyway, I (and many others) was (were) able to walk through LAN parties and to trace every single display, running in 60Hz mode or less. ... And if there is no measurement and no maths for a evidence of micro stuttering, it's just because it hasn't been invented or discovered, yet!

There is a way to measure micro-stuttering, you graph the frame processing latencies in the same way that we are graphing DPC latencies. If you have consistent latencies then the issues you are having have to be else were, that's just science. :laugh: FYI: Nvidia has a toolkit called FCAT to measure microstuttering, but I've never used it though.

As for eye operating at 24 hertz, that's just a myth, that's not how visual processing in eye/brain works. It's well known that 60 hertz monitors do a poor job of capturing motion blur for example. In any case, this discussion is best done in another thread as Neowin already has had a recent thread regarding this topic. And there are other folk here who are better equipt to comment about it than I am.

[WonG.]

Yes, but this maths is way higher than you could ever do this. Not the math is the problem, we are the problem. Often we aren't able to use math so complex, to cover things from every angle we could watch. Maths often only works in models, in a special frame of reference.

 

Or is there any math to display "micro stuttering"? It's like: "You don't need more than 60Hz, your eye isn't able to recognize more than 24 pictures a second..." Unfortunately the math isn't as easy as it seems to be! Anyway, I (and many others) was (were) able to walk through LAN parties and to trace every single display, running in 60Hz mode or less. Not a big deal, but now I accept that you aren't able to recognize micro stuttering and that you aren't able to trust in God. In this case I show a lot more tolerance than you do, not accepting me. And if there is no measurement and no maths for a evidence of micro stuttering, it's just because it hasn't been invented or discovered, yet!

 

Maybe a high speed camera could help, but these are way more efforts, to just get a simple answer, than reasonable. 

[BoDEAN]

My performance is currently fine with my setup. Going to pass on this tweak, but thanks for sharing.

[WonG.]

  On 11/02/2014 at 01:50, snaphat (Myles Landwehr) said:

If you are seeing micro-stuttering caused by DPC issues it would be showing up in the graph results for DPC latencies, that's all I'm saying. If the latencies aren't spiking and they are consistent then that can't be the cause of the stuttering.

 

This micro stuttering doesn't express itself as big spikes. Yes, sometimes there are spikes, and then you really are able to measure them via the DPC latency.

 

But anyway, you aren't able to lower my base latency, so all discussions are unnecessary. Thank you very much for your efforts and sorry for being rude.

[Athernar]

  On 11/02/2014 at 01:50, WonG. said:

but now I accept that you aren't able to recognize micro stuttering and that you aren't able to trust in God.

 

Typical placebo cop-out response. Computers are man-made digital devices, they are built upon and built from maths and logic. There is no subjectivity or unknowns at play here, a computer is not like the human body where we've yet to understand it fully.

 

If the math doesn't add up, and you've accounted for all the correct variables, then your "theory" is bunk. Simple as that.

[WonG.]

@Athernar

 

Y, but math should be used correct. There is no way, a normal fps benchmark is able to help me displaying my issue. If there is 1/8 or 1/16 of a second, where no new pictures are shown, and in the rest of the second, there are enough new pictures shown, you won't be able to see the problem on the basis of a normal benchmark. You can have at least more than 300fps without having a smooth picture.

[Athernar]

  On 11/02/2014 at 02:16, WonG. said:

@Athernar

 

Y, but math should be used correct. There is no way, a normal fps benchmark is able to help me displaying my issue. If there is 1/8 or 1/16 of a second, where no new pictures are shown, and in the rest of the second, there are enough new pictures shown, you won't be able to see the problem on the basis of a normal benchmark. You can have at least more than 300fps without having a smooth picture.

 

So benchmark the frame time instead of the FPS aggregate.

[NateB1]

This is purely anecdotal, but I had a case where I overclocked my CPU by a fairly significant amount several years ago( ~800 Mhz or so on an i7 920), and for a while games would operate in a slowed-down fashion - where the audio would play and the characters in the 3D games would quickly go out of sync with the audio, due to being in slow motion.  It was not a framerate issue - the framerate was fantastic, but anything that required CPU was in slow-motion.   It was very annoying - and what fixed it was enabling HPET in the BIOS and in Windows.  It was a very odd problem.  I've moved to a different CPU/motherboard now, but still overclock by a fairly wide margin, and I've kept HPET enabled to prevent such a scenario from happening again.

[snaphat (Myles Landwehr) Member]

 

  On 11/02/2014 at 02:08, WonG. said:

This micro stuttering doesn't express itself as big spikes. Yes, sometimes there are spikes, and then you really are able to measure them via the DPC latency.

 

But anyway, you aren't able to lower my base latency, so all discussions are unnecessary. Thank you very much for your efforts and sorry for being rude.

 Micro-stuttering by definition is caused by differences in frame processing that show up a frame processing spikes. You aren't looking at that directly though. However, it stands to reason that if DPC latency is consistent and low, the micro-stuttering you are seeing can't be caused by it. If you are seeing stuttering you need to check your frame latencies and see if those show an issue. If neither show an issue, then something else is going on. Discrepancies in frame processing time are going to come out in the wash somewhere.

 

  On 11/02/2014 at 02:19, Athernar said:

So benchmark the frame time instead of the FPS aggregate.

Yup.

 

@WonG: I modified my previous post slightly. It mentions something called FCAT, try to see if you can use that. You don't need to show us evidence if you don't want to, but it'd be probably be good tool check if you can see issues yourself.

 

 

  On 11/02/2014 at 02:22, NateB1 said:

This is purely anecdotal, but I had a case where I overclocked my CPU by a fairly significant amount several years ago( ~800 Mhz or so on an i7 920), and for a while games would operate in a slowed-down fashion - where the audio would play and the characters in the 3D games would quickly go out of sync with the audio, due to being in slow motion.  It was not a framerate issue - the framerate was fantastic, but anything that required CPU was in slow-motion.   It was very annoying - and what fixed it was enabling HPET in the BIOS and in Windows.  It was a very odd problem.  I've moved to a different CPU/motherboard now, but still overclock by a fairly wide margin, and I've kept HPET enabled to prevent such a scenario from happening again.

It kind of sounds like overheating and the CPU throttling to me. It also kind of sounds like buggy timer code or driver code. You aren't the first person to experience this from googling briefly. I'm chalking it up to bugs somewhere at the moment given that it was fixed via HPET in your case. 

[WonG.]

  On 11/02/2014 at 02:26, snaphat (Myles Landwehr) said:

@WonG: I modified my previous post slightly. It mentions something called FCAT, try to see if you can use that. You don't need to show us evidence if you don't want to, but it'd be probably be good tool check if you can see issues yourself.

With lower latency I haven't had any stuttering issues... The FCAT seems to need a high speed capture card to work correct. The software based capturing captures before directx and before drivers take action.

 

http://international.download.nvidia.com/geforce-com/international/pdfs/FCAT_Reviewer's_Guide.pdf

[snaphat (Myles Landwehr) Member]

  On 11/02/2014 at 02:41, WonG. said:

With lower latency I haven't had any stuttering issues... The FCAT seems to need a high speed capture card to work correct. The software based capturing captures before directx and before drivers take action.

 

http://international.download.nvidia.com/geforce-com/international/pdfs/FCAT_Reviewer's_Guide.pdf

Try Fraps with frame-times enabled and process it using this app: http://sourceforge.net/projects/frafsbenchview/files/ (it explains how). Note: I've never done this so I dunno how well it will work. I wasn't aware fraps was capable of doing frame times (perhaps it is a new?)

 

EDIT: another link for it: https://frapsforum.com/threads/frafs-bench-viewer-tool-for-viewing-fraps-benchmark-files.2121/

[NateB1]

  On 11/02/2014 at 02:26, snaphat (Myles Landwehr) said:

 

 

It kind of sounds like overheating and the CPU throttling to me. It also kind of sounds like buggy timer code or driver code. You aren't the first person to experience this from googling briefly. I'm chalking it up to bugs somewhere at the moment given that it was fixed via HPET in your case. 

 

 

Temps were fine - I'm blaming the motherboard.  I experienced random odd occasional stability issues with it I could never quite pin down - memory tests came back fine, it passed CPU/GPU stress tests, etc.

[clustaB]

Hi guys, I could not resist joining this forum to add my two cents. HPET made me go nutz, too.

 

 

HPET on/off making a significant difference is definitely NOT snake oil.

 

 

On my previous Win 7 build (DAW only), disabling HPET in BIOS & OS resulted in a DPC latency of comfortable 2 - 4 micro seconds. Before that, the latency rarely ever dropped below 130 micro seconds, which already has been quite good regarding the 270 which I?ve had before I got rid of my nvidia card and its crappy drivers.

 

Not only there were no more drop outs (at reasonable buffer sizes), the whole system was much more responsive. The negative result was that my ASIO load meter got more "nervous/sensitive". Means that the meter in Cubase jumped up and down more than before when it was slightly higher but also more stable.

 

I?ve dealt quite a while with the HPET thing and have come to the conclusion, that HPET is neither the "best timer" nor the worst. Computers are not interested in having the timer "ring" every 1000 or 976 or whatever when. They have no personal preference and don?t care about the output. Just about the processing itself. So the important thing is to have as many timers as possible as this means more potential moments to generate interrupts.

 

["...interrupts can be missed if the target time has already passed"]  the wiki link

 

Enabling HPET & using "bcdedit..... true" to force Windows to use only one timer seems absurd. More

 

Just think of it as drinking in a bar where two out of three waitresses have been fired and the one who?s left may be extremely punctual at appearing only once per hour. One of the former waitresses (which meanwhile are unemployed and hungry) could have come your way already 45 minutes after your last beer order. That?s when you were supposed to generate that one interrupt to quench your thirst.

 

I am aware that there has to be some kind of down side to it. Otherwise, nVidia would not set their drivers to strictly induce a latency of 255 micro seconds instead of matching it with the PCI Latency Setting found in BIOS. Maybe this allows a more stable framerate (not a faster one!), like slaves on a galley working their paddles to the decent but steady beat of the drummer. Less strokes, but more load per stroke.

 

While its benefits/disadvantages depend on each single person?s needs, its influence on the computer at the bare system level has to be clearly explainable. There is no place for "every setup is different, so this function does whatever its wants to do", computers don?t work this way.

 

For me, disabling it much more serves my needs as constantly keeps my snake oiled.

 

 

Cheers from Germany

[DeepSpaceDoge]

I have just registerd to say that this did wonders to my old rig

Core 2 Quad Q6600@3Ghz

Asus P5Q-Pro on Intel P45

Win 8.1 64bit

 

I have no option in bios to enable HPET but enabling it in windows with Win 8 specific command "bcdedit /set {current} useplatformclock yes"  increased overall responsivness and disk transfer rates, firefox starts like 2x faster same as many other apps, and what is most imortant to me finally Diablo 3 stopped stuttering like crazy every few seconds without anything special on screen - battle.net forums are flooded with posts about this problem and Blizzard completely ignores them. If I only knew about it since D3 release day!

High precision event timer is in my device manager and WinTimerTester shows 14.31818 MHz

What to say more...Big THANK YOU

[PanzerIV]

Me too I've registered on that board only to comment about my experience. It's a comment from a post on BlurBusters.com that brang me here. I already had "HPET" enabled since day 1 on my new computer and even did since forever on my previous as I always optimize my bios but I never knew that you also had to tweak a setting in Windows for it to really be 100% effective. That's imo super dumb and should be auto-detected and change on it's own without the user's manual intervention. I mostly play first person shooters and I'm a perfectionist with my computer so it needs to always be clean both inside my case and on my drives, the OS and Bios needs to be fully optimized, everything that can be overclocked needs to be to reach the most performance out of what I've paid but yet I would still get some stuttering in Battlefield 4 on Ultra 4xAA at 1080P even though I have ~120fps so I wondered wtf was wrong and out of nowhere it appears that I've found the problem. I'm glad I landed on this forum as otherwise I would have never found it! I ran the WinTimer and it goes right away to 0.99 then after about 180 seconds it stays to 1.0 if anyone wonders and here's a part of my specs below. Oh yea I'm on Windows 8.1 64bit btw.

 

Main specifications of my computer:

Processor: Intel i7 4770K @ 4.20Ghz

Motherboard: MSI Z87-GD65 "LGA1150, Chipset Z87"

Memory: Mushkin Redline 2x4Gb DDR3-2133 "9-11-10-28 1.65v"

Video Cards (SLI): Asus Geforce GTX670 2.0Gb "1188Mhz / 7000Mhz, DirectCU II"
                                  Gigabytes Geforce GTX670 2.0Gb "1202Mhz / 7000Mhz, WindForce"

Sound Card: Creative Soundblaster Zxr

Solid State Drive: Samsung 840 Pro 256Gb "Sata-III"

[snaphat (Myles Landwehr) Member]

What is with all of the overly verbose, yet vague, and generally strange posts on this topic all of a sudden? The first contains false analogies (as well as misunderstands how timers work), the second contains absurd claims of increased I/O performance and ridiculous speedups, the third... I'm not really sure what that one is saying. They are all very strange...

[Athernar]

  On 22/03/2014 at 07:59, snaphat (Myles Landwehr) said:

What is with all of the overly verbose, yet vague, and generally strange posts on this topic all of a sudden? The first contains false analogies (as well as misunderstands how timers work), the second contains absurd claims of increased I/O performance and ridiculous speedups, the third... I'm not really sure what that one is saying. They are all very strange...

 

Tweakers are like the pseudoscience "community", they drift around the place like tumbleweed claiming to have the quick solution to get free performance or free energy. Snakeoil 2.0, like Web 2.0 but even more useless.

 

You'll also notice similar sorts of behaviour around core parking in Windows, it fixed some performance issues for some people with specific Intel chips & SMT enabled but now people preach it like it's the solution to everything.

 

"When all you have is a hammer, every problem looks like a nail"

[PanzerIV]

Hmm finaly it seems it didn't make things better or worse. I still get stutter sometime like it's 120fps then suddently going to 60fps and back again to 120fps and no I don't use Vsync.

As for the Core Parking trick, too many people were praising it as if it was magic which I highly doubt but I may give it a try. I could see cores parking while idling or on my desktop which is the point of power saving but why would it do that during intense gaming?! If all my cores are around 65-70C, I highly doubt I have an idle core lol.

 

  On 22/03/2014 at 08:12, Athernar said:

You'll also notice similar sorts of behaviour around core parking in Windows, it fixed some performance issues for some people with specific Intel chips & SMT enabled but now people preach it like it's the solution to everything.

[HawkMan]

  On 22/03/2014 at 06:56, PanzerIV said:

Me too I've registered on that board only to comment about my experience. It's a comment from a post on BlurBusters.com that brang me here. I already had "HPET" enabled since day 1 on my new computer and even did since forever on my previous as I always optimize my bios but I never knew that you also had to tweak a setting in Windows for it to really be 100% effective. That's imo super dumb and should be auto-detected and change on it's own without the user's manual intervention. I mostly play first person shooters and I'm a perfectionist with my computer so it needs to always be clean both inside my case and on my drives, the OS and Bios needs to be fully optimized, everything that can be overclocked needs to be to reach the most performance out of what I've paid but yet I would still get some stuttering in Battlefield 4 on Ultra 4xAA at 1080P even though I have ~120fps so I wondered wtf was wrong and out of nowhere it appears that I've found the problem. I'm glad I landed on this forum as otherwise I would have never found it! I ran the WinTimer and it goes right away to 0.99 then after about 180 seconds it stays to 1.0 if anyone wonders and here's a part of my specs below. Oh yea I'm on Windows 8.1 64bit btw.

 

Main specifications of my computer:

Processor: Intel i7 4770K @ 4.20Ghz

Motherboard: MSI Z87-GD65 "LGA1150, Chipset Z87"

Memory: Mushkin Redline 2x4Gb DDR3-2133 "9-11-10-28 1.65v"

Video Cards (SLI): Asus Geforce GTX670 2.0Gb "1188Mhz / 7000Mhz, DirectCU II"

                                  Gigabytes Geforce GTX670 2.0Gb "1202Mhz / 7000Mhz, WindForce"

Sound Card: Creative Soundblaster Zxr

Solid State Drive: Samsung 840 Pro 256Gb "Sata-III"

 

That's kind of what the default setting does. you just disabled it's ability to detect the other setting that you already disabled in bios...  i.e. you just ate a sugar pill

  On 22/03/2014 at 08:45, PanzerIV said:

Hmm finaly it seems it didn't make things better or worse. I still get stutter sometime like it's 120fps then suddently going to 60fps and back again to 120fps and no I don't use Vsync.

As for the Core Parking trick, too many people were praising it as if it was magic which I highly doubt but I may give it a try. I could see cores parking while idling or on my desktop which is the point of power saving but why would it do that during intense gaming?! If all my cores are around 65-70C, I highly doubt I have an idle core lol.

 

If you're losing half your fps, even if you could tell at those, then something else is seriously wrong, something that effects performance a good deal more than a timer or a single core going idle. HDD seems to be a likely curlprit as they can also cause high cpu spikes and clog up IO. 

[DeepSpaceDoge]

  On 22/03/2014 at 07:59, snaphat (Myles Landwehr) said:

What is with all of the overly verbose, yet vague, and generally strange posts on this topic all of a sudden? The first contains false analogies (as well as misunderstands how timers work), the second contains absurd claims of increased I/O performance and ridiculous speedups, the third... I'm not really sure what that one is saying. They are all very strange...

 

And whats with all this negative comments now? It solved my 2 years old issue with D3.

Ive told about it my friend in D3 who has 2500k on P67 chipset with HD6870 and it solved this problem for him also.

While digging on bnet forums I have found some old posts about hpet and how it helped, so I reposted it few days ago and again there is a positive feedback

If it WORKS then its a good solution. About my I/O performance - I have two old HDDs in raid0 and sequential reads are now like 5-7Mb/s faster - its repeatable with HPET enabled/disabled

[snaphat (Myles Landwehr) Member]

^ Generally, your claims are unbelievable unless there is something majorly wrong in your system. For example, your claims of consistently better I/O performance are rather odd given that modern systems use DMA for transfers and that is completely independent of the CPU. I can't possibly see how a timer could affect such things since timers interrupt the CPU and DMA should continue to go on its way...

 

But, in general, what I found strange was that we had three people register (2 in support, 1 otherwise) very close together and all three made rather grand claims (and reached different conclusions). But, I'll encourage you to document the evidence and post it. We have yet to see any corroborated evidence that forcing the HPET timer affects performance in any way. Every time I ask folks to do this, we simply don't get anything back. 

[The Evil Overlord]

  On 23/03/2014 at 04:54, snaphat (Myles Landwehr) said:

^ Generally, your claims are unbelievable unless there is something majorly wrong in your system. For example, your claims of consistently better I/O performance are rather odd given that modern systems use DMA for transfers and that is completely independent of the CPU. I can't possibly see how a timer could affect such things since timers interrupt the CPU and DMA should continue to go on its way...

 

But, in general, what I found strange was that we had three people register (2 in support, 1 otherwise) very close together and all three made rather grand claims (and reached different conclusions). But, I'll encourage you to document the evidence and post it. We have yet to see any corroborated evidence that forcing the HPET timer affects performance in any way. Every time I ask folks to do this, we simply don't get anything back. 

Some new members are genuine, ala Warwagon's thread about svchost

some just use threads as old as this in an attempt to hide their first post, so to post spam later, (as if that trick ever works)