The Corsair User Forums

The Corsair User Forums (https://forum.corsair.com/forums/index.php)
-   Corsair Link (https://forum.corsair.com/forums/forumdisplay.php?f=209)
-   -   Corsair Link 4.9.1.23, H115i - Incorrect # of Fans & Temp Sensors (https://forum.corsair.com/forums/showthread.php?t=172231)

TevleGnirheg 11-07-2017 05:19 PM

Corsair Link 4.9.1.23, H115i - Incorrect # of Fans & Temp Sensors
 
Corsair Link 4.9.1.23 has resolved some issues. Other issues I have and is a known issue is the incorrect fan count and incorrect temperature sensor count.

I can repeatedly get the fan count to be correct and then incorrect.

Steps:
1) Reboot the machine
2) Start Corsair Link (enter the admin password depending on machine configuration and user one is logged on as)
3) Corsair link displays 6 temperature sensor readings and 8 fans, with fans 5 to 8 having rpm readings between 8000 and 33000. (Fans 5 to 8 are what I refer to as ghost fans and they are magically quiet)
4) Kill Corsair Link (right click on Corsair Link icon in task bar and select exit)
5) Start SIVX64 or SIVX32 as Administrator
6) While SIV64X is running start Corsair Link up again
7) Now Corsair Link only show 3 temperature sensors and a total number of 4 fans with sensible rpm readings.
8) At this point one can kill SIVX64/32 and Corsair Link and check the processes in the Windows Task Manager to ensure that nothing is running in the background.
9) Start Corsair Link and it functions correctly (Correct number of temp sensors and fans).
10) Reboot the machine and one has to start at step 1) again to rectify the problem.

My Question is:
What is SIV64X/SIV32X doing that results in Corsair Link being able to detect the temp sensors and fans correctly, where Corsair Link has been started from scratch after SIV64X was started?
This, however does not fix the incorrect CPU core numbering.

I feel that SIV64X contains the missing link to resolve the issue at hand.

Refer to attachments posted on 11-06-2017, 09:52 AM at http://forum.corsair.com/forums/show...=171244&page=2

Corsair Dustin 11-08-2017 01:22 PM

SIV doesn't use the CPUID SDK to my knowledge. Again, those are issues with the CPUID SDK's reporting since, as you said, these things appear in HWMonitor as well.

We continue to fold in new versions with new fixes as they become available.

SpeedyV 11-08-2017 04:14 PM

Quote:

Originally Posted by Corsair Dustin (Post 925734)
SIV doesn't use the CPUID SDK to my knowledge. Again, those are issues with the CPUID SDK's reporting since, as you said, these things appear in HWMonitor as well.

We continue to fold in new versions with new fixes as they become available.

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!

DevBiker 11-09-2017 12:13 AM

Quote:

Originally Posted by SpeedyV (Post 925756)
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.

LicSqualo 11-09-2017 03:10 AM

Quote:

Originally Posted by DevBiker (Post 925775)
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.

... completely wrong :eek:... you are new here? :D:

SpeedyV 11-09-2017 10:56 AM

Quote:

Originally Posted by DevBiker (Post 925775)
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.

You are correct - they removed the Global\CorsairLinkReadWriteGuardMutex. I apologize for misspeaking. It's clear from your post that you are more knowledgeable about the inner workings of Link and the environment it operates in. Thanks for sharing your insights.

TevleGnirheg 11-09-2017 11:27 AM

Contrary to what I read above, SIVnnX (nn = 32 or 64, makes no difference on a 64bit platform) works perfectly well. Intel's Extreme Tuning Utility and SIVnnX report fans and temperature sensors correctly. I find no problem running SIVnnX concurrently with Corsair Link.

Starting SIVnnX first ensures that Corsair Link detects the correct number of fans and temperature sensors.

Without SIVnnX being started first, Corsair Link does not function correctly.

After Corsair Link is started you can terminate SivnnX and Corsair Link then continues to function correctly.

Unfortunately I have to shut down my machine and when I restart I repeat the work around from scratch. This is a pity as the product seems quite good. It is only the link software that let's the side down. I want to buy additional components but just cannot justify spending anything until it all works as intended to without requiring a work around. An example I need a device like commander pro to control several fans.

Does this not provide any clues or are we at the situation where most developers sometimes get to when one is desperately trying to resolve an issue and you can't see the wood for the trees.

What is SIVnnX doing right that Corsair Link is not doing at all?

Corsair Dustin 11-09-2017 01:31 PM

We had to choose to break the mutex to get software playback. That's the short version.

The medium-length version is a little more complicated but it basically works like this:

There are products that we straight up wouldn't be able to use a mutex with (or at least not easily) because they require continuous software control (i.e. LL fans). While we do want to support third party applications and obviously as a company enjoy the benefits of the open platform that is the PC, we also are obligated to provide the most stable software we can, and we do not have infinite resources.

Our choice on where to direct our resources came down to this:
1. Expend substantial time and energy working on the mutex and other code to ensure third party applications can monitor and control Corsair products.
OR
2. Expend time and energy implementing new features, supporting new products, and -
most importantly in my opinion - fixing bugs.

With respect to the hard work done by other software vendors, our priority is always going to be making sure our software and products work and work well.

TevleGnirheg 11-09-2017 01:55 PM

