Jump to content

DevBiker

Members
  • Posts

    10,127
  • Joined

  • Days Won

    31

DevBiker last won the day on June 3 2022

DevBiker had the most liked content!

Reputation

254 Excellent

Converted

  • Interests
    Getting as much done as possible with as little effort as possible.

Converted

  • Occupation
    Being lazy. Being impatient. Feeling hubris.

Recent Profile Visitors

8,693 profile views
  1. You don't need more. You can drive 6 fans directly from the hub. Maybe even all 7 with a splitters. Running the front and side fans together (at the same speed) would probably work well and simplify things. You'd want the rear exhaust to kick up a bit more than the airflow fans. Completely do-able with the CoCoreXT and the hub.
  2. @Deemster - That sounds like short circuit protection. Are you using ONLY the cable that came with the PSU? Do not use your old ThermalTake cables.
  3. No, that looks good. You'll only need a single Link controller to handle that as well. What I can't say is if you need additional cables and somethings that's hard to say until you build it. But what I would definitely recommend is that you plan out the cables and how you are going to do the daisy-chains of the fans. That'll be a start to think about any splitters, hubs or extensions you may need.
  4. First, can you identify what controllers you have in the case? My sig has a link to a video that will help you identify what you have. But ... my first guess would be that they either aren't connected to a controller or connected incorrectly. But let's get a list of what you got before we go there.
  5. You can ... they are certainly optional. They do provide better airflow and are also a good place for radiators in exhaust configuration.
  6. Have you tried a full power-off shutdown and cold boot? Have you changed the USB port (again)? Do you have any other monitoring tools installed?
  7. I don't, not regularly, at least. But ... I've got 128GB on my main machine and frequently run 3-4 Virtual Machines at a time. And I really only look at it to get an idea of just how much of that 128GB is consumed by my VMs, though HyperV manager gives me a better idea of how much each individual VM is using. The few hundred MB of memory that iCUE uses isn't even a consideration. In the grand scheme of things, it really isn't that much. Firefox, Chrome, Edge ... all of them use a metric cr*p ton more memory - with 7 tabs open, Firefox is consuming 3.8GB in Task Manager right now. iCUE, honestly, is a pittance. And don't even get me started on the memory that Visual Studio uses. That app is truly a hog. But I digress. The number that is shown in Task Manager is the Private Working Set and includes all physical memory that the application has currently allocated, not necessarily how much it is actually using. It is not uncommon for apps to allocate more memory than they currently need ... memory allocation is expensive and doing this is actually a performance tuning trick (trading memory for performance ... a very common trade off and one I make often, tbh ). Additionally, this is only pageable memory - memory allocations that have been swapped out to disk aren't included. It does, however, also include the memory allocated for memory mapped files (like resources ... which are all of the images and, at high resolution, they are quite large). If memory usage is too high or physical memory is scarce, the Windows memory manager will swap memory from the Private Working Set to disk (the 'swapfile'). And while memory mapped files are addressable by the application, they aren't necessarily in active memory - they're just 'mapped' to it (hence the name). So ... that memory you are so concerned about will be swapped out if you actually need it and it hasn't been accessed recently. That does, however, come with a performance hit - though far less with current NVMe drives than with good ol' spinning rust. The magic of Windows Memory Manager written by those excellent engineers at Microsoft that you referred to does that for you. Close the iCUE window and much of that memory you see in Task Manager can be swapped out. The nonpaged pool, which is memory that cannot be swapped out, is 217K. That number is far more important, too, as Windows cannot release that from physical memory if needed. It can swap the Working Set out and release the physical memory if it needs to, though the application may appear to 'hang' when that happens, especially if your swap file is on spinning rust. That's not a good user experience. The memory manager is also lazy. It won't swap unless it really needs to. When your total system-wide usage is < 50% ... well, the memory manager just ain't gonna do diddly-squat 'cuz there ain't no need for that nonsense. Finally ... as a 64-bit application, it's going to take up more memory than a 32-bit application, simply because all of the handles are twice the size. There is just no way around that one. And, as a 64-bit application, it has 256 TB of addressable memory (which has nothing at all to do with how much RAM is physically installed). Task Manager really isn't a good tool to use to dig into the details of memory usage or to determine if you have a leak. It can give you a general idea but it's gooey and you can't rely on it when reviewing memory usage. Windows memory management, overall, is kinda gooey due to the virtualization and other tricks (like the shared page pool and the aforementioned memory mapped files). Instead, there are specialized tools that provide far more detailed information on memory usage and tracking down leaks. Personally, as a .NET developer, these days I use JetBrains dotMemory (and, to a lesser extent, dotTrace) for analyzing memory usage and issues ... QT has these tools as well. No developer in their right mind uses Task Manager to determine if there are issues with memory usage and that is why these tools exist. But ... again ... when optimizing the application, memory usage isn't the top priority. User experience and rich functionality are. So if they need to allocate a few more classes and a bit more data to improve the user experience and functionality, they're gonna do it. There are always trade offs in software development and, for the most part, memory is the least of our worries in most applications and the one most easily (and quickly) traded for other priorities. Back in the 16-bit days of Windows 3.1 - when I started writing software - the story was very different. But we usually have far more physical memory available then is needed so it's not a big deal ... and most of the devs that have started coding in the past 15 years or so just have absolutely no concept of optimizing memory - they don't learn that in college and it's not usually necessary these days. All of that doesn't mean that they ignore it and, as I said previously, it's gotten a whole lot better. I guess that's a long way to say that you really don't need to worry about it and ... worrying about it is kinda pointless, tbh.
  8. Well ... I'm not quite so sure about that. While I do think that Microsoft's RGB is interesting, I don't think it will eliminate specialized software like iCUE. Like the built-in mouse driver or the built-in display driver, it'll provide a set of baseline functionality but lack advanced features that you would find in specialized drivers/applications. If you look historically at how Microsoft operates with these types of Windows added components, that's what they do. And they do it only when it becomes a large enough mass for it to be interesting to them. They'll provide the core platform and basic functionality and leave it to 3rd parties / partners to build on that baseline. Really ... that's just Microsoft's entire business model in a nutshell. Where I do see it really adding value is providing a common API that the 3rd party applications can plug in to - this will open up the ability for one application to run RGB from multiple vendors ... although support for other vendor's tools may not be as rich as support for your own tools. But that, in itself, would be a huge improvement over the fragmented market that we have now. Will Corsair support it? If what I say comes to pass (and it may not), they will. They may do it kicking and screaming but the market will demand it. As for iCUE's memory usage ... the biggest part of that is the QT runtime that they use for the user interface. It's a rich, flexible UI framework but it does use a bit of memory for all of the UI objects (similar to a WPF or Java application). They also keep history of your sensor readings (for the display graphs). Even though that's likely down-sampled, it still uses memory. Now, on the Corsair side, they do have a focus on providing a rich user experience with their tools ... and so they will lean more towards look and feel over memory usage when balancing design decisions. That's just the nature of software development - it's always a balancing act between multiple competing priorities and you have to decide what your highest priorities are. And, of course, their target market is going to be higher-end enthusiasts ... who will likely have more memory on their system ... and that's also a factor in the balancing act. That said, memory usage has gotten significantly better, especially with the new modular design. Of course, the more Corsair devices that you have, the more memory it'll use as well. For example ... right now, on the laptop that I'm currently using with only a Virtuoso headset and a Dark Core Pro SE mouse, memory usage with Desktop open and in the foreground is about 230MB. That's really not bad in today's world of software. My desktop ... which is decked out with a TON of Corsair stuff and using video murals, will consume a good deal more memory ... because there is much more going on. Could I reduce it? Sure ... I can set hardware lighting and just close iCUE. I could turn off video murals. But I want the richer effects that I get with full iCUE and I like murals ... and those things cost memory. Now ... if your focus is to provide basic functionality and optimize memory usage, you could do that too ... and wind up with an interface that feels like it's 1995 all over again. Those apps exist out there and they have their purpose. But the market for iCUE is not that ... and the competition is not that.
  9. Just shows how old we are, eh? 😛
  10. The Capellix coolers won't connect to the new iCUE Link system. However, if you have the Link system, it will work alongside your cooler and you'll control both from iCUE. @muvo is, I think, referring to the older Corsair Link software that used to be what we used for inside-the-case devices once upon a long time ago.
  11. With the temp sensor - is that the source temp for your fan curves? And you don't 'see' hardware mode. For the fan control, it happens behind the scenes. But you can absolutely set the Commander Core to start fans at startup; that's exactly how mine was configured for a long time before I switched to the Link system.
  12. It is intentional; it is not broken in the least. The pin that is missing is for the Data Return signal (back from the fan) and is used for daisy-chaining the fans. With a splitter, you don't need it on all of them, just 2 of them. The connector with the missing 3rd pin is the last fan in the chain.
  13. Well, saying that based on this thread misses a lot. The reality is ... for the folks where it works, you never hear anything. Personally, I have four of the capellix coolers on various systems and have never seen this issue. While it is a problem, it's apparently random and it most certainly does not happen with all ... or even most.
  14. Well, we can probably help get a solution for this but I'll need a few more details. If you have the Commander Core XT, that's the standalone right? You don't have an Elite cooler, correct? So what cooler do you have? And - more importantly - how do you have the fans configured once you log in? What is the control variable? iCUE, btw, runs when you log into Windows as one of your user profile's startup apps and does not start until a user profile has logged in to Windows. There is a Corsair Service but it is far more limited in scope than iCUE is. That said, most of these devices also have a hardware mode and THAT is what we need to check and tweak. For the Commander Core, this will work if the control variable for the fan is a sensor that is on the Commander Core itself. Not CPU temp ... not GPU temp ... it has to be one of the 2 temp sensors that you have on the Commander Core XT. They are standard 10K temp sensors - so inline temp sensors in a custom loop work just fine. Alternatively, you can also use the radiator exhaust temperature as a control variable using one of the temp probes that comes with the XT. That'll take a bit of playing around but it's can be used as a proxy for your coolant temp. So ... there are options. Provide a little more information and we'll see if we get something figured out.
  15. Yes, you can. You need to add a layer on top of your chosen settings and apply it *only* to the fans that you want to dim. The layer should be in the custom section - Static Color. Set it to black and slide the opacity back and forth to dim the fans to your liking. You actually have more control over it this way vs. using the slider in the device settings.
×
×
  • Create New...