Gearslutz.com

Gearslutz.com (http://www.gearslutz.com/board/)
-   Music Computers (http://www.gearslutz.com/board/music-computers/)
-   -   HPET (High precision event timer) ON or OFF ? (http://www.gearslutz.com/board/music-computers/835600-hpet-high-precision-event-timer-off.html)

nms 7th May 2013 01:21 AM

HPET (High precision event timer) ON or OFF ?
 
1 Attachment(s)
What's the story with this these days? Midi timing is crucial due to my use of outboard gear, but I just did a test sequencing an 8 bar midi and when comparing them found no noticeable difference with HPET on or off (in BIOS & OS).

Has this changed on the X79 platform?

I'm curious what the pro DAW builders ADK, DAW PLUS etc are doing here lately.

I do get lower DPC (according to DPC Lat Chk) and less CPU spike activity in task manager with HPET off but can't help but wonder if that has any negative effect elsewhere.

Idle desktop after a few mins with HPET off. I've tweaked this machine (3930k @4.2ghz w/16gb ram @1866) quite a bit mind you:

loopy 7th May 2013 01:48 PM

I'd be interested in hearing this as well. I have it turned off on my Gigabyte UDR3 X58a board because it caused DPC spiking. I never heard or experienced any problems with it on though.

Always wondered if I should turn it back on despite the spiking?

Gear Geek 7th May 2013 08:08 PM

There are absolutely no adverse affects in a pro audio environment when disabling this. Because it was stated that it helps multimedia applications people where scared it would affect audio performance or midi timing which is not the case whatsoever. However, depending on the platform, there can be adverse affects to leaving it on.

DAW PLUS 7th May 2013 11:05 PM

You can turn it off on audio systems. Some boards do not suffer any worse DPC values when left on, though.

nms 8th May 2013 01:55 AM

2 Attachment(s)
Here's a look at the core activity I get with it on vs off after playing back the same section of a project at 128k buffer in my DAW. Disregard the CPU percentage on the left which bounces up and down:

valis 8th May 2013 06:42 AM

Turn HPET on, it's only XP era systems, older hackintoshes and dual core systems CORE-era systems which have all C-states disabled and are running older software where you'd want it HPET off. So this 'fix' was intended for XP era systems initially, and gets constantly rolled into 'DAW tuning guides' as people tend to carry 'fixes' over when they get used to them and 'dont see anything bad' when they implement them on newer systems.

HPET is finer grained than RTC, places a lower load on the system and allows developers to setup easier 1-shot timers and better PER CORE control.

Since RTC is very coarse grained (or places increasing system load as you approach 1ms timers), your time window on 'doing the next thing' (accessing or writing registers etc) may be larger than needed when a thread has finished its current task but has to sit around and wait for RTC to refresh before moving on to the next thing. Basically HPET generates interrupts at a much higher rate than RTC with lower system load, enables timers to be aperiodic (1shot or specifically timed) and enables multithreaded apps that work at finer resolutions than 1ms to implement better per-core control over things that change the state of registers & mapped memory.

XP can actually use TSC & PMTIMER along with RTC to get finer grianed control (if a dev wishes) but on Win7/8 era systems there's NO NEED imo to disable HPET. If you're having issues that this 'seems' to solve it's still driver related and should be solved elsewhere imo.

DAW PLUS 8th May 2013 08:39 AM

Fact is that HPET still is a problem solver on many W7 configurations.
As long as drivers are not optimal, it can be the only way out without no-go side effects.
We don't need to switch off HPET in our current systems, since they A) don't have an issue and B) disabling HPET does not improve anything.

On desktop boards we did see issues which can only be fixed by end users by disabling HPET. In the case of a certain interface, it could not be used when HPET was enabled, no matter whether C states we active or not.

nms 8th May 2013 08:50 AM

Quote:

Originally Posted by valis (Post 9020533)
Turn HPET on, it's only XP era systems,

Well then how do you explain the screenshots I posted above with a nice new 3930k on P9X79 Pro running W7? There's a pretty clear difference shown between HPET on or off and that difference is seen in both CPU spikes and DPC latency. This seems to be quite common. I've talked to people who had issues in gaming systems as well that turned it off to have smoother graphics with less dropped frames.

Here's something I read elsewhere:

Quote:

In general:

- With HPET enabled in both BIOS and OS, idle DPC latency is in the 20-30us range, and generally does not move much under load.

- With HPET enabled in BIOS, but not in Windows, idle DPC latency is in the 5-8us range on my ASUS board (p9X79 WS), and 0-2us on my Gigabyte boards (X58A-UD5 and X79S-UP5-WIFI). Load goes to 20-35us on the ASUS, and stays almost the same as idle on the Gigabyte with the exceptions of rare spikes into the 30-40us.

- With HPET disabled in both BIOS and Windows, idle DPC latency is 0-2us on both brands, load is similar to the above.

Now the real fun starts when I run apps that poll the systems super I/O chip and EPU/VRM controllers:

With HPET fully enabled, programs like HWmonitor, CPU-Z, and just about any other monitoring software produce very frequent spikes into the 300-700us range.

With it HPET fully disabled, spikes only occur once every few minutes, and are of much lower magnitude, about 200-300us.

With regard to differences between the boards, it seems as though the ASUS monitoring chips (Nuvoton et al) produce much more latency while HPET is enabled than the iTE chip on the Gigabyte boards. However, when HPET is completely disabled, the balance shifts back in ASUSes favor.

I never had to disable HPET on my Gigabtye boards, but it seems like a wise thing to do with ASUS. Also, if HPET is necessary for some application, it's critical that any polling of temp/rpm sensors or the like be paused when doing latency sensitive tasks.

valis 8th May 2013 09:41 AM

shitty drivers? Sorry I did not mean to imply that it didn't WORK, I think perhaps I under-emphasized my summary line. DAW plus's response was 100% accurate though, and exactly what I meant.
Quote:

Originally Posted by DAW PLUS (Post 9020720)
As long as drivers are not optimal, it can be the only way out without no-go side effects.
We don't need to switch off HPET in our current systems, since they A) don't have an issue and B) disabling HPET does not improve anything.

I probably should have also conceded that it can help in laptop systems too though. Drivers are something you have less control of in a laptop system obviously. And as an end user since it's such an OEM based market and in the lower end of the desktop market most people don't return things frequently. Sadly, I do if it's not going to work.

There are timers below RTC btw, though anything below the APIC timer is probably emulated by now anyway as I think it's necessary for per-core scheduling to work at all.

nms 8th May 2013 09:49 AM

So are you saying on your machine under identical test conditions you get less CPU spike activity & DPC latency with HPET switched on in both BIOS & OS?
Are you on gigabyte or Asus?

valis 8th May 2013 03:36 PM

Supermicro, and yes but it does depend on the application!

This is a Xeon rig with RME HDSPe soundcard & multiface II, a small collection of USB devices (BCF2k/APC40/MPD32/Nocturn) & 2 midi interfaces (MOTU MTP-AV & MicroExpress). I used to use the MTP-AV to lock to video sources with this board but haven't done that in a while, and HPET was 100% required for reliable HD recording using Black Magic and other 1080p & higher capture cards (so you can run say a DSLR or HDcam's output into it and get full 4:4:4 instead of the codec it saves to). I had sync issues between the audio & video stream when I first built this machine that finally were resolved with HPET on and all APIC/ACPI 2.0 features enabled in bios, full EIST support on (I do my power profiles in windows) and *proper drivers for my hardware*.

