batcrave Posted March 11, 2013 Share Posted March 11, 2013 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.) Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.