New Product Suggestion

[Gooserider]

Hi,

I am looking at getting a fan controller / system status monitor for the Linux box that I'm building. It will be a liquid cooled system built into a server-cube type case with four 120mm fans, two on the intake, and two on the exhaust. As a firm believer in the idea that PC's should be silent or close to it, I want to have temperature sensitive variable speed control on the fans so that I can run them at the lowest possible speed providing acceptable temperatures at any instant. I find lots of 'Baybus' style manually adjustable controllers, which IMHO miss the point, a computer should be able to handle such things automatically, not require extra work from the user!

Ideally, I would like the controller to be able to monitor other system health type functions (Resevoir coolant level, coolant flow, fan failure, leak detection, etc.) and be able to shut the system down if needed. It should also run on it's own microprocessor so that it does not depend on, or steal processing power from, the main O/S running on the motherboard. I feel this would make the controller more efficient and reliable, as well as giving greater independence as to what is running on the main board. (I sometimes play with other operating systems) Other than initial configuration, and possibly optional reporting, I'd like the controller to operate completely seperately from the main system.

The users Dutch2 and FanControl over on Silent PC Review have home built designs that are very close to what I want, but FanControl's unit doesn't support enough fans or have enough software support. Dutch2 left the board abruptly, so his unit isn't available but the thread describing it is excellent. Innovatek has a unit called the 'Fan-O-Matic' which I think would do what I want except that it isn't available in the US, and does not have Linux compatible configuration software.

The 633 comes very close to what I'm looking for, in terms of functionality, but it has some limitations, the biggest being that it relies excessively on software running under the main O/S. However this might be tolerable given the 633's watchdog safety function.

What I would like to see is a CF unit with the following functionality...

1. A larger display? I'd like to see the largest display that can be fit into a standard 5.25" half height drive bay. This is relatively minor, I could live with a 633 size display, but bigger is better...

2. A more robust on board Microprocessor with sufficient memory (Flash?) to allow a configured unit to remember it's programming and run independently of the motherboard.

3. Configuration software that runs as O/S independently as possible (Java based?) at the very least it must run under Linux and that other insecure, overpriced O/S.

4. Either loose the keypad, or make it do something useful. (BTW, most cases already have power and reset buttons, so duplicating them on the keypad is NOT a useful function IMHO) Possible useful things would be to change the contrast or step through a multi-line display output.

5. Possibly add support for more fans and / or some additional generic user configurable input / output pins.

6. Keep the DOW sensors, it is one of the better things about the 633.

Based on what Dutch2 and Fancontrol were talking about offering on their controllers (purchasing single unit quantity parts) I'm sure that CF could easily offer something at around $100, which is a price I would gladly pay for such a unit.

Thanks,

ART

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

Thanks for your suggestions.

I can address a few of the points. We have Linux and Windows service programs that will do the temperature controlling:

https://forum.crystalfontz.com/forumdisplay.php?forumid=14

Please look at the stickys.

In some ways it would be nice to put a more capable processor on te LCD, but is is hard to justify spending perhaps 2-4 times more for the resources on the embedded processor when there is (literally) a million times more resources that cost 1000 times less (per byte/cycle) only a few inches away. The trade-off we came up with is the service + fail-safe fans.

CC2 will make good use of the keys. It is just over that next rise.

 

[Gooserider]

Again, many thanks for the reply, it was helpful.

In some ways it would be nice to put a more capable processor on te LCD, but is is hard to justify spending perhaps 2-4 times more for the resources on the embedded processor when there is (literally) a million times more resources that cost 1000 times less (per byte/cycle) only a few inches away. The trade- off we came up with is the service + fail-safe fans.

It's not a bad trade-off I'll agree, it addressed my concern with many of the S/W solutions that I had otherwise seen. The other concern that makes me feel inclined towards using a seperate processor is the idea of not chewing up prime CPU time on a 'housekeeping' task, it seems like a good idea to me to get as many burdens of that sort off the CPU. Any data as to how much of a performance penalty running the fan control off the main CPU takes from the rest of it's tasks?

