15.02.2025, 00:58
Change Language
Register
Login
You are not logged in.
Wednesday, December 4th 2024, 2:23am
I am happy to hear that my rambling post was helpful.
Calitemp sensors require Aquabus, so now I understand why you need the Aquaero. I have been meaning to add temp sensors so I can have Aquasuite calculate the amount of power (in watts) that my rads are dissipating but I haven't gotten around to doing it yet. I have It set up in the Playground but used constants for the rad temp inputs (for testing). I exported the setup and tried to attached the .XML file to this post but the forum said its an invalid file extension, so I attached a picture of it instead. You may already know how to do the calculation but if you don't, this may help. I do have some concern about how accurate the calculation would be because my temp sensors are just regular 10K thermistors that are not extremely accurate. I would invest in Calitemp sensors but I don't know if I would buy an Aquaero controller. While they are great controllers, IMHO they are a bit outdated. I, like many others, am hoping that Aquacomputer will release a new Aquaero controller with a much more powerful MCU and a color screen. Since the 5.25" drive bay is not common in modern case designs, but little stats displays are, I think the new Aquaero form factor should be a 1920x480 color touch screen with a power cable and a data cable that connects to a remote box with all the connectors on it that can be mounted in the back of the case somewhere. Just my opinion, but maybe Aquacomputer will consider it.
Fan speeds before Aquasuite is running - The PWM ports on the Octo controller have a user adjustable Fall Back slider that you can set if the port is set to Target Temperature or Curve Controller. The Octo will use this speed until Aquasuite is up and running. I don't know if the Quadro also has this feature. The Quadro manual does not mention this control but neither does the Octo manual. Here is a screen ship showing the Fallback power setting. It's all the way at the bottom of the Fans tab and only appears if the port is in Target Temp or Curve Controller mode.
Quadro Aquabus Address - I don't know, and since I don't have a Quadro or an Aquaero, I can't try it. Maybe someone from Aquacomputer will chime in here, or someone who knows or has the same hardware. If it works, I wouldn't worry about it.
Pump Speed - I use the delta-T between ambient temp and coolant temp as the control source for my fans but I leave my pump at a constant speed. Some people (including Sven at Aquacomputer) think doing this is pointless but it works well for me because where I live, seasonal temps are very different. Despite my AC unit's best efforts, the ambient temp in my home office with multiple computers running can very by up to 10°C. When the room is warmer when I boot my computer, the coolant is also warmer so if I just used coolant temp to control the fans, they would run faster for no reason. Heat exchange between the coolant and the air is not going to happen until there is a temperature difference no matter how fast the fans are spinning. This does not apply to the pump so I don't see any reason to vary its speed. If you think there is something be gained by varying pump speed, go for it!
Splitting the High Flow Next Signal output - I don't see why this would not work but I also don't know how you would do this unless you built a custom cable. The High Flow Next Signal connector is quite small but the D5 Next Fan/Flow connector is just a regular 4-pin PWM connector. I guess you could buy 2 cables #53294 and plug the D5 Next end into a 4-pin PWM splitter cable, then plug each leg of the splitter into your 2 pumps. If the D5 Next Fan/Flow input has a high impedance, which it probably does, I don't see why it would not work. If you try it, post and let me know!
Internal USB2.0 Hub - The Hubby7 is a very nice USB hub, and the option to power the ports with SATA or USB power is a nice feature. There are cheaper ones on Amazon but I have read too many reviews with horror stories about these cheap hubs smoking and sometimes damaging the motherboard. The only other one I trust is the NZXT AC-IUSBH-M3. I have a few of them and they work great. I am generally not a fan of NZXT but this USB2.0 hub is a well designed product.
Good luck with your system, and let me know if you manage to get the High Flow Next signal into both D5 Next pumps. I am the only person I know of who has actually set this up so its nice to know that someone else thinks its worth doing. I will mention that when I first did it, the flow rate did not match what my High Flow Next reported. I asked about this and was told that they changed something in the software that required them to also change values in the D5 Next hardware, which they had not done yet. Sven told me that the D5 Next has very limited Flash memory and they were having problems getting new firmware to fit. He said they would not release a firmware update just to fix this problem since its rare that anyone uses it, but they would take care of it the next time they updated the firmware. They finally fixed it when they releaesd Aquasuite X.78. The release note says they did it in the High Flow Next firmware so maybe they decided to adjust it there instead of in the D5 Next. Whatever they did, it now works.
Calitemp sensors require Aquabus, so now I understand why you need the Aquaero. I have been meaning to add temp sensors so I can have Aquasuite calculate the amount of power (in watts) that my rads are dissipating but I haven't gotten around to doing it yet. I have It set up in the Playground but used constants for the rad temp inputs (for testing). I exported the setup and tried to attached the .XML file to this post but the forum said its an invalid file extension, so I attached a picture of it instead. You may already know how to do the calculation but if you don't, this may help. I do have some concern about how accurate the calculation would be because my temp sensors are just regular 10K thermistors that are not extremely accurate. I would invest in Calitemp sensors but I don't know if I would buy an Aquaero controller. While they are great controllers, IMHO they are a bit outdated. I, like many others, am hoping that Aquacomputer will release a new Aquaero controller with a much more powerful MCU and a color screen. Since the 5.25" drive bay is not common in modern case designs, but little stats displays are, I think the new Aquaero form factor should be a 1920x480 color touch screen with a power cable and a data cable that connects to a remote box with all the connectors on it that can be mounted in the back of the case somewhere. Just my opinion, but maybe Aquacomputer will consider it.
Fan speeds before Aquasuite is running - The PWM ports on the Octo controller have a user adjustable Fall Back slider that you can set if the port is set to Target Temperature or Curve Controller. The Octo will use this speed until Aquasuite is up and running. I don't know if the Quadro also has this feature. The Quadro manual does not mention this control but neither does the Octo manual. Here is a screen ship showing the Fallback power setting. It's all the way at the bottom of the Fans tab and only appears if the port is in Target Temp or Curve Controller mode.
Quadro Aquabus Address - I don't know, and since I don't have a Quadro or an Aquaero, I can't try it. Maybe someone from Aquacomputer will chime in here, or someone who knows or has the same hardware. If it works, I wouldn't worry about it.
Pump Speed - I use the delta-T between ambient temp and coolant temp as the control source for my fans but I leave my pump at a constant speed. Some people (including Sven at Aquacomputer) think doing this is pointless but it works well for me because where I live, seasonal temps are very different. Despite my AC unit's best efforts, the ambient temp in my home office with multiple computers running can very by up to 10°C. When the room is warmer when I boot my computer, the coolant is also warmer so if I just used coolant temp to control the fans, they would run faster for no reason. Heat exchange between the coolant and the air is not going to happen until there is a temperature difference no matter how fast the fans are spinning. This does not apply to the pump so I don't see any reason to vary its speed. If you think there is something be gained by varying pump speed, go for it!
Splitting the High Flow Next Signal output - I don't see why this would not work but I also don't know how you would do this unless you built a custom cable. The High Flow Next Signal connector is quite small but the D5 Next Fan/Flow connector is just a regular 4-pin PWM connector. I guess you could buy 2 cables #53294 and plug the D5 Next end into a 4-pin PWM splitter cable, then plug each leg of the splitter into your 2 pumps. If the D5 Next Fan/Flow input has a high impedance, which it probably does, I don't see why it would not work. If you try it, post and let me know!
Internal USB2.0 Hub - The Hubby7 is a very nice USB hub, and the option to power the ports with SATA or USB power is a nice feature. There are cheaper ones on Amazon but I have read too many reviews with horror stories about these cheap hubs smoking and sometimes damaging the motherboard. The only other one I trust is the NZXT AC-IUSBH-M3. I have a few of them and they work great. I am generally not a fan of NZXT but this USB2.0 hub is a well designed product.
Good luck with your system, and let me know if you manage to get the High Flow Next signal into both D5 Next pumps. I am the only person I know of who has actually set this up so its nice to know that someone else thinks its worth doing. I will mention that when I first did it, the flow rate did not match what my High Flow Next reported. I asked about this and was told that they changed something in the software that required them to also change values in the D5 Next hardware, which they had not done yet. Sven told me that the D5 Next has very limited Flash memory and they were having problems getting new firmware to fit. He said they would not release a firmware update just to fix this problem since its rare that anyone uses it, but they would take care of it the next time they updated the firmware. They finally fixed it when they releaesd Aquasuite X.78. The release note says they did it in the High Flow Next firmware so maybe they decided to adjust it there instead of in the D5 Next. Whatever they did, it now works.
Monday, January 13th 2025, 4:01am
Thanks much Speedy-VI for this info!
I finally have this system setup and working nicely. Even with Furmark running on the GPU, and Prime95 running on all cores of the CPU, the system is still very quiet with all fans sitting at around 1000 rpm! Super happy with this result! Sharing a few details of the configuration...
To recap, my loop has the following in this order:
Setup of virtual sensors to calculate Delta Temps...
For Ambient temp, I used two regular 10K temp sensors mounted just inside the rear intake case fan, and took an average between the two (not really necessary though):
Delta CPU Temp measured between water temp at the CPU rad out calitemp and ambient:
Delta GPU Temp measured between water temp at the GPU rad out calitemp and ambient:
Delta Temp Max is just the maximum value between Delta CPU Temp and Delta GPU Temp. This is used for case fan and pump speed controllers:
Below is the virtual sensors for CPU Power (GPU Power is the same except it uses a GPU temp reference instead). The specific heat for water is around 4,200 J/KG*C. However, with that value, these virtual sensors did not produce the same watt values as reported from hardware. I found that a specific heat of around 3,500 produces roughly the same output for the CPU, which you can see 283W from HWinfo and 285W from the virtual sensor (with Furmark and Prime95 running at a stead-state). For the GPU, a specific heat of 4,000 (not shown) produced an equivalent 448W from the virtual sensor vs. 452W from GPU-Z:
In an attempt to feed the signal from the High Flow NEXT to both pumps and the motherboard, I created this splitter:
After connecting it up, I was able to feed the flow signal to both pumps and get the same reading as the High Flow NEXT. However, this is where I realized it's really not possible to feed both the pumps and motherboard fan header at the same time. This is because you have to set the type of output specifically in Aquasuite under "Alarms":
In the end, I didn't really need the flow rate at each pump after all, and I needed the signal for the motherboard (to be able to handle a low/no flow condition in IPMI). Also, the motherboard was not able to read the RPM until the pumps where disconnected. You can see below from the IPMI dashboard, the moment the pumps were disconnected the RPM signal was picked up properly:
For fan and pump speed controllers, I setup Set Point (a.k.a. Target) controllers. I always used curve controllers, but I did not know these are actually PID controllers, which is fantastic!
For fans, these are all on a QUADRO which is connected over aquabus. So the controllers live in aquaero. The source for each controller is the the corresponding Delta Temp virtual sensor (from above). After loading the system and tweaking the target temp, I found 4C is able to keep the thermals under control with fan speeds still at around 1000 rpm. For the PID profile, "Normal" works just fine:
Each pump got the same speed controller as the case fans from above (Delta Temp Max as source and 4C target), except the controllers live with each pump since the pumps are not connected over aquabus:
For load testing of the system and tweaking the controllers, I ran Furmark for the GPU and Prime95 (Blend mode) for the CPU. Below is a series of charts from Aquasuite showing the various power and temps of each component. These are all running the same test which starts from a cold idle, runs Furmark and Prime95 for about 30 minutes, and then runs until all heat is dissipated from the system and reaches a cold idle again...
This is the CPU and GPU temps as reported directly in hardware from each. Temps spike immediately, reach a stead-state, and then drop immediately when the apps are stopped:
This chart shows a comparison of CPU power from hardware, the virtual sensor, and the built-in Aquaero power consumption calculation. The virtual sensor uses a specific heat of 3,500 as mentioned above. When compared to power reported directly from the CPU (CPU Package), calculated CPU Power rises gradually because it's based off of Delta CPU Temp, which takes time to absorb the heat before reaching steady-state. It's the same case except reversed when the load is removed:
Same chart below except this is for the GPU. A specific heat of 4,000 for the virtual sensor correlates nicely with the hardware reading in GPU-Z (GPU Package) once the test reaches a steady-state:
This chart shows the two Delta temperature virtual sensors for the CPU and GPU. We can see the Deltas rise and fall gradually with the load, same as the power calculations from above. Also, after the Deltas go beyond 4C, this is where the fan and pump speeds kick in and maintain the 4C target!:
Power % and RPM for the fans and pumps. These charts all behave similarly as they are all based of the Delta Temp virtual sensors:
I found that a flow of 80 l/h is sufficient for this configuration at idle or light usage scenarios. At this speed, the pump is at 35% power and consumes only 5.6W each. Great! However, I decided to configure the pumps to ramp with Delta Temp CPU and GPU all the way to 100% power, to be able to keep temps and fan noise as low as possible under load:
I finally have this system setup and working nicely. Even with Furmark running on the GPU, and Prime95 running on all cores of the CPU, the system is still very quiet with all fans sitting at around 1000 rpm! Super happy with this result! Sharing a few details of the configuration...
To recap, my loop has the following in this order:
- Pump: D5 Next (#1)
- CPU: AMD TR 3975WX 32-core, Heatkiller waterblock
- Radiator: Thermochill 120.3 360mm
- Radiator: Thermochill 120.3 360mm
- Pump: D5 Next (#2)
- GPU: NVIDIA 4090 FE with Bitspower SOLO and Bitspower backplate waterblocks, front and back
- Radiator: Hardware Labs Black Ice SR2 560mm radiator
- Radiator: XSPC 360mm radiator
- Radiator: Hardware Labs Black Ice SR2 560mm radiator
Setup of virtual sensors to calculate Delta Temps...
For Ambient temp, I used two regular 10K temp sensors mounted just inside the rear intake case fan, and took an average between the two (not really necessary though):
Delta CPU Temp measured between water temp at the CPU rad out calitemp and ambient:
Delta GPU Temp measured between water temp at the GPU rad out calitemp and ambient:
Delta Temp Max is just the maximum value between Delta CPU Temp and Delta GPU Temp. This is used for case fan and pump speed controllers:
Below is the virtual sensors for CPU Power (GPU Power is the same except it uses a GPU temp reference instead). The specific heat for water is around 4,200 J/KG*C. However, with that value, these virtual sensors did not produce the same watt values as reported from hardware. I found that a specific heat of around 3,500 produces roughly the same output for the CPU, which you can see 283W from HWinfo and 285W from the virtual sensor (with Furmark and Prime95 running at a stead-state). For the GPU, a specific heat of 4,000 (not shown) produced an equivalent 448W from the virtual sensor vs. 452W from GPU-Z:
In an attempt to feed the signal from the High Flow NEXT to both pumps and the motherboard, I created this splitter:
After connecting it up, I was able to feed the flow signal to both pumps and get the same reading as the High Flow NEXT. However, this is where I realized it's really not possible to feed both the pumps and motherboard fan header at the same time. This is because you have to set the type of output specifically in Aquasuite under "Alarms":
In the end, I didn't really need the flow rate at each pump after all, and I needed the signal for the motherboard (to be able to handle a low/no flow condition in IPMI). Also, the motherboard was not able to read the RPM until the pumps where disconnected. You can see below from the IPMI dashboard, the moment the pumps were disconnected the RPM signal was picked up properly:
For fan and pump speed controllers, I setup Set Point (a.k.a. Target) controllers. I always used curve controllers, but I did not know these are actually PID controllers, which is fantastic!
For fans, these are all on a QUADRO which is connected over aquabus. So the controllers live in aquaero. The source for each controller is the the corresponding Delta Temp virtual sensor (from above). After loading the system and tweaking the target temp, I found 4C is able to keep the thermals under control with fan speeds still at around 1000 rpm. For the PID profile, "Normal" works just fine:
Each pump got the same speed controller as the case fans from above (Delta Temp Max as source and 4C target), except the controllers live with each pump since the pumps are not connected over aquabus:
For load testing of the system and tweaking the controllers, I ran Furmark for the GPU and Prime95 (Blend mode) for the CPU. Below is a series of charts from Aquasuite showing the various power and temps of each component. These are all running the same test which starts from a cold idle, runs Furmark and Prime95 for about 30 minutes, and then runs until all heat is dissipated from the system and reaches a cold idle again...
This is the CPU and GPU temps as reported directly in hardware from each. Temps spike immediately, reach a stead-state, and then drop immediately when the apps are stopped:
This chart shows a comparison of CPU power from hardware, the virtual sensor, and the built-in Aquaero power consumption calculation. The virtual sensor uses a specific heat of 3,500 as mentioned above. When compared to power reported directly from the CPU (CPU Package), calculated CPU Power rises gradually because it's based off of Delta CPU Temp, which takes time to absorb the heat before reaching steady-state. It's the same case except reversed when the load is removed:
Same chart below except this is for the GPU. A specific heat of 4,000 for the virtual sensor correlates nicely with the hardware reading in GPU-Z (GPU Package) once the test reaches a steady-state:
This chart shows the two Delta temperature virtual sensors for the CPU and GPU. We can see the Deltas rise and fall gradually with the load, same as the power calculations from above. Also, after the Deltas go beyond 4C, this is where the fan and pump speeds kick in and maintain the 4C target!:
Power % and RPM for the fans and pumps. These charts all behave similarly as they are all based of the Delta Temp virtual sensors:
I found that a flow of 80 l/h is sufficient for this configuration at idle or light usage scenarios. At this speed, the pump is at 35% power and consumes only 5.6W each. Great! However, I decided to configure the pumps to ramp with Delta Temp CPU and GPU all the way to 100% power, to be able to keep temps and fan noise as low as possible under load:
Monday, January 13th 2025, 11:10pm
Wow. This is a really well thought out setup that shows what Aquasuite is capable of. Congrats on getting it all set up and dialed in. I am curious about the IPMI reporting. Mainstream gaming and "workstation" motherboards typically do not support IPMI. Is your AMD TR 3975WX installed in a server motherboard?
I am also curious why you had to adjust the values for the specific heat of water which is 4.186J/g°C (or 4186 J/kg°C), not 3500 J/kg°C, and not 4000J/kg°C. I understand that you adjusted this value until the calculated watt values equaled the measured values. I think the calculation would be off if you were using DP Ultra or some other coolant and not pure water because the mass and mass flow rate in kg/s would be different, and the specific heat would be different. This could be compensated for by adjusting the value for the specific heat of the coolant, but I don’t understand why you had to use different values for the CPU rads and the GPU rads. I suppose inaccuracies in the Calitemps could be part of it. Also, not all the heat is dissipated in the rads. Some heat will be radiated directly by the cooling blocks, and even the tubing (although I think that would be minimal).
I understand why you could not connect both the pump's Fan/Flow headers and your mobo to the High Flow Next Signal header. This could be resolved by adding a second High Flow Next
. Aquacomputer also has the MPS series of flow sensors which use differential pressure instead of a rotating wheel. I think they are more accurate (if calibrated properly) and the output can be configured as a tach signal. They are calibrated specifically for Aquacomputer fittings, which could be a problem.
Finally, I am curious if you have tested to see if the pump speed being controlled by Setpoint controller using Delta-T Max as the control source provided any measurable improvement in temps vs leaving the pumps set for a fixed flow rate of 80 l/hr, If this did yield a significant improvement versus just increasing the fan speeds, I may need to rethink by earlier statement that varying pump speed based on coolant temp (or Delta-T) is not worth it. I am still reviewing your screen shots and data. Thanks for providing it,
I am also curious why you had to adjust the values for the specific heat of water which is 4.186J/g°C (or 4186 J/kg°C), not 3500 J/kg°C, and not 4000J/kg°C. I understand that you adjusted this value until the calculated watt values equaled the measured values. I think the calculation would be off if you were using DP Ultra or some other coolant and not pure water because the mass and mass flow rate in kg/s would be different, and the specific heat would be different. This could be compensated for by adjusting the value for the specific heat of the coolant, but I don’t understand why you had to use different values for the CPU rads and the GPU rads. I suppose inaccuracies in the Calitemps could be part of it. Also, not all the heat is dissipated in the rads. Some heat will be radiated directly by the cooling blocks, and even the tubing (although I think that would be minimal).
I understand why you could not connect both the pump's Fan/Flow headers and your mobo to the High Flow Next Signal header. This could be resolved by adding a second High Flow Next
. Aquacomputer also has the MPS series of flow sensors which use differential pressure instead of a rotating wheel. I think they are more accurate (if calibrated properly) and the output can be configured as a tach signal. They are calibrated specifically for Aquacomputer fittings, which could be a problem.Finally, I am curious if you have tested to see if the pump speed being controlled by Setpoint controller using Delta-T Max as the control source provided any measurable improvement in temps vs leaving the pumps set for a fixed flow rate of 80 l/hr, If this did yield a significant improvement versus just increasing the fan speeds, I may need to rethink by earlier statement that varying pump speed based on coolant temp (or Delta-T) is not worth it. I am still reviewing your screen shots and data. Thanks for providing it,
Wednesday, January 15th 2025, 6:10pm
Hi Speed-VI, thanks! This is still a work-in-progress, but definitely getting there, especially with your observations. Much appreciated!
The motherboard is a ASUS WRX80 which has a BMC. Without a fan signal, it continually reports alerts in its log. I could probably turn it off, but would rather feed it a fan speed and keep the BMC alert/reporting feature intact (even though I may not end up using it, but still is available with the fan signal coming from the flow meter).
Good idea to have two flow meters, to separate signals for both the motherboard and pumps. I do have a High Flow (53068) from a previous build. Perhaps I can add it to the loop. However, I don't seem to be using flow as a critical data point, other than just for the motherboard. Flow is used to calculate power, but not used for the fan speed controllers, which use Calitemp-ambient deltas. The only side benefit I could see by feeding flow to the pumps, is to have the flow value show up in the display screen on the D5 Next pumps (because the pumps aren't on aquabus where I could grab flow from the flow meter that way). Perhaps am I missing a place where I can use flow other than that?
**edit... I see now that adding a mechanical flow sensor input to the pumps enables alarm reporting from the pumps. However, I use the signal output of the High Flow NEXT for my motherboard fan header, instead of the motherboard power switch. Instead, I have the signal connection from LEAKSHIELD connected to the motherboard power switch. Is there a way to feed the flow signal to Leakshield over USB for alarm reporting? (because Leakshield is not on aquabus). I'll investigate this further...
**
Good point about flow and comparing 82 l/h to 150 l/h. I re-ran the same test, except set the pumps at 35% power, which makes around 82 l/h flow. The charts below show some interesting results...
Both CPU and GPU temps remain the same as before (they both sit at around 59C), which is great. This is to be expected with the fan controllers set to a 4C water-ambient target delta. However, something must compensate for the lower flow, and that would be increased fan speed! (see further below).
Regarding the specific heat values... I set the specific heat value in both of my CPU and GPU virtual sensors back to 4186J/g°C. With both Furmark and Prime95 running to steady-state temps, the virtual sensors do eventually roughly equal the reported values from hardware. I was playing with the specific heat values earlier to make these outputs more equal, but 4186 is probably more correct (see the following two screen caps). However, I think power is still a 'nice-to-know' since I don't really use these power values other than for reporting on the Aquaero display.
Now with the flow set to around 82 l/h at 35% pump power (vs allowing it to reach its max of 150 l/h at 100% pump power), this chart shows definitely different behavior with the delta temps. With both the CPU and GPU rad fan controller targets still set to a target temp of 4C, you can see the CPU delta never gets past 3.5C. I believe this is because of two factors: 1) this is a single loop, which means the CPU rad probably effects the GPU rad and vice-versa, and 2) the GPU rads are about 2X the size of the CPU rads (see details of the rads in my previous post). In this case, for some reason, with flow at a steady ~82 l/h, the GPU rads seem to be dominating the CPU rads (as compared to the previous screen shot of this same chart where both delta temps were more balanced, resting at a stead-state of around 4C):
For Device Power %, you can see the CPU fan never ramped past its minimum of 30% (because the CPU Delta Temp never hit 4C). Pump power % is kept at 35%. However, GPU and Case power % hit a max of around 65% vs around 55% when the pumps were allowed to reach 100% (see this chart in previous post):
Fan speed of the GPU rad and Case fans were noticeably louder with flow set to 82 l/h. Max RPM hit 1400 vs. around 1150 previously. This is MUCH quieter and even when the pumps running at 100%, they aren't really any louder, so I would prefer ramping the pump to 100% power (by set-point controller as before) based on this result!:
For some reason, even with the pump set to a steady 35% power, flow ramped from 82 l/h to 86 l/h. Perhaps due to the increase in water temp? I have no explanation for this:
Also, as a side note, the system takes about 3L of coolant, so at 82 l/h, only around 1.4L is flowing per minute (only half of the total 3L!) which explains the time it takes for the delta temps to react with CPU/GPU loads. At 150 l/h, flow is 2.5L per minute, nearly the whole volume, which probably makes the system a bit more reactive to CPU/GPU loads, but maybe not by much.
The motherboard is a ASUS WRX80 which has a BMC. Without a fan signal, it continually reports alerts in its log. I could probably turn it off, but would rather feed it a fan speed and keep the BMC alert/reporting feature intact (even though I may not end up using it, but still is available with the fan signal coming from the flow meter).
Good idea to have two flow meters, to separate signals for both the motherboard and pumps. I do have a High Flow (53068) from a previous build. Perhaps I can add it to the loop. However, I don't seem to be using flow as a critical data point, other than just for the motherboard. Flow is used to calculate power, but not used for the fan speed controllers, which use Calitemp-ambient deltas. The only side benefit I could see by feeding flow to the pumps, is to have the flow value show up in the display screen on the D5 Next pumps (because the pumps aren't on aquabus where I could grab flow from the flow meter that way). Perhaps am I missing a place where I can use flow other than that?
**edit... I see now that adding a mechanical flow sensor input to the pumps enables alarm reporting from the pumps. However, I use the signal output of the High Flow NEXT for my motherboard fan header, instead of the motherboard power switch. Instead, I have the signal connection from LEAKSHIELD connected to the motherboard power switch. Is there a way to feed the flow signal to Leakshield over USB for alarm reporting? (because Leakshield is not on aquabus). I'll investigate this further...
**
Good point about flow and comparing 82 l/h to 150 l/h. I re-ran the same test, except set the pumps at 35% power, which makes around 82 l/h flow. The charts below show some interesting results...
Both CPU and GPU temps remain the same as before (they both sit at around 59C), which is great. This is to be expected with the fan controllers set to a 4C water-ambient target delta. However, something must compensate for the lower flow, and that would be increased fan speed! (see further below).
Regarding the specific heat values... I set the specific heat value in both of my CPU and GPU virtual sensors back to 4186J/g°C. With both Furmark and Prime95 running to steady-state temps, the virtual sensors do eventually roughly equal the reported values from hardware. I was playing with the specific heat values earlier to make these outputs more equal, but 4186 is probably more correct (see the following two screen caps). However, I think power is still a 'nice-to-know' since I don't really use these power values other than for reporting on the Aquaero display.
Now with the flow set to around 82 l/h at 35% pump power (vs allowing it to reach its max of 150 l/h at 100% pump power), this chart shows definitely different behavior with the delta temps. With both the CPU and GPU rad fan controller targets still set to a target temp of 4C, you can see the CPU delta never gets past 3.5C. I believe this is because of two factors: 1) this is a single loop, which means the CPU rad probably effects the GPU rad and vice-versa, and 2) the GPU rads are about 2X the size of the CPU rads (see details of the rads in my previous post). In this case, for some reason, with flow at a steady ~82 l/h, the GPU rads seem to be dominating the CPU rads (as compared to the previous screen shot of this same chart where both delta temps were more balanced, resting at a stead-state of around 4C):
For Device Power %, you can see the CPU fan never ramped past its minimum of 30% (because the CPU Delta Temp never hit 4C). Pump power % is kept at 35%. However, GPU and Case power % hit a max of around 65% vs around 55% when the pumps were allowed to reach 100% (see this chart in previous post):
Fan speed of the GPU rad and Case fans were noticeably louder with flow set to 82 l/h. Max RPM hit 1400 vs. around 1150 previously. This is MUCH quieter and even when the pumps running at 100%, they aren't really any louder, so I would prefer ramping the pump to 100% power (by set-point controller as before) based on this result!:
For some reason, even with the pump set to a steady 35% power, flow ramped from 82 l/h to 86 l/h. Perhaps due to the increase in water temp? I have no explanation for this:
Also, as a side note, the system takes about 3L of coolant, so at 82 l/h, only around 1.4L is flowing per minute (only half of the total 3L!) which explains the time it takes for the delta temps to react with CPU/GPU loads. At 150 l/h, flow is 2.5L per minute, nearly the whole volume, which probably makes the system a bit more reactive to CPU/GPU loads, but maybe not by much.
Thursday, January 16th 2025, 1:17am
Thanks for the clarification. I looked up that mobo. It looks like it uses the optional ASMB9-iKVM module which Asus offers for some workstation boards, but it’s not a true server-grade BMC/IPMI system. Is there no way to disable the no-fan log reporting? Most mobos allow the CPU fan header to be disabled in the BIOS.The motherboard is a ASUS WRX80 which has a BMC. Without a fan signal, it continually reports alerts in its log.
I agree that other than the rads waste heat power calculations, the flow rate is not used for anything else. Since you have set the signal header to output a speed signal to the mobo fan header, you can’t use it to trip the mobo power switch. In my system, the HFN signal header is connected to the D5N, which uses and displays the HFN flow rate instead of the D5N virtual flow rate. I have flow rate alarms enabled in the HFN and D5N Alarm tabs, but all they do is report alarms in AQS and change the LEDs to Red.I don't seem to be using flow as a critical data point, other than just for the motherboard.
The LKS has a dedicated sensor for flow rate data coming in over USB from a flow sensor but I don’t see any way to trigger an alarm based on it. Since having a flow sensor input to the LKS helps it calculate the operating parameters more accurately, and the LKS has a Signal header that can connect to the mobo power switch header, it would be nice if Aquacomputer would add flow rate to the LKS Alarm section. Connecting the HFN Signal output to the D5N Fan/Flow header gets the HFN flow rate into the D5N, which has a flow rate based alarm, but no header to connect a cable to the mobo power switch header.Is there a way to feed the flow signal to Leakshield over USB for alarm reporting?
So your GPU rads and case fan speeds increased when the pump was set to 35% (~82 /lhr), but your CPU rad fans did not. This happened because the GPU rads’ delta-T exceeded the set-point controller target, which means the temp difference between the inlet and outlet of the GPU rads was higher than the temp difference between the inlet and outlet of the CPU rads.However, something must compensate for the lower flow, and that would be increased fan speed! GPU and Case power % hit a max of around 65% vs around 55% when the pumps were allowed to reach 100%.
My understanding is that as the flow rate increases, the temperature difference between the rad inlet and outlet decreases. The heat transfer efficiency of the rad also decreases because the coolant is in the rad for less time. At an infinite flow rate, the temperature difference between rad inlet and outlet is 0° and the mass flow rate is infinite. Since there is no temperature gradient, the rad heat transfer efficiency is 0. As the flow rate decreases from infinite, the rad inlet to outlet temp difference increases while the mass flow rate decreases, so the rad heat transfer efficiency is somewhat constant. At 0 flow rate, rad inlet to outlet temp difference reaches Tmax but the mass flow rate is 0, so rad heat transfer efficiency is again 0. There is an efficiency curve between these 2 extremes. The trick is to keep the system operating in the maximum efficiency range, and in some cases varying the flow rate (pump speed) can help do this.
Thursday, January 16th 2025, 3:36am
This is a great explanation on pump speed vs rad efficiency! Perhaps then I could lower my GPU set point and raise the CPU set point a bit to balance it out better. See what happens with the fan speeds and keeping the flow constant at around 80 l/h.
The next piece is to setup the alarms properly. For this setup, things get a bit convoluted without being able to get flow over aquabus form the HFN to the D5Ns due to QUADRO is higher priority than D5N. I didn't find a way to kill CPU_FAN warnings in the mobo bios (would rather have a rpm signal show there anyway so the mobo can also be aware). Also, the HFN and LS are each capable of shutting down the computer via the power switch, but can it work over a Y-splitter? I think probably. This means I still would not have a flow signal from the HFN to the D5Ns, and a second pump flow sensor would be needed to deliver flow to the D5Ns. But I would still not have rpm at the mobo, which previously came from the HFN but now used for flow to D5N. A third flow meter? I do have an old high flow sensor I could use for the D5Ns and a Koolance sensor for the mobo. I may incorporate these into the system.
I'm also not even sure the LS alarms can work with dual 200mm reservoirs in series. These are actually Koolance 60mm tubes on Koolance D5 tops. Volume for each is probably about the same as a ULTITUBE 200, which is 470mL. To get a fill % number to show up for LS in AS, I tried different reservoirs in the pull-down but always got 0% when testing for fill level. Only when I punched in much higher values under "User defined" such as 2000 mL did the fill level % start to register. I don't know the formula behind the fill level % or how it's calculated, so not sure if this will work. The combined volume of the two reservoirs is around 940 mL not 2000mL! But at least the fill level seems about right:
I will need to somehow test if this fill level % will work for leak and fill level alarms in LS.
Here are a couple of pics of the system:
The next piece is to setup the alarms properly. For this setup, things get a bit convoluted without being able to get flow over aquabus form the HFN to the D5Ns due to QUADRO is higher priority than D5N. I didn't find a way to kill CPU_FAN warnings in the mobo bios (would rather have a rpm signal show there anyway so the mobo can also be aware). Also, the HFN and LS are each capable of shutting down the computer via the power switch, but can it work over a Y-splitter? I think probably. This means I still would not have a flow signal from the HFN to the D5Ns, and a second pump flow sensor would be needed to deliver flow to the D5Ns. But I would still not have rpm at the mobo, which previously came from the HFN but now used for flow to D5N. A third flow meter? I do have an old high flow sensor I could use for the D5Ns and a Koolance sensor for the mobo. I may incorporate these into the system.
I'm also not even sure the LS alarms can work with dual 200mm reservoirs in series. These are actually Koolance 60mm tubes on Koolance D5 tops. Volume for each is probably about the same as a ULTITUBE 200, which is 470mL. To get a fill % number to show up for LS in AS, I tried different reservoirs in the pull-down but always got 0% when testing for fill level. Only when I punched in much higher values under "User defined" such as 2000 mL did the fill level % start to register. I don't know the formula behind the fill level % or how it's calculated, so not sure if this will work. The combined volume of the two reservoirs is around 940 mL not 2000mL! But at least the fill level seems about right:
I will need to somehow test if this fill level % will work for leak and fill level alarms in LS.
Here are a couple of pics of the system:
Saturday, January 18th 2025, 2:21am
For Ambient temp, I used two regular 10K temp sensors mounted just inside the rear intake case fan, and took an average between the two (not really necessary though):
That looks to be a pretty good location for your ambient sensors, but I am still interested in a chart of the ambient temperature vs. system load.
Sunday, January 19th 2025, 5:05am
That looks to be a pretty good location for your ambient sensors, but I am still interested in a chart of the ambient temperature vs. system load.
Could you elaborate on the chart you're thinking of? The plot for ambient would be a straight line since my ambient is a steady 20.5C. For system load, CPU, GPU, both in percent?
Btw, quick update... I decided to add a high flow sensor to the loop. This will be used to signal the D5Ns for their non-shutdown alarms (light and buzzer) and also be used to signal the Aquaero for actual shutdown alarms (connected to the power switch of the motherboard via the Aquaero relay). The other flow sensor (HFN) will signal the CPU_FAN header to satisfy the motherboard.
However, I would also like to use the signal from the Leakshield for a shutdown alarm. Is it possible to connect both the Leakshield signal AND ground signal from the Aquaero to the mother board power switch? This is no problem on the Aquaero because the ground signal coming from a Leakshield shutdown event would be connected to the NO side of the Aquaero relay. However, in the case of a Aquaero alarm sending a ground signal, would the signal pin of the Leakshield mind if it was grounded externally? In the manual, the signal pin is "open drain max 3.3 V / 5 mA". What happens if this is grounded externally?
Quoted
6.2. Connector “signal”
The header can be connected to the power switch header of the motherboard using an additional specialized cable (53216, not included in delivery).
Pin assignment: Pin 1: GND
Pin 2: not connected
Pin 3: open drain max 3.3 V / 5 mA
**Edit**
Did a bit of research on this, and the open drain output of the Leakshield is I believe a low level output. I don't want to connect this directly to ground. Instead, I think it needs a relay similar to the relay configuration of the Aquaero. However, this low level output can't drive a relay coil directly because it's limited to 5mA (relay coils are a lot more, 40mA+). There's this low-level input relay with 2mA trigger:
https://www.amazon.com/gp/product/B0CZ6VNK65
With this, I should be able to control the power switch of the motherboard from either the Leakshield or Aquaero independently through the relays.
Sunday, January 19th 2025, 1:01pm
Could you elaborate on the chart you're thinking of? The plot for ambient would be a straight line since my ambient is a steady 20.5C. For system load, CPU, GPU, both in percent?
Checking for a straight line for the ambient would be the purpose of the chart, often having the ambient sensor in or around the system can cause the reading to rise with system load.
Here is a link to a quick study I performed on my system a while back... my setup has an external radiator, but the concept is the same [ambient_test]
Similar threads
-
English forum »-
high flow NEXT - The next generation of flow sensors
(Aug 26th 2020, 11:17am)
-
- English forum »
-
[solved] Highflow next through Quadro indicates 16X the real flow
(Jul 29th 2022, 5:00pm)
-
- English forum »
-
Need some advice on Aquabus/USB/FLOW SENSOR and FARBWERK
(Feb 5th 2016, 4:47pm)
-
- English forum »
-
Flow sensor "high flow" G1/4 for aquaero, aquastream XT ultra and poweradjust doesn't work
(Oct 24th 2015, 1:41pm)