New AX1200i: Link/Sierra Problems, Questions, and Confusion (not in that order)

[batcrave]

Before posting this, I've prowled around forums a bit and seen a number of rather discouraging, disheartening, and downright distressing discussions... But, in the interests of boundless optimism and a hope for new information (and avoiding any more alliterative 'd' words), I though I'd lay out my problems and see if there are any solutions I've been overlooking, rather than going straight from "Hello, my name is..." to rants, threats, and demands. If it doesn't pan out, I suppose I can always try to work myself up to a screaming tirade later, but those things take such an awful lot of energy.

 

That being said, here's the situation...

 

As the (hopefully) final piece in a long series of hardware purchases motivated by cascading failures, I recently became the proud owner of a shiny new AX1200i. Although, actually it's more of a 'nice matte black AX1200i'. And maybe I'm not quite as certain about the 'proud' part as when I first opened it up (gorgeous packaging, guys - I'm still trying to mop up the sense of luxury that it oozed all over my workbench - that stuff gets everywhere.)... But, at any rate, I'm at least the owner of a new AX1200i, powering a bunch of other nearly-as-new hardware - most of which has a fair collection of kinks in need of working out, so finding a few more with the PSU isn't so surprising as it might've been The AX1200i's kinks seem a tad kinkier than most, though.

 

It's definitely an imposing unit, no shortage of power - but where it has a surplus of brawn, it seems to be suffering a rather tragic deficiency when it comes to brain (unless of course it's my own that's deficient, in which case I look forward to being sent briskly on my way, with a stronger PSU and weaker pride).

 

First, and most frustrating, is that CorsairLINK2 (v2.2.0)'s SierraService - under both Win 7 and 8 - seems determined to make a racket by grinding my poor old spindle drives once every 200ms-1s (I imagine it's doing something similar to the SSDs, but those are polite enough to be quiet about it). Aside from the noise, this also causes my PC to immediately wake again any time that it goes to sleep (and I'm reasonably sure I didn't enable Wake-On-Sleep in BIOS). I would assume this is a result of polling the drive temps, except that I've never encountered it with any other monitoring software. I've seen suggestions that it's a SMART access, although - again - I can't produce a similar effect via SMART polling with anything else (not to mention the fact that it doesn't give any indication of using SMART data). More importantly than the 'what' and 'why' though, is the 'how' of it... Specifically, is there any way to disable it without sacrificing the rest of Link's functionality? I don't particularly need another temperature monitoring package (especially one that doesn't recognize any of the 10+ sensors on the motherboard), but I would enjoy having access to all those nifty power features that were such a great selling point that I sucker punched my better judgement when it told me to buy a cheaper and more conventional PSU.

 

Speaking of those nifty power features, the amperages displayed on the Power tab are... erratic, to say the least - particularly under Win 8. It doesn't give the impossibly high numbers that someone (Boris, maybe?) had seen, but instead it displays - with a fully-loaded CPU and GPU - zeros (or, I suppose, .0s) for all eight rails. Every now and again, usually several seconds apart, one or more of the (rails? pseudo-rails? meters?) - seemingly at random - will display a value for a fraction of a second before returning to zero. On Win 7, the effect is less pronounced - the meters will more often display a steady value, with occasional momentary drops to zero. In addition, there's the somewhat worrying fact that if SierraService fails, is killed, or just doesn't respond, Link acts as if all the levels have remained constant. These aren't so critically broken as the behavior under 8, but they do make it difficult to put much faith in the values displayed. I suppose this one isn't the sort of thing I should expect to find a solution to, outside of a new release - so it can just be filed away with the other bug reports.

 