Nvidia drivers were a PITA a while back (machine has a quadro 4800 in it atm) as were ANY of the Intel drivers for storage (RST), and I've used only ES.2 & RE4's in this thing for working drives.

I have 1-2 AMD boards from Asus & Foxconn that fare worse obviously, but it's again due to onboard devices that I can disable. I also have an LGA-1155 board here that has smoother core stepping into the lower states (the cores wake faster) but I use that as a render slave for when I do 3d work more than

tombot 8th May 2013 04:48 PM

+1 for disabling HPET on Asus X79 boards. Doesn't seem to make much difference when the system is idle, but under load it really flattens dpc latency off.

Yorrrrrr 9th May 2013 04:00 AM

The trick to enabling HPET and for it to work well, is not only to enable it in BIOS, but also in Windows with the bcdedit /set useplatformclock true command in CMD.exe

More info about this here:

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

Try what I say and compare it to HPET disabled to see if there's any benefit.

IMO it is not neccesary to worry about the DPC latency too much. Just try to stay in green area and you're good to go.

nms 9th May 2013 04:42 AM

Quote:

Originally Posted by Yorrrrrr (Post 9023558)
The trick to enabling HPET and for it to work well, is not only to enable it in BIOS, but also in Windows with the bcdedit /set useplatformclock true command in CMD.exe

