OK, thanks. I still didn't taste this new version; I guess your damp is a kind of differential control. Anyway, what I have in mind is something like this.

Fi: actual fan value
Ti: actual temp.
Tc: target temp

Pi = Ti - Tc
Di = Ti - T(i-1)
F(i+1) =  Fi + aPi + bDi

where a,b are constants that should be elected after some tryings.  See, that integral control is implicit in the dependence of old value.


I don't think so... I've monitored the fan speed and It shows often near values.

2.0.4 seems much better.

Most important thing : it protects the GPU far more efficiently than 2.0.3, the GPU temp doesn't go more than 1 or 1.5°C above target.
The fan speed setting still overshoots the ideal speed when going above the target but doesn't undershoot it as much. It seems that the oscillation's amplitude lowers itself with time and finally stabilizes itself (according to logs the 5970 which had the most problems with 2.0.3 is now happily at 46% for more than 30 minutes without any re-tuning by cgminer after an initial period of 20 minutes of oscillations).

I installed 2.0.4 last night and checking it this morning my efficiency is at 16%.  The previous versions had 80+%.

I haven't changed any of my settings.
Sam

Suggested fix.

Hi I run a pool that takes a different approach to pool servers.  I use many servers and not just one and round robin them on one domain.  CGIMine is the only miner I know of that does not stick to the one ip when it makes get work requests and submitting its work thus it would get work from one server on the round robin and submit it to another that rejects it.

I am thinking of creating a balance server to fix this issue however if the developer can fix it that would be better.

Currently poclbm works fine it sticks to one server ip unit there is a problem then request a new IP address from the domain name rotating it to another server automatically.
If you are not familiar with round robin domain the way it works is that if you ping nmcbit.com you will get an IP address clear your DNS cache and pint nmcbit.com and you will a different IP.   This is great for web sites not so good for mining if the miner does not use the same IP over and over again until there is a problem.

Using multiple servers gives me the appearance of 100% up time (once I get all the bugs out lol) as I do upgrades.  Last night was prime example where I was able to rotate out pushpool with PoolServerJ with no disruptions to my miners.

This is best fixed on your side because a user could have one username on the pool but many miners using the same username and password from the same IP address, thus preventing my load balance code from detecting if the user came from the same computer.

Use balanceserver1.nmcbit.com you will get less than 0.10 rejects that's where I will add my code.  Check my stats...
http://www.nmcbit.com/statistics
See the guys with ZERO or less than .10, those are CGIMiners connecting to just one server instead of nmcbit.com.

It works with CGIMiner the problem is my pool does not because of the round robin.   If you connect to just one server CGIMiner KICKS ASS!

Also you can mine more than one chain at the same time it's not a scam anymore than bitcoin is scam.  You sound like my viewers of my YouTube channel when I told them about bitcoins.

SCAM!

The great thing about merged mining if it works well is that we can have more than one currency and that will not be inflationary anymore than copper is inflationary to gold.  lol

Have a good one.

Instability Since 2.0.3:

I was running stable with 2.0.0 through 2.0.2, but with 2.0.3, my GPU started dying.  I was hopeful that the auto-fan changes in 2.0.4 would fix this, but they didn't.  As such, I have two questions:

1) Does cgminer 2.0.3+ have additional performance improvements that might require me to lower my OC values some more like an
earlier 1.x version did?

2) Regardless of the answer to (1), would these parameters effectively prevent overheating without manipulating the GPU after startup?:
--temp-target 66 --temp-hysteresis 1 --temp-cutoff 68

I ask (2) because I am thinking maybe (especially if the answer to [1] is no) my GPU doesn't like the constant changes and will be stable this way but still shut off before it even risks heat damage (68 should be a low number, but I haven't seen this GPU functional while the temp was above 70 yet).

EDIT:  I hav beeen stable for an hour using the parameters mentioned in (2).  Also, I am getting the same shares/minute as before and haven't reached the target temp.  It would appear that the instability I was experiencing (including earlier today when it was cooler where the miner is) was due to either a) my GPU overheating before cgminer took action (possibly due to my higher 72 degree temp cutoff combined with the auto-fan) or b) the constant changes from cgminer (which seems less likely given the stability experienced in version prios to 2.0.3).  I'm guessing (a) is the culprit, and it doesn't necessarily imply a problem with cgminer since I didn't lower my --temp-cutoff from 72 during those runs.

This is a bug on your end. The solution is to get your pool servers to share their work log.

That is another solution I have pondered.  However PSJ code quickly uses methods to quickly validate work that can not be accomplished using Memcache or anyother type off remote memory.  With that said miners existed before my clustered pool idea did.

Best regards

Davinci

Well two things:

1) The reason that cgminer doesnt work with your pool (nmcbit) is that it works as it is supposed to. The whole idea of automatic load balancing is that it should be transparent to the clients. So fix the pool.

2) The reason that the other miners works with your pool is that they are broken and doesnt load balance (they stick to the one of them that they got the first time - ie. no load balancing.)


Best Regards
//Ghost of kobra