View Single Post
  #4  
Old 11-09-2017, 12:13 AM
DevBiker's Avatar
DevBiker DevBiker is offline
CORSAIR Beta Team
DevBiker's PC Specs
 
Join Date: Feb 2017
Location: Republic of Texas
Posts: 7,535
POST ID # = 925775
DevBiker Reputation: 88
Default

Quote:
Originally Posted by SpeedyV View Post
Actually since Corsair decided to remove the SMB Buss interlocks, it is known that if Link is run concurrently with SIV, HWINFO64, AIDA, etc. that there will be strange problems. The author of SIV has stated clearly that since this change was made, you cannot operate Link and SIV at the same time and expect things to work reliably. This was a conscious decision on Corsair's part as they have stated that removing the interlocks was necessary as they migrate to software based LED control as required for the new LL series fans. I have asked for an explanation of WHY the buss interlocks had to be removed but I never received a response. Maybe they will explain it this time.

In short, if you are using the latest version of Link, don't run SIV at the same time. You can exit one and open the other but you can't have both open at one. Same is true for HWINFO64 and AIDA64 for sure. Not sure about other monitoring programs but probably.

I believe Corsair is well aware of this. Not sure what is has to do with the CPUID SDK. Incorrect CPU Core numbering has been a problem for a long time. Also, Link can't report more than 16 cores since it is written as a 32-bit application. So it can't report all cores on an I9-7980XE or many XEON CPUs that have more than 16 cores.

Good luck!
Please ... stop with the totally incorrect information. Corsair isn't doing anything with SMBus interlocks ... they call into the CPUID SDK to get the system-level data and it's the CPUID SDK's job to handle that. Link is written in .NET (probably C# with perhaps a touch of Managed C++ for calls into unmanaged code). You don't have direct access to the SMBus in higher-level managed platforms. Your access to this (and other low-level hardware interfaces) is going to be via calls into libraries like the CPUID SDK.
What they did do is removed the global mutex to control access to their hardware devices and are using a private, in-process SemaphoreSlim instead to ensure that Link only has one thread accessing the Link devices at a time. Since it's Corsair software accessing a device that Corsair made and that is running firmware that Corsair wrote, it is not unreasonable for them to do this. And yes, it can cause problems with third party software that is trying to read those same sensors on the Link device. Now, they've not said why they did this. Perhaps they don't want to play with others. Perhaps they were having issues with other applications grabbing their mutex and not letting Link do it's thing. Or maybe they moved all of the sensor reads to a single process and, not needing to have cross-process synchronization any longer, opted to use a lighter-weight mechanism for thread synchronization. Doesn't matter, really ... it was a named mutex that they created for themselves and never published as an integration point, making it a private API. So any one relying on that private, unpublished, undocumented API can't whine when it goes away. It wasn't published or documented for a reason.
That said, with a little bit of C# and SignalR code, it would appear to be possible to actually use the Link Service to read these sensors AND play nice with Corsair's software ecosystem. Of course, that's an unpublished API as well, so you'd do so at your own risk with the expectation that any change to link could break your integration code.
As for the 64-bit, maybe there is a technical reason for it or maybe they just never changed Visual Studio's default "AnyCPU - 32-bit preferred" assembly flag. What I do know is that, if you know a little about the .NET Framework and CLR as well as the SDK tools, you can run Link as a 64-bit app. But that won't make a difference because it's the service needs run as 64-bit and that doesn't work ... SIUSBXp (the USB Device driver) is a 32-bit DLL. That may not be available as a 32-bit component OR the 64-bit version may not work with all of their devices ... still, it appears to be a technical limitation.
Finally, I will say this ... in the past several months, Link has gotten better. It's a process, not a happening and, with the exception of some missteps with driver signing (ahem), they are definitely heading in the right direction. It's not a small code base and they need to be careful about any incremental improvements that they make so as limit breakages AND keep up with the hardware teams that are throwing new stuff at them all the time.
Reply With Quote


1 members found this post helpful.