Try what I say and compare it to HPET disabled to see if there's any benefit.

IMO it is not neccesary to worry about the DPC latency too much. Just try to stay in green area and you're good to go.

Look a few posts up. That's the difference with HPET on vs off and yes (as mentioned in my first post) it was enabled or disabled in OS as well.

Gear Geek 9th May 2013 03:23 PM

Quote:

Originally Posted by Yorrrrrr (Post 9023558)
IMO it is not neccesary to worry about the DPC latency too much. Just try to stay in green area and you're good to go.

It depends on how low you want latency. DPC has a direct relation to how low you can set your latency given no other variables are the bottleneck. If you want to run 32-64 buffers and your soundcard and system can handle it then anything above around 60-80 microseconds can impact performance. Of course if your CPU or soundcard is the bottleneck then DPC will be less important but the lower latency you need the lower DPC is required for glitch free audio.

valis 9th May 2013 04:12 PM

Quote:

Originally Posted by nms (Post 9023620)
Look a few posts up. That's the difference with HPET on vs off and yes (as mentioned in my first post) it was enabled or disabled in OS as well.

While doing what? What software was loaded? How loaded were your cores and memory bus? Your system bus, sata controllers, and other peripheral devices? Which drivers and what hardware were in use exactly?

My system runs HIGHER dpc latency now than when I had problems capturing video btw, both at idle and under loads that were experiencing issues. But the explanation was that a device was polling too infrequently and then not releasing fast enough, the driver kinda sucked imo (good hardware). Replace device, bingo! New device/driver combo polls quite frequently now, DPC latency shows higher results but data delivery is in fact occuring properly and related i/o buffers are not either empty or full too long, or too large. So a good example of when the metrics don't reflect what you're suggesting, but again I'm monitoring under load NOT idle conditions.

valis 9th May 2013 04:14 PM

Quote:

Originally Posted by Gear Geek (Post 9024546)
It depends on how low you want latency. DPC has a direct relation to how low you can set your latency given no other variables are the bottleneck. If you want to run 32-64 buffers and your soundcard and system can handle it then anything above around 60-80 microseconds can impact performance. Of course if your CPU or soundcard is the bottleneck then DPC will be less important but the lower latency you need the lower DPC is required for glitch free audio.

The thing is DPC Latency is a *metric* to be used as a tool to discover problems, it's not actually in and of itself *the problem*. It's a symptom or indicator of a problem... Ie, any discussion of it should probably refer to information that can help resolve such problems, and not just discover symptoms. System tuning requires testing loads, both artificial and hopefully closer to 'real world' conditions so that you can determine where bottlenecks actually occur.

Going beyond DPC Latency Checker to LatencyMon is a good start, along with other tools that can watch and capture OS, System and process related metrics. I'd love to hear more information on this than just vague hand waving and screenshots of Latency Checker with no comment on the conditions under which screenshots were taken etc.

Gear Geek 9th May 2013 04:21 PM

