OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[gyverlb]

Redownload please 

Works for me now.

I've removed my --gpu-fan tunings to see if the new fan speed setting algorithm is working for me : I had huge variations of fan speed and gpu temp that made my OC'd GPU unstable. With 2.0.3 the GPU temps could reach 10°C above target.

[1713980478]

1713980478

[1713980478]

1713980478

[1713980478]

1713980478

[1713980478]

1713980478

[1713980478]

1713980478

[Shevek]

I know about PID controllers, I just think it's just far too complicated to bother trying to implement, as I said in git issues. Most people find the simple approach works fine. I'd happily take well done patches implementing it though. I will damp is slightly next release.

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.

edit: It could also simply be that your hardware doesn't accept the smaller values being passed to it and it ignores them till it gets some coarse value it accepts.

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

[Shevek]

NEW VERSION: 2.0.4

Now available for Gentoo through Portage (or any other ebuild package manager):

Code:

layman -a bitcoin && emerge cgminer

Please test and report results!

I'm happy to see you here Luke! did you test cgminer against eligius? In earlier versions cgminer reported a lot of rejections with your pool.

[gyverlb]

I've removed my --gpu-fan tunings to see if the new fan speed setting algorithm is working for me : I had huge variations of fan speed and gpu temp that made my OC'd GPU unstable. With 2.0.3 the GPU temps could reach 10°C above target.

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).

[Luke-Jr]

I'm happy to see you here Luke! did you test cgminer against eligius? In earlier versions cgminer reported a lot of rejections with your pool.

Pretty sure all those bugs were fixed with 2.0.0.

[os2sam]

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

[The00Dustin]

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

I had similar problems starting with 2.0.0, however, my shares/minute stayed the same or improved, so I didn't worry about it.  I think (guessing here) it is lower because more work is queued to prevent you from running out of shares and dropped because they sit too long.

[DavinciJ15]

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.

[The00Dustin]

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.

No wonder I'm getting 80% rejects on your pool, I thought it was just overloaded and my connection was too slow to get work submitted without a faster miner beating me to it.

[DavinciJ15]

No wonder I'm getting 80% rejects on your pool, I thought it was just overloaded and my connection was too slow to get work submitted without a faster miner beating me to it.

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.

[kano]

Your pool is namecoin.
There is no point posting in this thread.
The bitcoin+namecoin mining scam idea will not work with cgminer.
It cannot mine more than one chain at the same time.

[DavinciJ15]

Your pool is namecoin.
There is no point posting in this thread.
The bitcoin+namecoin mining scam idea will not work with cgminer.
It cannot mine more than one chain at the same time.

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.

[The00Dustin]

See the guys with ZERO or less than .10, those are CGIMiners connecting to just one server instead of nmcbit.com.

Con, regardless of you opinion on NMC vs BTC et al, round robin DNS is a standard thing it would be good to support.  Unfortunately, I know nothing about programming, but here's a thought on a simple solution that might keep cgminer better than the others...  What if cgminer keeps track of which work belongs to which IP so that it can take advantage of that instead of only using one IP or sending work to the wrong server?  I suppose you could actually choose one IP and fail over to others by default and only do this when --load-balance was selected, but then if someone wanted a backup pool as well, they would have to work for it or only work for one server in any round robin pool.  One other thing to keep in mind would be that a slower mining device might be better off not using all of the servers depending on much the load-balancing might negatively affect the shares found vs shares discarded.

[The00Dustin]

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.

[kano]

Your pool is namecoin.
There is no point posting in this thread.
The bitcoin+namecoin mining scam idea will not work with cgminer.
It cannot mine more than one chain at the same time.

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.

The only thing 'merged mining' does is take hashes away from Bitcoin and give them to another chain (in this case namecoin) but pretend that it's good for bitcoin.
It isn't good for bitcoin.
It is good for namecoin and bad for bitcoin.
It's a scam because namecoin people won't admit the truth, and thus try to convince others by deception.

I'd wonder how people would react if SolidCoin 2.0 did merged mining ...

Anyway, AGAIN, cgminer cannot mine 2 chains at the same time.
So there is no point looking for other changes to suit you when it will never work in it's current incarnation anyway.

I look at it this way:
Would I want to lower cgminer's extremely high ability to avoid rejects and stales just so I can give away hashes to namecoin?
No, of course not.

[Luke-Jr]

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.

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

[DavinciJ15]

I look at it this way:
Would I want to lower cgminer's extremely high ability to avoid rejects and stales just so I can give away hashes to namecoin?
No, of course not.

Not sure why you are angry, but like bitcoins is not a scam merged mining is not a scam.  The work you do on mining is "a make work project" and very little to do with a particular block chain.   Yes, there is tx validation work being done but on any block chain the majority of the work you do is not relevant just the fact that you did it is.  This is an easy to understand version of how it works it's not exactly right but in a general sense it is.

I'm not going to get into an argument with you about fraud because there is none.  

Finally today at my pool you can mine namecoins and get paid bitcoins but when merged mining kicks in you will be mining both.  When it happens the market will decide if it's worth it.

Good luck

Davinci

[DavinciJ15]

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.

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

[gyverlb]

NEW VERSION: 2.0.4

Now available for Gentoo through Portage (or any other ebuild package manager):

Code:

layman -a bitcoin && emerge cgminer

Please test and report results!

Code:

emerge: there are no ebuilds to satisfy "dev-util/amd-adl-sdk"

I have dev-util/amd-app-sdk-bin though.

[Ghostofkobra]

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