Possibly related to this (or, well, manifesting near the same readouts, at any rate), the behavior of the OCP sliders has me utterly baffled - and maybe here someone can suggest something I've been too thick to pick up on. I'll freely admit that I have no idea whether it's actually buggy, or if I just don't understand how they're intended to work. It seems that most often (under both 7 & 8) if I check the Enable OCP box with the slider at 40.0A, it will decrement by one every second or so (although the time varies, and it doesn't appear to be synchronized with the other updates), until it eventually hits 19.9.... except that sometimes, it doesn't. At first I thought that maybe it would lower the values if they totaled over the PSU's 100A max, except that it also happened when selecting a lone rail. I thought that perhaps, due to a logic beyond my grasp, it would lower idle rails (as the loaded ones seemed to stay fixed more frequently)... but that didn't prove out either. So, am I stupid, or does it actually not make sense? "C.) Both" is also a valid answer here.

 

Last of all (what? you're still reading this? oops, sorry...), the logging (under Options) seems have broken its leash and run wild. Regardless of the interval or the sensors selected to log, it variably writes out somewhere from 50-60 rows/second. I'm going to guess this is another for the bug file, unless there's an option somewhere that I've overlooked. Also, in the logs I've seen some of the fields output to as many as thirteen decimal places. I have trouble believing they're actually accurate to that sort of degree, but is there any information available on what sort of real accuracy or confidence can be expected from the logs?

 

 

-Bats

(I'm finished. You can stop reading now. I promise.)

[Toasted]

Is the Axi PSU connected via the USB LINK Dongle (Included with the PSU)?

[batcrave]

Is the Axi PSU connected via the USB LINK Dongle (Included with the PSU)?

 

Yep. I'm not sure how I'd be getting any readings at all if it weren't... Unless Corsair has cracked the problem of machine telepathy - in which case all of the results are really pretty impressive.

 

And, I don't think I mentioned it, but the wattage, voltage, temperature, and fan RPM readings do all appear to be correct - or at least within a reasonable margin of what other software (HWiNFO, SpeedFan, AIDA, etc.) reads.

[wemdee]

You might want to read through this thread in regards to the disk writing issue. You can lower the logging level.

 

http://forum.corsair.com/v3/showthread.php?t=111067

[batcrave]

You might want to read through this thread in regards to the disk writing issue. You can lower the logging level.

 

http://forum.corsair.com/v3/showthread.php?t=111067

 

Thanks - I'd skimmed that thread before, but hadn't caught the tip about Sierra2.exe.config. The logging (although enabled rather than disabled) might help tracking down a couple other minor issues, although so far it looks like it doesn't have much to say below the INFO level.

 

Unfortunately though, that seems to have been an unrelated issue with an older version (2.0.16?). It looks like the problematic logging has since been disabled by default, and I'm not seeing anything dumped there or in the event log - or at least not with the regularity of the disk accesses. In my case, there aren't any actual writes happening - or anything at all that Windows' Resource Monitor identifies as disk activity coming from any of the Sierra* components.

 

I should probably also mention that the spindle drives are both strictly storage - CorsairLink isn't installed there, and they hold no system files, logs, or pagefiles that might normally be accessed. The drive light still shows activity when they're unplugged and removed from the system (which may or may not be causing wear on the SSDs, depending on what's happening) but, obviously, it happens more quietly. This, along with the lack of detectable activity, suggests to me that it's not a standard file being read/written to, as that would tend to be limited to a single drive, rather than occurring on any/all attached drives at once.

[wemdee]

I can look at my PC when I get home. I haven't checked lately.

[batcrave]

It seems that most often (under both 7 & 8) if I check the Enable OCP box with the slider at 40.0A, it will decrement by one every second or so (although the time varies, and it doesn't appear to be synchronized with the other updates), until it eventually hits 19.9.... except that sometimes, it doesn't.

 

I'm still in the dark on what exactly is happening here, but I have found that it coincides with an error from C-Link Service popping up in the event log every ~15sec that reads "Unable to write/verify to register 234" (yes, with two 'to's). This happens only when one or more PCIe OCP boxes are checked and counting down. Once the slider stops decrementing (whether at 19.9, or elsewhere) or if the GUI is shut down, the errors stop appearing.

 

Not directly related, but I've also been seeing error events reading "An error occurred with HDD Node Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index". These appear on a similar ~15sec tick, but don't appear to be tied to the GUI being open - although they stop (for a while, at any rate) if Sierra2Service is restarted.

 

Unfortunately, however, these also don't seem likely to relate to the problem of the constant drive accesses. The timing is off (~15sec/ea vs ~2-300ms/ea), and - unlike the above errors - the drives accesses consistently occur whenever (and for as long as) Sierra2Service is running.

[robandcathy]

Your actually to brilliant for me to even want to debate lol but most of what you are experiencing in lame mans terms is the bugs plagued by the software. Besides turning off logging or disabling sirrea2 (which would shut down dashboard) your stuck waiting for the all mighty update to fix all and end all. Sirrea2, netframework and clicking have been the biggest offenders. The link checks status every second of anything it is supposed to monitor. Does not matter if the drives are storage or not if the link software does not jive then you will have that result, hopefully this week it will get updated.

[wemdee]

You should probably try the new version that is now out.

 

http://forum.corsair.com/v3/showthread.php?t=116396

 

Make sure you remove the previous version completely first. It has a folder in your program files folder and under %appdata%.

[batcrave]

You should probably try the new version that is now out.

 

http://forum.corsair.com/v3/showthread.php?t=116396

 

Oops! I've been running 2.3.4816 for a day or so, now... I posted on that thread, but forgot to follow up on this one.

 

To summarize, the new version stopped poking at my drives (or found a more discrete way to do so), which is wonderful. OCP still has the same behavior, and the amperage displays are still erratic - although the latter is significantly improved. Finally, the runaway logging has stopped running away, but introduced new issues (if less crippling ones). Now none of the power options are labeled on the logging tab - just a string of unmarked check boxes - and including my FX-8350's load in the report causes all output to break, writing nothing but a jumbled version of the column titles to the log file.

 

I'm thrilled by the drive polling fix, and the log issues aren't especially critical for me (it'd be nice to be able to relate power to CPU load, but without having an option for GPU load too, it's fairly meaningless - and the missing labels are just a minor annoyance). As for the Power tab, not being able to use OCP should probably make me far more nervous about that massive 100 Amp rail than it actually does (memo to self: do not use screwdriver to clean out handfuls of metal shavings spilled in case). On the other hand, if - after twenty-odd years of poking recklessly at the innards of computers - I haven't caused anything to important to melt, burst into flames, or explode (at least not accidentally), I figure I'll probably survive another release or two on a single rail.

 

So, while I still can't say I'm impressed with Corsair's software division (or those two starving VB coders they keep chained up in the sub-basement), this version is actually useful now, and starting to deliver on more of the AX1200i's promise (and more of Corsair marketing's promises).

 

I am, however, rather heartbroken over the choice to drop the client/service-over-loopback architecture - that looked like it was going to make it so much less of a headache to pull out the PSU monitoring data for external software to use. I couldn't find mention with a cursory search, but is this something anyone else has done any work on? Or are they changing the backend too fast & frequently to bother?

 

 

-Bats

[wemdee]

Good luck. :sunglasse

[hammong]

I have the same erratic amperage display issue that is reported here. I opened another thread with screen shots to illustrate the problem. I have at least 5 of the PCIe plugs connected to devices (4x to GTX 680 cards, 1x to 8-pin EPS+12V) and it shows 0.000A most of the time, and occasionally (every 5-10 seconds) might show 4-6A on one or more of those links. The ATX connector reports 0.000A most of the time as well, and will also occasionally change to 4-6A then back to 0.000A

 

The only time I can consistently get one of those current displays to work, is if I load up the CPU with Prime95, then the PCIe output I am using for EPS+12V will show 14-15A during the full load condition, and go back to 0.000A if I close Prime95.

 

Frustrating considering I bought the AX1200i today and am faced with problems on day #1. I have mine connected to my H100i CorsairLink port, as I'm out of USB headers on the motherboard.

 

 

Greg