I agree and maybe should not have stated it as an absolute. It is a metric tool but on the systems I built I have seen a direct relationship in what that the DPC latency monitor showed and audio dropouts at the lowest latencies. Just saying it's very important to keep the DPC latency down as much as possible on pro audio systems contrary to the belief that it does not make much difference.

nms 9th May 2013 09:32 PM

CPU core activity is more important to me than DPC latency checker. I use LatencyMon occasionally as well.
Quote:

Originally Posted by valis (Post 9024684)
While doing what? What software was loaded? How loaded were your cores and memory bus? Your system bus, sata controllers, and other peripheral devices? Which drivers and what hardware were in use exactly?

As I mentioned in the post with the 2 screenshots they were taken while playing back the same section of a project in my DAW at 128k buffer. The screenshots show the core activity over time under load with 3.3gb of ram used. This is a very tweaked build with top performing components. The interface used was my Lynx Hilo, but I observed the same difference in spike activity testing with my Virus Ti as a USB interface.

Quote:

Replace device, bingo! New device/driver combo polls quite frequently now, DPC latency shows higher results but data delivery is in fact occuring properly and related i/o buffers are not either empty or full too long, or too large. So a good example of when the metrics don't reflect what you're suggesting, but again I'm monitoring under load NOT idle conditions.
You replaced a device & driver and had improved performance. I'm not sure how that supports better operational comparison between HPET on/off? Since then have you actually gone and tested it carefully under identical conditions with HPET on/off (BIOS & OS) as I did above? In the images I posted it looks like the polling activity looks a lot more healthy with HPET off on ASUS.

I used a project with 72 tracks in Live 8.34 each containing an instance of Simpler, 2 Ableton reverbs, one Fabfilter Pro-Q, an instance of The Glue on every 8th channel, 4 active reverb sends (Lex PCM native, CSR, Ableton)being fed by all channels, and my usual master channel plugins (Fabfilter Pro-L, Pro-Q, The Glue). This is a benchmarking project I use containing the plugins I usually use.

I'm interested in uncovering and verifying more of what goes on with HPET in current machines as there are no shortage of conflicting reports.

It didn't take me much time to do the test I did in my second post. If anyone wants to debate HPET I would ask that you help us out by doing a test of the same manner and posting it as that is much more useful than talk. From what I've read the results can go either way depending on manufacturer.

1. with HPET enabled or disabled (in both BIOS & OS) reset machine
2. open a DAW project at a section that places high enough load that you are near the point of drop outs
3. hit play and let it play for 16 bars then take a snapshot of windows task manager to show the core activity over that time

then go run CMD and enable or disable HPET in the OS, restart into BIOS to change that, and repeat the test above.

CMD lines again for easy reference:

bcdedit /set useplatformclock true (enables HPET)
bcdedit /deletevalue useplatformclock (disables HPET)

valis 9th May 2013 10:46 PM

Quote:

Originally Posted by nms (Post 9025666)
CPU core activity is more important to me than DPC latency checker. I use LatencyMon occasionally as well.

They're both metrics basically, so your input was interesting. Which is more important again is something you weigh against a *specific set of circumstances*, given load/app etc. Which isn't to say you didn't, but clarifying that for others avoids the 'simple rule of thumb' approach which leads us to an industry that uses RTC for the next 12 decades...ok I'm exaggerating a bit

Quote:

Originally Posted by nms (Post 9025666)
You replaced a device & driver and had improved performance. I'm not sure how that supports better operational comparison between HPET on/off? Since then have you actually gone and tested it carefully under identical conditions with HPET on/off (BIOS & OS) as I did above?

I had sync issues, but LOWER results in DPC Latency Checker in terms of DPC timing under load. In fact if you watched the incoming feed on a monitor (software or hardware off component output) you could VISIBLY see it stutter and drop frames or corrupt blocks. RTC solved this but was barely able to keep audio & video sync when running at full 4:4:4/29.967 with 48khz audio. HPET enabled ran fine, once I changed devices. The problem was NOT a defective device, they had a new controller in the newer unit (one would think) and a completely different driver.

4:4:4 hdmi/component input isn't the most demanding thing in the world for systems anymore, but the old device was having problems. RTC was INDEED checked & verified but it's too coarse grained for what I was doing. Ie, I'm not interested in whether RTC would have fixed the problem, as RTC is the *lowest* clock that will work for video/audio sync, not the *best*.

HPET works fine with the newer device but *shows higher DPC Latency Checker figures*. Hence my example, it's not intuitive as per the 'general rule of thumb' in these threads. The system I'm referring to is obviously not just a laptop running ableton though or a typical desktop, so it's just an example for sake of discussion.

Quote:

Originally Posted by nms (Post 9025666)
I'm interested in uncovering and verifying more of what goes on with HPET in current machines as there are no shortage of conflicting reports.

And I'm addressing why there are conflicting reports to some degree, no? It's going to depend entirely on the components & drivers in your system. I would think those vary quite a bit across the forum/web sampling pool for this subject.


Quote:

Originally Posted by nms (Post 9025666)
It didn't take me much time to do the test I did in my second post. If anyone wants to debate HPET I would ask that you help us out by doing a test of the same manner and posting it as that is much more useful than talk.

1. with HPET enabled or disabled (in both BIOS & OS) reset machine
2. open a DAW project at a section that places high enough load that you are near the point of drop outs
3. hit play and let it play for 16 bars then take a snapshot of windows task manager to show the core activity over that time (or any similar utility in MAC)

then go run CMD and enable or disable HPET in the OS, restart into BIOS to change that, and repeat the test above.

CMD lines again for easy reference:

bcdedit /set useplatformclock true (enables HPET)
bcdedit /deletevalue useplatformclock (disables HPET)

First, Be careful with HPET if you're rebooting into your hack first off (you mentioned OSX). Know why first...(RTC patch etc depending on the age of your hack)

Second, that useplatformclock command I *think* forces all clocks off the HPET which will cause worse issues. I'm suggesting having it available in the bios so that properly coded drivers & software can work in tandem to utilize it is probably a *good* thing, and that debugging your system if HPET causes problems probably is too. I'm not suggesting "HPET forced on is always best" and I suspect a proper sample of users will show that. We'll see.... So perhaps people should add some more configuration information too.

The real question is what devices are at issue, and there's plenty of threads that delve into this out there already. Nvidia & ATI drivers, certain wifi cards or even onboard NICs (broadcom/realtek etc) and possibly certain driver versions...

nms 9th May 2013 11:16 PM

For me the relevant part isn't whether HPET is enabled in OS, but rather whether it's enabled in the BIOS or not. It seems to enable and disable fine that way for me and I noticed no difference with the command lines. My device manager lists it only when enabled in BIOS.

I've heard that for people working in video HPET is a different story, but we're focusing on performance in audio production here. Oh and I don't use a mac, I just meant obviously mac users have different monitoring tools, though I don't really care what goes on in mac land personally so I've edited that out.

I believe there are consistent results to be found when looking at HPET on/off for for DAW use in Windows 7 without getting into network cards or wifi (wifi shouldn't be on anyways). If you have problem components in your system (graphics, network cards etc) that's something you need to sort out. I guess you could say the basis of this discussion is about HPET on/off in a good system which isn't suffering from component problems.

I think it's clear by now that the only way to know for sure what works best in your system is to test it yourself. I would just like to see some factual results from tests like what I posted above so we can get a more real picture. The one thing you haven't seemed to mentioned yet Valis was an example of testing it under identical conditions in your current working machine (since changing out bad hardware & drivers) with HPET on/off. Until you've done that I think it's perhaps a bit hasty to invest much into the debate.

valis 9th May 2013 11:29 PM

I did enabled/disable RTC, I was sure I mentioned that somewhere but it may have been lost in editing. These long winded responses are murder on an iphone tbh. Anyway the result was that video blocks were serviced before timeout conditions (dropping data) but the audio sync was problematic. Combine that with external hardware you need to lock to....or have locked to you.,...

And I wasn't suggesting whether HPET forced on is relevant to YOU, just giving my impressions of what it will achieve (worse performance most likely, just try a 1080p flash video on youtube or html5 on vimeo and you'll see how well your gpu drivers fare on forced HPET alone).

It's not a different story for video though, the problem is in tuning your system so that i/o interrupts can be serviced without compromising your cpu-bound load and other i/o tasks going on at the same time (gpu to screen, mouse input, midi devices on usb etc in the case of audio).

Ie, I know of no DAW that services only an audio card's buffer and cpu cores for the DAW software, and my example isn't supposed to refute or support anything beyond that thesis. Discount it for having sync issues specifically between two streams of data one of which YOU don't use, but it's still relevant of the overall situation imo. Device & driver stack dependant imo.

Gear Geek 10th May 2013 12:24 AM

Missed that your earlier example was about video. Sorry but the whole thing is totally not relevant since we are talking about audio. I don't think the OP was looking on theory or an explanation of HPET, but rather if it is better to turn it off on a pro audio PC, specifically under Windows.(even though that was not stated it seems an obvious given)

valis 10th May 2013 12:28 AM

Exactly my point, hand waving. The underlying principles are the same and I am *not* debating a pro/con but illustrating examples. Tbh I have work to do, you guys have fun. I don't run $150 motherboards anyway with crap components so you're right this probably isn't relevant to me after all...

nms 10th May 2013 12:44 AM

Quote:

Originally Posted by valis (Post 9025916)
I did enabled/disable RTC, I was sure I mentioned that somewhere but it may have been lost in editing.

I only caught where you mentioned doing the enable/disable tests before getting rid of your problematic hardware. I don't think anyone here cares about how HPET worked for you then compared to after you straightened out your machine. And yes specifically how it worked for audio use as we are in the music computers section of a recording website!

I find it can get to be a waste of time when too much time is spent on chatter without taking a few minutes to actually test something carefully to show factual results.

Quote:

I don't run $150 motherboards anyway with crap components so you're right this probably isn't relevant to me after all...
How is that relevant to anything here? I mean if we're pulling 'em out my machine beats what you're running yet clearly I and others in audio production have some interest in the HPET debate. Instinctively, disabling something called "high precision event timer" isn't something I do without worrying I may be causing some detrimental effect I'm not aware of yet.

valis 10th May 2013 02:43 PM

Your machine 'beats what I have running' lol. Sigh... The argument put forth when I suggested that we look first at our peripherals and onboard devices to solve DPC problems is repeatedly either 1. mobile devices don't allow this latitude (conceded & true) or 2. people are attempting to tune midrange desktop systems already built (ie, "Do I run Asus or Gigabyte"). If I built a system and had to disable modern functionality (like Haswell in current form) just to get it stable, that seems counterproductive to...really just me? Ie, why I'll skip boards until a stable revision, same with chipsets, cpu's etc. Every product has a long list of errata but USB sleep issues & PCI/PCIe bandwidth issues are easily avoided imo, as are devices which have horribly coded drivers and/or outdated controllers.

And my point about introducing the case where a hardware change meant my DPC Latency figures went HIGHER but stability was achieved for my capture stream is NOT invalid as it precisely demonstrated something I wanted to relate. The central point was to refute "DPC Latency values should always be lower", not because it's a true/false statement but because the GOAL is NOT "lower DPC Latency values" it's "remove performance bottlenecks" right? Hence leading to your question of whether disabling HPET (setting back to RTC) is "better" in some way.

Video devices ARE still i/o bound just like audio, and in many cases the i/o is magnitudes higher AND includes audio along with the same conditions as audio devices, so the stress on the cpu, system bus and i/o interrupts is that much more. In fact since it's capturing MORE than one stream of data the test case here is actually closer to either utilizing more than one card (where the driver supports multiple cards like RME) or alternatively getting a UAD/Powercore based system stable with low latency.

Imo this was an obvious case where a time-critical high interrupt i/o condition was having issues and the developer and I tried several 'fixes' including. "just disable HPET to improve performance" is being bandied about here. In fact that WAS one of the things we tried I learned really quickly that RTC has horrible timing (~1ms of resolution) and so you'll forgive me for being leery of timing my cores on a timer like RTC even if it seems to give 'lower cpu usage' or 'lower dpc latency figures'. The main thing is that HPET timers shouldn't be used anyway by a dev unless they need the added resolution (core threading is a good case, as is sub 1ms accuracy for timing critical events). And the TRADEOFF will unsurprisingly be a bit more load on the interrupt/procedure calls as RTC only sets a register it does NOT trigger an interrupt.

And fwiw you have no clue who I am or what I do, nor should you. But between 20+ years of using Windows & Mac I've done plenty of commercial (broadcast) audio & video work for major regional ad campaigns (Ford, Betty Crocker, Nike, sports teams etc) as well as EDM & 'geetar' music since the early 90's. I've had multiple platforms over the years from HP/UX to SGI to DOS/Amiga trackers to Atari/MacOS. I've also helped develop a bit of DSP for Scope DSP systems (some years ago), dealt with troubleshooting EXTREME cases of PCI bus congestion with DSP systems for BOTH video & audio and so on. So I've worked across a fair number of fields as both an end user, a developer, a researcher and one who had to maintain the systems involved in each as well. I've worn enough of the hats to be willing to speak up consistently on these forums, and I'll point to my past track record here (or at other forums) and let the record speak for itself. And I recall when it was the "rule of thumb" to "always disable ACPI" for most soundcards, DSP cards and especially my SCOPE cards. Incidentally I was *always* able to achieve stability without doing so, though it might have required avoiding certain chipsets and onboard peripherals (sound familiar?)!

Currently I've got 3 audio workstations here (including a laptop) and multiple video machines, they are in no way dissimilar until you start dealing with specific applications. The initial build & benchmarking process (to identify shitty components) is the same for the most part. So the idea that the HARDWARE invalidates my discussion is stupid imo, i/o interrupts and base timer conditions are no different.

Tuning for the end-application can certainly be different too. Premiere, After Effects, Maya or Softimage is different in each case and different again from PT, Live or Cubase (on Win). I'll surely concede that! But Tuning the HARDWARE in my experience is not so different, unless you're using SLI systems with CUDA cards perhaps... which is a good example because Nvidia's drivers seem to handle multiple card sync poorly with HPET on (whether you're doing SLI or 2-3 CUDA cards). But since vendors with a more vertical footprint (and less broad base of hardware to satisfy) are able to sync multiple devices just fine with HPET enabled (be it blackmagic capture cards or RME's HDSPe products) I'm still suggesting the fault is NOT with HPET and the 'fix' should only be used if you have no other recourse.

So discount my input if you want but I'm willing to bet that my example and thesis is correct: checking your DPC latency values is simply a metric to be used to troubleshoot, NOT a benchmark that always 'improves performance with lower values'. Disabling HPET might also "improve performance" but I'll state one last time, this would be largely due to a device in your system that might possibly be 'fixed' in several other ways (including disabling or replacing it). And there multiple ways in which HPET can be an advantage, though there are always tradeoffs obviously, and those decisions SHOULD be left to the developer who hopefully builds a product that's of enough quality to be a sound investment. Should that not be the case, move to a different product imo!

nms 10th May 2013 05:56 PM

Quote:

Originally Posted by valis (Post 9027510)
Your machine 'beats what I have running' lol. Sigh...

I use an OC'd 3930k on P9X79 Pro. You got all dismissive saying none of this matters to you because you don't run crappy $150 motherboards that nobody here has indicated they do.
Quote:

The argument put forth when I suggested that we look first at our peripherals and onboard devices to solve DPC problems is repeatedly either 1. mobile devices don't allow this latitude (conceded & true) or 2. people are attempting to tune midrange desktop systems already built (ie, "Do I run Asus or Gigabyte").
What? I didn't say either of those things. You know Asus & Gigabyte are motherboard manufacturers right? I didn't think it would be like pulling teeth to simply have a discussion about HPET on current fully functional DAW machines. I don't care to get into wifi or network cards because wifi doesn't belong on a desktop DAW and you can't change them on laptops. If you lose all focus the thread becomes pointless just like it seems to have now unfortunately.
Quote:

I'm still suggesting the fault is NOT with HPET and the 'fix' should only be used if you have no other recourse.
Well there are a whole lot of people finding issue with it and I don't think you can look at my core activity above and say it's better for my machine as the polling looks much healthier with it off.
Quote:

So discount my input if you want but..
Well as of yet it hasn't been input that's been informative to the purpose of this this thread.

I built my machine with top quality components that are known to be solid for DAW use, and expectedly it's fully functional so I have no interest in changing out any hardware over HPET.

I didn't want to get into a big discussion with you if it was not about music computers running music production apps and didn't really want to get into how your machine worked before you got rid of bad hardware. Too much time wasted on pointless discussion. I've heard nothing about how your machine worked with HPET off AFTER you sorted out your hardware.

Without focus things go nowhere fast and you end up having wasted time and learned or verified nothing.

If anyone else would like to try the simple test I mentioned and post it along with mobo model please do.

valis 11th May 2013 10:29 PM

Quote:

Originally Posted by nms (Post 9028033)
I use an OC'd 3930k on P9X79 Pro. You got all dismissive saying none of this matters to you because you don't run crappy $150 motherboards that nobody here has indicated they do.
What? I didn't say either of those things. You know Asus & Gigabyte are motherboard manufacturers right? I didn't think it would be like pulling teeth to simply have a discussion about HPET on current fully functional DAW machines. I don't care to get into wifi or network cards because wifi doesn't belong on a desktop DAW and you can't change them on laptops. If you lose all focus the thread becomes pointless just like it seems to have now unfortunately.
Well there are a whole lot of people finding issue with it and I don't think you can look at my core activity above and say it's better for my machine as the polling looks much healthier with it off.
Well as of yet it hasn't been input that's been informative to the purpose of this this thread.

I got dismissive because I was outlining what we're measuring (how long it takes to service an i/o task in many cases) by measuring DPC Latency and gave a specific example of when higher values are a GOOD thing. This discussion is more than just you and I however and you're not the only person I'm responding to. Honestly what was frustrating is having portions of a discussion cherry picked to dismiss anything but what you're after. I am a bit tl;dnr about this but we've gone in circles a bit too...

Quote:

Originally Posted by nms (Post 9028033)
I built my machine with top quality components that are known to be solid for DAW use, and expectedly it's fully functional so I have no interest in changing out any hardware over HPET.

I never said you needed to do that, I said the FIRST place to start is determining WHY you have higher latencies under HPET than RTC. Start with the source, deal with possible solutions next. RTC has load advantages since i'ts just a register and not an interrupt, but it has disadvantages too! Again I see this on so many

Quote:

Originally Posted by nms (Post 9028033)
I didn't want to get into a big discussion with you if it was not about music computers running music production apps and didn't really want to get into how your machine worked before you got rid of bad hardware. Too much time wasted on pointless discussion. I've heard nothing about how your machine worked with HPET off AFTER you sorted out your hardware.

YOu deem it pointless, but again this is a multi-party discussion that's atm being dominated by only 2-3 players. I've in no way said people shouldn't "do your test" but use something beyond DPC Latency Checker please, this is NOT a benchmarking contest. Or make it that lol...

WonG. 7th February 2014 02:40 PM

Hey nms,

how to reach such low latencies? Can you give me some tweaking tips?


All times are GMT +1. The time now is 09:50 AM.

SEO by vBSEO ©2011, Crawlability, Inc.