CC2 will make good use of the keys. It is just over that next rise.

Possibly true, but CC looks to me like a Windows program, which doesn't do a thing for me since I'm running under Linux....

 

[CF Tech]

>Any data as to how much of a performance
>penalty running the fan control off the main
>CPU takes from the rest of it's tasks?

Please post that question over in the
CrystalControl forum, I am sure CC Admin will have a good idea of the usage.

 

[CF Mark]

Ill answer it here

The current 633-Service under Linux uses about 0.5% CPU usage (box is a PII-300).

Most of that CPU time is used to update the 633's screen ~20 times/sec.

Running simple fan control (reads temp sensors and updates fan speeds every 5sec) uses pretty much no CPU time at all.

 

[Gooserider]

That sounds pretty reasonable...

The current 633-Service under Linux uses about 0.5% CPU usage (box is a PII-300)

Considering that the new box will be a dual Athlon, it should drop the performance hit even more....

Gooserider

 

[CF Mark]

That sounds pretty reasonable...

Its not too bad.
Not as low as i would like it, but you wont notice it running.

 

[Gooserider]

CrystalControl Admin:
Most of that CPU time is used to update the 633's screen ~20 times/ sec.

Why is it necessary to update so often? I would think the only time an update would be needed is when changing the display content, which I would hardly be doing that often!

It seems to me like refreshing the display should be the LCD controller chip's job. I know that the LCD 'status windows' on a product I used to work on seemed to capture whatever text was sent to them, and keep displaying it until they recieved new text. (As shown by keeping the same text on the display even after the board was totally hung...)

If the display refresh were handled by the LCD controller, it would seem to me that you would only need to update once every few seconds when either the data changed, or you loaded a different status screen...

Gooserider

 

[CF Tech]

The LCD will keep whatever is sent to it indefinitely with no intervention from the host.

The software uses 20 updates per second to make things like bar graphs update smoothly, and things like network traffic, RAM usage and et c. appear more "real-time".

I suppose the software could run internally at 20 times per second, but only update the physical display if the data shown is actually changing. I do not know if that is in the works for CC2, but I do not think that it would be difficult.

I guess the question would be whether the compare takes less CPU time than just dumping the data out of the port. The USB, which uses a driver to send the stream through the VCP may impact the CPU usage and change the balance. My gut tells me that the "compare and send only when changed" would be the least CPU intensive method.

 

[CF Mark]

It updates the LCD every 50mS... but only sends if the lines have changed.

It processes any new incoming packets every 250mS.

It updates fan speeds, checks alarms and updates the stats file every 2.5sec.

Thinking about it now, itll be my high-accuracy timing routines that are using the small amount of CPU time.

 

[Gooserider]

CrystalControl Admin:
It updates the LCD every 50mS... but only sends if the lines have changed. It processes any new incoming packets every 250mS. It updates fan speeds, checks alarms and updates the stats file every 2.5sec. Thinking about it now, itll be my high-accuracy timing routines that are using the small amount of CPU time.

Wow, I than you for the quick and throrough responses, even on weekends!
Is there any reduction in CPU usage if one is only using the unit as a fan controller? Or would there be a way to lower the accuracy on the timing routines so as to make them a bit less CPU intensive?

Maybe it's a holdover from my old PC days when there weren't many to spare, but I really hate using more CPU cycles than necessary...

Gooserider

 

[CF Mark]

Wow, I than you for the quick and throrough responses, even on weekends!
Is there any reduction in CPU usage if one is only using the unit as a fan controller? Or would there be a way to lower the accuracy on the timing routines so as to make them a bit less CPU intensive?

Possibly.
The problem is that its using the same timing routines as those in CrystalControl2, where high accuracy is needed for displaying to HD44780 displays.

Maybe it's a holdover from my old PC days when there weren't many to spare, but I really hate using more CPU cycles than necessary...

Yeh, same here