Jump to content

DevBiker

Members
  • Posts

    10,135
  • Joined

  • Days Won

    31

DevBiker last won the day on June 3 2022

DevBiker had the most liked content!

Reputation

255 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,778 profile views
  1. Can you show us how the fans are configured in the Cooling section in iCUE? Please make sure to include what profiles/presets the fans are using and, even more importantly, what the source temperature is for those presets.
  2. There is no connector to plug strips into the Link hub. The GPU one would technically work for 14 LEDs but that's it.
  3. Well, this is what I saw there when I selected 140mm option. Just keep in mind that there really should be an asterisk here as it is only with low profile memory ... so it's tight.
  4. Both indicate that you can put a 280 in the top. One caveat though - you'll need low profile RAM. So it does depend on your RAM.
  5. All of this, dude? Seriously? And the entire waste of good electricity that this generated? You really need to get a hobby other than making tin foil hats. And no, I'm not a Corsair employee.
  6. I've heard a rumor (on reddit, from one of the Corsair mods) the rear one is for some kind of external connection for Link devices. Not sure about the one on the bottom with the fans.
  7. Just as @LeDoyen said ... PCIe, EPS, and peripheral cables are the same through the Corsair line. Only the ATX differs. Type 4 PCIe and EPS may have the inline capacitors but those aren't necessary. The pinouts for everything except the 24-pin ATX motherboard connector are the same between Type 3 and Type 4. It's a big reason why all of my PSUs are Corsair.
  8. Exactly which H100 do you have? There are several "flavors" of H100. If it supports iCUE, it will come with the controller that you need. This version: https://www.corsair.com/ww/en/p/cpu-coolers/cw-9060053-ww/h100-rgb-240mm-liquid-cpu-cooler-cw-9060053-ww does not support iCUE control; it connects to the motherboard and is controlled by the motherboard RGB.
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. You can ... they are certainly optional. They do provide better airflow and are also a good place for radiators in exhaust configuration.
  14. 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?
  15. 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.
×
×
  • Create New...