I am just as eager, as I am sure all at Corsair are, to get Corsair Link to function as intended. Mentioning Intel Extreme Tuning Utility is just to illustrate that it works perfectly OK. SIVnnX as far as I understand, is a utility used to check the system and comes from Corsair. Correct me if I am wrong. It also functions OK. Why I mentioned the steps I tried is also to show that somehow running SIVnnX has a positive outcome on the way Corsair Link works.

My aim is to remove all fans from the main board headers, install Corsair Commander Pro and drive all fans through that where I am hoping to have better control over cooling.

SpeedyV 11-09-2017 01:57 PM

Running SIV then Link
 
Quote:

Originally Posted by TevleGnirheg (Post 925674)
Corsair Link 4.9.1.23 has resolved some issues. Other issues I have and is a known issue is the incorrect fan count and incorrect temperature sensor count.

I can repeatedly get the fan count to be correct and then incorrect.

Steps:
1) Reboot the machine
2) Start Corsair Link (enter the admin password depending on machine configuration and user one is logged on as)
3) Corsair link displays 6 temperature sensor readings and 8 fans, with fans 5 to 8 having rpm readings between 8000 and 33000. (Fans 5 to 8 are what I refer to as ghost fans and they are magically quiet)
4) Kill Corsair Link (right click on Corsair Link icon in task bar and select exit)
5) Start SIVX64 or SIVX32 as Administrator
6) While SIV64X is running start Corsair Link up again
7) Now Corsair Link only show 3 temperature sensors and a total number of 4 fans with sensible rpm readings.
8) At this point one can kill SIVX64/32 and Corsair Link and check the processes in the Windows Task Manager to ensure that nothing is running in the background.
9) Start Corsair Link and it functions correctly (Correct number of temp sensors and fans).
10) Reboot the machine and one has to start at step 1) again to rectify the problem.

My Question is:
What is SIV64X/SIV32X doing that results in Corsair Link being able to detect the temp sensors and fans correctly, where Corsair Link has been started from scratch after SIV64X was started?
This, however does not fix the incorrect CPU core numbering.

I feel that SIV64X contains the missing link to resolve the issue at hand.

Refer to attachments posted on 11-06-2017, 09:52 AM at http://forum.corsair.com/forums/show...=171244&page=2

Quote:

Originally Posted by TevleGnirheg (Post 925811)
Contrary to what I read above, SIVnnX (nn = 32 or 64, makes no difference on a 64bit platform) works perfectly well. Intel's Extreme Tuning Utility and SIVnnX report fans and temperature sensors correctly. I find no problem running SIVnnX concurrently with Corsair Link.

Starting SIVnnX first ensures that Corsair Link detects the correct number of fans and temperature sensors.

Without SIVnnX being started first, Corsair Link does not function correctly.

After Corsair Link is started you can terminate SivnnX and Corsair Link then continues to function correctly.

Unfortunately I have to shut down my machine and when I restart I repeat the work around from scratch. This is a pity as the product seems quite good. It is only the link software that let's the side down. I want to buy additional components but just cannot justify spending anything until it all works as intended to without requiring a work around. An example I need a device like commander pro to control several fans.

Does this not provide any clues or are we at the situation where most developers sometimes get to when one is desperately trying to resolve an issue and you can't see the wood for the trees.

What is SIVnnX doing right that Corsair Link is not doing at all?

HUh. I have never heard that running SIV first and then opening Link would cause Link work correctly, or differently at all. My understanding is that since Corsair "broke the mutex", running SIV and Link concurrently was a no-no. Yet you are saying that running SIV, then Link, then closing SIV, results in Link reporting fans and temps correctly, which it does not do if you do not run SIV first before you open Link. I have no idea why that would be happening. I know who would know but he is not available for comment.

SpeedyV 11-09-2017 02:00 PM

This SIV??
 
Quote:

Originally Posted by TevleGnirheg (Post 925823)
SIVnnX as far as I understand, is a utility used to check the system and comes from Corsair. Correct me if I am wrong. It also functions OK. Why I mentioned the steps I tried is also to show that somehow running SIVnnX has a positive outcome on the way Corsair Link works.

Are we talking about the same SIV? This SIV?

http://rh-software.com/

TevleGnirheg 11-09-2017 03:04 PM

Quote:

Originally Posted by Corsair Dustin (Post 925821)

With respect to the hard work done by other software vendors, our priority is always going to be making sure our software and products work and work well.

This forum is meant just for that purpose. To raise awareness of issues experienced outside at the consumer coal face as it were. I do accept that with limited resources it will take time to resolve. The difficulty is identifying the root cause and directing enough resources to resolve these issues.

I have been through many software development and conversion projects where one tests the code till you are blue in the face and when it is placed into production all hell breaks loose.

Recently participated in an upgrade to Maximo software running on IBM AIX Power8 severs connecting to Oracle 12cR1 databases at a National Utility company and all stress tests provided us with a false sense of achievement in terms of performance. Post Go-Live the performance was dismal and totally unexpected, so yes I understand the immense pressure all at Corsair may be faced with.

Technobeard 11-09-2017 04:55 PM

Quote:

Originally Posted by TevleGnirheg (Post 925823)
SIVnnX as far as I understand, is a utility used to check the system and comes from Corsair. Correct me if I am wrong.

SIV did not come from Corsair.

TevleGnirheg 11-10-2017 05:24 AM

SpeedyV, Yes that is the SIV I am referring to.

TevleGnirheg 11-10-2017 05:35 AM

On some or other posting I came across this software being mentioned. Somehow I picked up that output from this is helpful in determining a problem. SpeedyV, it actually works on my system as described.


All times are GMT -4. The time now is 07:19 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.