I will report this to HQ. Patch could be a while if they can get the card. Some card readers do create detection issues during POST.
Printable View
thank you Shammy, this board has been a blast, waiting for a rampot but in the mean time . . .
http://i.imgur.com/Q5ZtZ.jpg
Thanks, Raja, for your help here.
Passing on some info -- a few of us on OCN have had some odd voltage popup warnings using Aida64, AI Suite, and the P8Z77-V. For me, both the voltage popups and the anti-surge shutdown (though I only had 1 of these) went away after uninstalling AI Suite. (My bios is 0906.) Otherwise, great board!
Also, there has been some discussion there on Vdroop and LLC -- I was wondering if Digi+ control of the VRMs improves undershoot in the transition from idle to load. I noticed your guide recommends 50% LLC -- could you provide any more details on the pros/cons of LLC choice related to minimum stable load voltage and temps?
Is there no way to adjust VCCIO on the non-ROG boards? I've got a P8Z77-V here and am quite surprised that this option is missing, seems to be missing for the Pro as well.
This seems like a really bad joke to me... Thanks for the input though!
They probably just didn't see it. Lets wait for Raja's comment.
That's why I posted, I'm not jumping to any conspiracy theory conclusions just yet. Actually, I was gonna use the board to disprove some of those conspiracy theories ;) Might need to get another board now though...
Use only one monitoring tool at a time, as they all poll the super IO at the same time. You can also turn off AI suite from polling some of those rails to prevent the misreads if those voltages are beign read by another tool.
As for LLC: I find 50% to be optimal from a thermal perspective. Full load voltages should be around the same (close) regardless of which LLC level you choose, while idle VID will need adjustment to ensure that the target VCC is adequate under full load. Technically, higher levels of LLC require a faster switching frequency and/or bulk capacitance to maintain overshoot and undershoot thresholds. While these are all accounted for in the levels we provide, I find myself sticking with a middle of the road approach as it is kinder to components.
I only have the Deluxe here but HQ tells me: Adjust VCCSA to adjust VCCIO. VCCSA is provided by a stepdown reg off VCCIO. When VCCSA is at stock so is VCCIO. On IB VCCSA/IO adjustment does not seem to do much. I think most vendors have done this (or something a little more crude) on their lower end boards that supply IGP voltage.
-Raja
Yeah I've experienced the same issues with AIDA64 and a P8Z77-V. I've made a post on the Asus forums and received the same advice - to only use one monitoring software. Its does seem a bit weak though? I've never had these issues before on p67 (asrock) or older 775 Asus boards. I am currently on 1050 Bios and latest AI Suite but atm I've disable the alerts (antisurge is still active). I've had one anti surge shut down in 72 hours.
If it really is more than one software polling issue then the official documentation should alert people of this.
Will the issue ever be resolved? or is it just don't use programs like Aida64. After all every single video demo with JJ for Asus has Aida64 used the stability and monitoring tool? How can you advise against something on one hand then use it yourselves?
Hi,
Without sounding rude, maybe a more pertinent question is how many ways does one need to monitor the same voltage at the same time? That's why a workaround is provided in the tool to stop it monitoring rails that other tools can be used for if one likes having many things open or in-use at once (one can also select which modules to install in AI Suite).
-Raja
Yeah but its still tripping the anti surge protection with probe 2 uninstalled from AI suite.
Its not just the voltages - it has also told me I have a negative degrees C motherboard temp.
Note also - JJ from Asus uses Aida64 too in his demos..
I've also raised this with Aida64 tech support.
Don't get me wrong great board - just struggling with this issue.
AI suite CPU temp is DTS offset for PECI. Again if you are polling this aggressivley with any other tool it will misread (even more if system is under full load of stress tests). The Super IO can only serve one request at a time, where two polling tools over lap one of the tools used will misreport.
JJ used the tool but that does not mean his system did not misreport if he allowed both to poll at the same time. He knows about this as well as I do. I don't use both to monitor at the same time and that sorts it for me.
When you install AI suite deselect the modules you intend to hand over to AIDA or if you can alter the polling interval aggression until it does not misreport. If you cannot, the only option is to use one tool, even if that appears "weak".
As for the system trip, how do you know it was down to Anti-Surge?
-Raja
Thanks for a more detailed response.
Don't get me wrong I love the product but it seems like greater resilience 'could' have be built into the AI suite to have it work nicely with other 3rd party monitoring software. I also know that we are talking about a fraction of Asus motherboard owners who actually use other software and it comes down to a cost/benefit scenario - I can understand.
Now that I am going to disable the AI Suite Probe 2 - what other settings do you suggest so the Anti Surge protection doesn't kick in? Although it seems greatly reduced as I've only have 1 in 72 hrs. Just disable it in the UEFI?
The PSU is new (1mth old) and its a corsair ax850 - so a pretty decent quality unit. It hasn't given me any issue with my last P67 system running the same CPU and GFX. Are you saying the two systems (probe ai suite and anti surge) are not linked? The poster above also had anti surge kick in too (although only once).
hi!
just got my sticks of tridentX F3-2400C10D-8GTX paired to a 3770K & Maximus V Genez77
the problem is, ram wount run @ stock settings wich are 2400mhz 10.12.12.31 2T 1.65v
each time i try mainboard gives back 33 error and loops between on & off, what is causing this?!
cpu is @ stock speed.
Thanks.
Let me explain this in more detail, because the effects can be much worser than you have currently seen (negative voltage report, warning). It's also not just about how many monitoring tools one needs to run concurrently.
The EC controls much more things (than system monitoring) including crucial parts of the machine. The conflict one experiences when running more tools concurrently is because of the nature of the EC-Host interface which is a pretty old KBC IO method that lacks advanced synchronization. So if there are more clients trying to talk to the EC concurrently, they can break the protocol. It might happen that the EC receives invalid data from host in such scenario and this can can cause all sorts of unpredictable results including serious system faults. That's also one reason why this issue should be handled.
One can have the AI Suite running and just try another tool which talks to the EC too and it can result in such situation. So it's not necessarily about having more applications running for monitoring the same rails.
I'd like the industry to understand this caveat of EC protocol and pursue different access methods for EC (shared BRAM for example, or something else depending on EC model), but I understand this is not easy.
So at least implementing a simple global inter-application mutex into applications willing to handle this situation (and sync) is the least effort (max 5 lines of code).
Double post.