Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 444. (Read 5805537 times)

legendary
Activity: 1428
Merit: 1001
Okey Dokey Lokey
Yay the 2.9.4 works great with stratum and eclipse!

Hashpower has LP again!

Everything is working as expected.
Smiley That's what I like to hear.

Do be careful though. That poison known as GBT may strike with unexpected bugs if one of your backup pools uses GBT.

Best current compromise is to use as many stratum pools as possible with their direct addresses and add --fix-protocol in case one of your backup pool uses GBT.

Bottom line: I really regret even implementing GBT for cgminer, as it was a lot of work, introduced a new set of bugs, and has earned me zero donations despite a lot of work. I'm seriously considering just disabling or even backing out GBT support.
Gosh guys, Do we Not have a donation address for ckolivas? When there was the change from 2.7->2.8 and we got that Totally Uneccesary "Best Share" stat, I'd of set my donation to 1% for two days.
I really think that CGminer should have a Prompt of "Could you please help the developer by enabling .001% hashrate donation? There are no side affects"

Seriously, Back when CGminer prompted for "donation set to 0%, Please consider atleast 0.00x% :"(" it made me want to donate, Im sure that if Ckolivas Gets SOMETHING for doing all this work, Then he'll continue the work.

What would you all do if CGminer just Stopped being updated? For awhile we would all be just fine, But imagine if it was discontinued Before stratum, Or even before LongPolling
Just donate!
legendary
Activity: 1540
Merit: 1001
Yay the 2.9.4 works great with stratum and eclipse!

Hashpower has LP again!

Everything is working as expected.
Smiley That's what I like to hear.

Do be careful though. That poison known as GBT may strike with unexpected bugs if one of your backup pools uses GBT.

Best current compromise is to use as many stratum pools as possible with their direct addresses and add --fix-protocol in case one of your backup pool uses GBT.

Bottom line: I really regret even implementing GBT for cgminer, as it was a lot of work, introduced a new set of bugs, and has earned me zero donations despite a lot of work. I'm seriously considering just disabling or even backing out GBT support.

You've got my vote to remove GBT support.  Just because it's available doesn't mean it has to be implemented.  That's how the marketplace works. 

M
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Yay the 2.9.4 works great with stratum and eclipse!

Hashpower has LP again!

Everything is working as expected.
Smiley That's what I like to hear.

Do be careful though. That poison known as GBT may strike with unexpected bugs if one of your backup pools uses GBT.

Best current compromise is to use as many stratum pools as possible with their direct addresses and add --fix-protocol in case one of your backup pool uses GBT.

Bottom line: I really regret even implementing GBT for cgminer, as it was a lot of work, introduced a new set of bugs, and has earned me zero donations despite a lot of work. I'm seriously considering just disabling or even backing out GBT support.
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Yay the 2.9.4 works great with stratum and eclipse!

Hashpower has LP again!

Everything is working as expected.
legendary
Activity: 1002
Merit: 1000
Bitcoin
the problem was "device" : "0", and 1 and 2 .. listed at the end of the .conf file Smiley  Removed all "device" : .. lines and all runs fine now Smiley  Thanks
hero member
Activity: 504
Merit: 500
Scattering my bits around the net since 1980
Im on it, I'll edit with news soon Smiley   thanks Cheesy

edit 1 : All GPU are OFF when starting cgminer with -c doom.conf  :/

this rig have 4 GPU and 1 FPGA, only FPGA runs on start now !!
Well, you still need to set up all of your configuration in the conf file too...

-- Smoov
legendary
Activity: 1002
Merit: 1000
Bitcoin
Im on it, I'll edit with news soon Smiley   thanks Cheesy

edit 1 : All GPU are OFF when starting cgminer with -c doom.conf  :/

this rig have 4 GPU and 1 FPGA, only FPGA runs on start now !!
hero member
Activity: 504
Merit: 500
Scattering my bits around the net since 1980
cgminer.conf edited manually, have change Engine and Memory parameters and it does'nt apply on loading CGMINER  :S
Dont want to use your precious time CKOLIVAS, was in hope someone else could help.. you have done so much work with CgMiner !

Edit : I'll try setting my Engine and Memory clock in the commandline that start CGMINER = Issue sould be relsoved  Cheesy

Thank you very much for your very nice miner, by far my favorite !
On Win7, I have several different shortcuts set up, which loads up different conf files depending on what I want to mine.

The only command line option is similar to "-c cgminer(BTC).conf", with all of my other options in the conf file.

Give that -c flag a shot?

-- Smoov
legendary
Activity: 1002
Merit: 1000
Bitcoin
cgminer.conf edited manually, have change Engine and Memory parameters and it does'nt apply on loading CGMINER  :S
Dont want to use your precious time CKOLIVAS, was in hope someone else could help.. you have done so much work with CgMiner !

Edit : I'll try setting my Engine and Memory clock in the commandline that start CGMINER = Issue sould be relsoved  Cheesy

Thank you very much for your very nice miner, by far my favorite !
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I've searched the forum and this thread and could not find an answer..

Settings/Write Config ENTER to default cgminer.conf did not save engine and memory clock settings.

Each time I restart CGMINER I need to set memory and GPU clocks.

I'm using an old version (2.7.5) maybe this is an issue that have already been adressed.
I've also tried to edit manualy the cgminer.conf file, not effective.

Sorry for maybe noob question, I've search for an answer before asking !

Thanks anyone for your time.
It saves command line parameters, not things you change later on.
legendary
Activity: 1002
Merit: 1000
Bitcoin
I've searched the forum and this thread and could not find an answer..

Settings/Write Config ENTER to default cgminer.conf did not save engine and memory clock settings.

Each time I restart CGMINER I need to set memory and GPU clocks.

I'm using an old version (2.7.5) maybe this is an issue that have already been adressed.
I've also tried to edit manualy the cgminer.conf file, not effective.

Sorry for maybe noob question, I've search for an answer before asking !

Thanks anyone for your time.
member
Activity: 623
Merit: 11
Proof-of-Stake Blockchain Network

... But you are running a very old miner version with some serious bugs in it. Upgrade today! Smiley

Thanks for the info.  That machine is just an old MB with a card plugged in. I guess I need to drag a monitor over to it and upgrade it.  My other rigs are running 2.7.6 with no problems. My GPU days are numbered anyway...
sr. member
Activity: 658
Merit: 250
What is "Harmful miner version detect" - using 2.6.1 on bitminter?

If you run a cgminer or bfgminer version below 2.7:
You are causing yourself and all other miners to lose transaction fee income on the blocks you make. You were causing slow server response and a high reject ratio, before these changes. You are getting work slower than others on the pool. You are probably getting more stales too. I know this isn't something you intended to do and you may not have been aware of it before. But you are running a very old miner version with some serious bugs in it. Upgrade today! Smiley
member
Activity: 623
Merit: 11
Proof-of-Stake Blockchain Network
Quick question @ckolivas

Just flashed over to check that all miner are up - saw this...




What is "Harmful miner version detect" - using 2.6.1 on bitminter?

I run Linux 10.10, don't have any backup pools, don't usually upgrade anything, because my rigs just mine continuously with no problems.
legendary
Activity: 1540
Merit: 1001
alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M
Did you have a GBT pool as a backup somewhere? I think there's a crash unique to pools that send GBT info. If so, --fix-protocol should prevent it, so you'll have to specify the stratum pools' urls/ports directly.

I probably do.  I don't know which ones use GBT and which ones don't.

M
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M
Did you have a GBT pool as a backup somewhere? I think there's a crash unique to pools that send GBT info. If so, --fix-protocol should prevent it, so you'll have to specify the stratum pools' urls/ports directly.
legendary
Activity: 1540
Merit: 1001
alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M
hero member
Activity: 563
Merit: 500
It looks like stratum backup pools aren't detected as alive when specified with a stratum+tcp:// URL (though, strangely, they work fine if you put in an http:// URL pointing to the stratum port).

At least with EMC.

ETA, unless I don't understand what a stratum URL is supposed to look like.

With the default (failover) strategy, if I specify my pools as follows then only whichever pool I put first is detected as alive (and if that's down it *doesn't* failover).

stratum+tcp://us1.eclipsemc.com:3333
stratum+tcp://us2.eclipsemc.com:3333
stratum+tcp://us3.eclipsemc.com:3333

If I specify them as follows then it connects with stratum, detects all pools live, and failover seems to work:

http://us1.eclipsemc.com:3333
http://us2.eclipsemc.com:3333
http://us3.eclipsemc.com:3333

ETA again: Although to be fair some of the evidence that lead me to the above conclusion was collected from a version of git master HEAD somewhere between 2.9.3 and 2.9.4.  But I'm certainly seeing backup pools report as down in 2.9.4 - can't say for sure that failover is actually not working.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.
If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone.
None of those (AFAIK) support decentralized mining, though. Nor is it really practical as GBT's bandwidth use is absurd with p2pool's 10 second blocks.
There's no reason to prefer p2pool over Eligius or Bitminter anyway, so long as you're decentralized mining.
FFSake can you stop with the FUD - Eligius and Bitminter are not decentralized - learn English, not whatever warped, deluded, zealot language you use.

There is a perfectly simple reason to use p2pool and not go anywhere near ANY centralised GBT pool like Eligius or Bitminter and that is the 2 orders of magnitude larger amount of data GBT transfers across the internet to your miner compared to the old getwork or new stratum pool protocol.
Even a bitcoin dev has said that the GBT data design is not designed for a WAN (or even a LAN)
Quote
The RPC protocol was never designed to minimize data transfer. It's meant for controlling a bitcoind instance on the localhost, in which case the amount of data is of no essence (hence the choice of JSON, too).
... as per my Issue I raised on the bitcoin code (where you sneaked in your botnet support into bitcoind/GBT)
https://github.com/bitcoin/bitcoin/issues/1985
I also do not understand why you supported botnets on Eligius and now added support of them into bitcoind that everyone now has in their bitcoind

Bitminter and Eligius ARE centralised - there is one place that controls all the work - the pool - just like every other non-p2pool pool does.
On Eligius GBT, the centralised pool decides what is valid work and what is not valid work.
On p2pool it is the p2peers that decide ... and if suddenly half the peers decide one type of work is valid and the other half decide a different type of work is valid, you will then get 2 p2pools running with 2 different sharechains
Be it half the miners or just one miner, the miner can keep mining no matter what it decides is valid - each sharechain is simply the list of p2pool miners that agree in it's contents ... and that is by definition decentralised.
legendary
Activity: 2576
Merit: 1186
You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.
If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone.
None of those (AFAIK) support decentralized mining, though. Nor is it really practical as GBT's bandwidth use is absurd with p2pool's 10 second blocks.
There's no reason to prefer p2pool over Eligius or Bitminter anyway, so long as you're decentralized mining.
Jump to: