genetix

Thanks for the reply that solved everything.

How is the Sandy Bridge Z68 board multiplier calculated. According to AIDA64 ratio is 32:3 (8:1 by CPU-Z). Set is: CPU 4700Mhz (x47) DDR3 2133Mhz Board(P8Z68-V) is at 100.0Mhz So, from what is that calculated ? (10,665 x 100 = 1066.5 x Double Data Rate = 2133Mhz <- Just doesn't make any sense where the 8:1 comes from.) or is the memory controller always 266Mhz Quad pumped (x4) 1333Mhz which would make 2133Mhz DDR3 2333 / 266 to be 8:1. ---------------- Also while at it.. Would also like to say that PSU voltages are off. * 5V is reporting 5.591v (by BIOS and on ASUS Probe this is 5.096v) * 12V is reporting 7.843V (by BIOS and on ASUS Probe this is 12.072v and max droop on OCCT ain't even over 0,072v) * -5V gives me -2.485V (by BIOS and on ASUS Probe this is -5.048v) * There's VBAT voltage shown which is kinda weird.

It's not the HPET. Tested it up a bit and there's no change on latency jumps. Most be something else. -located- Well, it seems this issue is releated to S.M.A.R.T. values scan, if I dump 'SMART Dump' I get 3 bars every time all over 130K(μs). Even if I disable the at AIDA64 stability the 'Low Level SMART operations' the SMART values are still at AIDA64 and so is harddrive temperatures. This is some Gigabyte own design of reading smart even through Intel RAID. This cannot be disabled by the BIOS. NOTE: I do suspect there's more than just the S.M.A.R.T., but would need an build where this is not read to verify where the next hanging section could be located. (as said these is most likely more than 1 issue as I said on my original post). -edit- * Loading 'PCI Bus Operations' causes jump ~65K(μs) * Issues could be also caused by OCZ Agility 2 'known issues' at scanning S.M.A.R.T. 'B0' (what ever this is ;P), but this cannot be disabled by the board. -edit- It's not the OCZ Hard drive S.M.A.R.T. issue. Removed the OCZ harddrive and cloned the root to Intel RAID-0 with Samsung F1's. Problem seems to be at the Gigabyte unique S.M.A.R.T. for ICH10R as problem occures at 2 places: Storage > SMART and at Sensor pages. There is a smaller jump at 'Motherboard->ACPI', but that's still on green limits and assuming this is normal.

That's actually quite curious idea. Wondering since I am using 64-bit HPET by BIOS could that actually be causing this need to test the theory. As for enhanced C states well that quite long reach I'd say considering these are timed events and updates happening every 3 seconds pretty much makes sure no event would power save in this time (well other that something like CPU). But really need to check on HPET state and see powercfg.exe for raise hardware wake-up events and see where the lag starts to appear. Although, system is at full performance mode and even HD internal states are disabled. Including all CPU power saving states and all PCI-E power save states except GPU power saving states. What's wrong with 10.1.0.1008 ? I know there's quite an bug in these or well actually it's not the Intel drivers, but their ICH10R Option ROM has bug which when caching is dropped drops also Disk internal read caching which was pretty hilarious to try to solve over Gigabyte support I might add since neither Intel Support nor Gigabyte support couldn't solve the Option ROM to only drop write caching when asked and not the read caching while at it.

Yeah, that goes for PR, but was referring what exactly was causing the issue. Seems if I uncheck all the stability section except the kernel mode driver the DPC latency lowers to ~20-30K instead of 60-130K jumps. So most be multiple issues there. Further I go down from Stability section more specifically SMBus section checked we yet again get the 60-13K jumps. However, it still jumps quite a bit even on Kernel Mode Driver enabled and not else.

Nope, no easytune nor any other releated tools installed or extra drivers (checked by 'autoruns') on background. No OC.

Yeah, understand, but don't you think it's just a little bit weird this doesn't happen on Everest ? Most also be something really small like some ACPI check but the checks are already unchecked while installing AIDA64, however, when I visit the area of information seems the jumps come more regularly there while going through information. heck, if I wouldn't know better I could read through several topics on forums like: and I bet these are all caused by same looped check somewhere.

Well, dunno if this is Gigabyte releated, but got here GA-X58A-UD7 Rev. 2 board and also clearly DPC latency caused by AIDA64. The Program runs for 60 seconds even and DPC jumps to 60000-135000 every HW scan AIDA64 makes. Tested v1.20 and v1.50 and both AIDA versions causes this. Same does not happen, if I run HWMonitor or any of the other tools and this doesn't seem to happen when I run Everest 5.50. Why I think this is Gigabyte releated is because this does not happen on ASUS-P5E (x38) or ASUS-P6T (X58) boards at all. Only way to stop the DPC jumps is to stop kernel driver from AIDA64 even disabling all other checkmarks on stability section doesn't help.