Author

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

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Smiley Yes since the discussion of MM I have --submit-stale on and will leave it on forever.
I don't want to be losing shares that are valid ... and I lose nothing submitting invalid shares ...
But as soon as any pool I use starts invalidating valid BTC shares due to merged mining I will certainly be vocal in creating a thread to suggest people dump that pool.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Version 2.0.8 - November 11, 2011

- Make longpoll do a mandatory flushing of all work even if the block hasn't
changed, thus supporting longpoll initiated work change of any sort and merged
mining.

Donated 5BTC as I promised.  Thanks for continuing to improve THE BEST miner out there.

I was hoping your could clarification on the flushing "timeline".

Does it work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
6) If GPU finds a share that share it considered stale and not submitted (SS increments by 1)
7) GPU begins work on new data

If so does enabling --submit-stale option cause it to work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
5) If GPU finds a share that share will still be submitted. (If actually stale R increments by one otherwise A increments by 1)
6) GPU begins work on new data

The reason I ask is because it is possible the LP is from new transactions or NMC header change and the share is still valid for BTC. 
I understanding using --submit-stale option will potentially increase rejects but if I understand this right.

SS + R should be equal regardless of if --submit-stale is used or not.  Right?

It makes me think I should use -submit-stale.  The only downside is that it increases potential workload for the server.  The upside is that I may gain a few more accepted shares.

Thank you very much for your donation  Cheesy

Your interpretation is spot on. --submit-stale is fine since pools don't usually penalise you for submitting shares it rejects. It just increases your reject count.
hero member
Activity: 742
Merit: 500
I just built 2.0.8 on my BAMT rig with the same flags that I used for 2.0.7.  Everything seems to work fine. Thanks for the hard work.
full member
Activity: 225
Merit: 100
Just donated 1 BTC. Keep up the good work, Conman.

Maybe you find some time for this in the next release.  Wink
https://bitcointalksearch.org/topic/m.584743
legendary
Activity: 3583
Merit: 1094
Think for yourself
Just installed 2.0.8 on M$ Windoze XP.
The .bin files did not get generated, had to copy the .bin files from 2.0.0.
Still crash's on quit.

But it still seems to run great.
Thanks,
Sam
jr. member
Activity: 39
Merit: 1
Code:
/usr/bin/ld: cgminer-adl.o: undefined reference to symbol 'dlopen@@GLIBC_2.1'
[...]
libdl.so: could not read symbols: Invalid operation

Can anyone help me on this?

New version: 2.0.8, links in top post as always.

Version 2.0.8 - November 11, 2011

Problem solved with v2.0.8.
Thanks ck
legendary
Activity: 3583
Merit: 1094
Think for yourself
Seems windows doesn't like when cgminer quits.  Maybe the next version could write that to the log. 

That sounds like a good idea/option for all OS's.

What say you conman?
Sam
donator
Activity: 1218
Merit: 1079
Gerald Davis
Seems windows doesn't like when cgminer quits.  Maybe the next version could write that to the log. 
legendary
Activity: 3583
Merit: 1094
Think for yourself
In preparation for a new version, I finally stopped my main miner that was running 2.0.7 for the longest period I've run cgminer for. I figured I should post what my miner ran like for that time period. Bear in mind I was load balancing so the reject rate would be slightly higher.


[2011-11-11 19:47:02] Started at [2011-10-26 07:04:04]
[2011-11-11 19:47:02] Runtime: 396 hrs : 42 mins : 58 secs
[2011-11-11 19:47:02] Average hashrate: 1749.3 Megahash/s
[2011-11-11 19:47:02] Solved blocks: 2
[2011-11-11 19:47:02] Queued work requests: 612950
[2011-11-11 19:47:02] Share submissions: 569593
[2011-11-11 19:47:02] Accepted shares: 567274
[2011-11-11 19:47:02] Rejected shares: 2319
[2011-11-11 19:47:02] Reject ratio: 0.4
[2011-11-11 19:47:02] Hardware errors: 0
[2011-11-11 19:47:02] Efficiency (accepted / queued): 93%
[2011-11-11 19:47:02] Utility (accepted shares / min): 23.83/min

[2011-11-11 19:47:02] Discarded work due to new blocks: 29680
[2011-11-11 19:47:02] Stale submissions discarded due to new blocks: 274
[2011-11-11 19:47:02] Unable to get work from server occasions: 1220
[2011-11-11 19:47:02] Work items generated locally: 31636
[2011-11-11 19:47:02] Submitting work remotely delay occasions: 956
[2011-11-11 19:47:02] New blocks detected on network: 2191

[2011-11-11 19:47:02] Summary of per device statistics:

[2011-11-11 19:47:02] GPU0 74.5C 5321RPM | (5s):450.0 (avg):442.6 Mh/s | A:143414 R:593 HW:0 U:6.03/m I:9
[2011-11-11 19:47:02] GPU1 73.5C 5266RPM | (5s):428.8 (avg):426.4 Mh/s | A:138718 R:547 HW:0 U:5.83/m I:9
[2011-11-11 19:47:02] GPU2 74.0C 5558RPM | (5s):430.1 (avg):430.9 Mh/s | A:139513 R:560 HW:0 U:5.86/m I:9
[2011-11-11 19:47:02] GPU3 73.5C 4479RPM | (5s):443.9 (avg):449.4 Mh/s | A:145629 R:619 HW:0 U:6.12/m I:9


I wish I could see a screen like that.  Whenever I quit the program it wants to send stuff to M$ Wink
Sam
donator
Activity: 1218
Merit: 1079
Gerald Davis
Version 2.0.8 - November 11, 2011

- Make longpoll do a mandatory flushing of all work even if the block hasn't
changed, thus supporting longpoll initiated work change of any sort and merged
mining.

Donated 5BTC as I promised.  Thanks for continuing to improve THE BEST miner out there.

I was hoping your could clarification on the flushing "timeline".

Does it work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
6) If GPU finds a share that share it considered stale and not submitted (SS increments by 1)
7) GPU begins work on new data

If so does enabling --submit-stale option cause it to work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
5) If GPU finds a share that share will still be submitted. (If actually stale R increments by one otherwise A increments by 1)
6) GPU begins work on new data

The reason I ask is because it is possible the LP is from new transactions or NMC header change and the share is still valid for BTC. 
I understanding using --submit-stale option will potentially increase rejects but if I understand this right.

SS + R should be equal regardless of if --submit-stale is used or not.  Right?

It makes me think I should use -submit-stale.  The only downside is that it increases potential workload for the server.  The upside is that I may gain a few more accepted shares.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
1 BTC for you ckolivas, you deserve it.

And another to kano, thanks for your hints.
Thanks, much appreciated =)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 2.0.8, links in top post as always.

Version 2.0.8 - November 11, 2011

- Make longpoll do a mandatory flushing of all work even if the block hasn't
changed, thus supporting longpoll initiated work change of any sort and merged
mining.
- Byteswap computed hash in hashtest so it can be correctly checked. This fixes
the very rare possibility that a block solve on solo mining was missed.
- Add x86_64 w64 mingw32 target
- Allow a fixed speed difference between memory and GPU clock speed with
--gpu-memdiff that will change memory speed when GPU speed is changed in
autotune mode.
- Don't load the default config if a config file is specified on the command
line.
- Don't build VIA on apple since -a auto bombs instead of gracefully ignoring
VIA failing.
- Build fix for dlopen/dlclose errors in glibc.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
In preparation for a new version, I finally stopped my main miner that was running 2.0.7 for the longest period I've run cgminer for. I figured I should post what my miner ran like for that time period. Bear in mind I was load balancing so the reject rate would be slightly higher.


[2011-11-11 19:47:02] Started at [2011-10-26 07:04:04]
[2011-11-11 19:47:02] Runtime: 396 hrs : 42 mins : 58 secs
[2011-11-11 19:47:02] Average hashrate: 1749.3 Megahash/s
[2011-11-11 19:47:02] Solved blocks: 2
[2011-11-11 19:47:02] Queued work requests: 612950
[2011-11-11 19:47:02] Share submissions: 569593
[2011-11-11 19:47:02] Accepted shares: 567274
[2011-11-11 19:47:02] Rejected shares: 2319
[2011-11-11 19:47:02] Reject ratio: 0.4
[2011-11-11 19:47:02] Hardware errors: 0
[2011-11-11 19:47:02] Efficiency (accepted / queued): 93%
[2011-11-11 19:47:02] Utility (accepted shares / min): 23.83/min

[2011-11-11 19:47:02] Discarded work due to new blocks: 29680
[2011-11-11 19:47:02] Stale submissions discarded due to new blocks: 274
[2011-11-11 19:47:02] Unable to get work from server occasions: 1220
[2011-11-11 19:47:02] Work items generated locally: 31636
[2011-11-11 19:47:02] Submitting work remotely delay occasions: 956
[2011-11-11 19:47:02] New blocks detected on network: 2191

[2011-11-11 19:47:02] Summary of per device statistics:

[2011-11-11 19:47:02] GPU0 74.5C 5321RPM | (5s):450.0 (avg):442.6 Mh/s | A:143414 R:593 HW:0 U:6.03/m I:9
[2011-11-11 19:47:02] GPU1 73.5C 5266RPM | (5s):428.8 (avg):426.4 Mh/s | A:138718 R:547 HW:0 U:5.83/m I:9
[2011-11-11 19:47:02] GPU2 74.0C 5558RPM | (5s):430.1 (avg):430.9 Mh/s | A:139513 R:560 HW:0 U:5.86/m I:9
[2011-11-11 19:47:02] GPU3 73.5C 4479RPM | (5s):443.9 (avg):449.4 Mh/s | A:145629 R:619 HW:0 U:6.12/m I:9
newbie
Activity: 16
Merit: 0
Every so often CG will get semi stuck loading and continue to scroll lines simular to these instead of snaping over to the usual info screen. When it does this it gets stuck in a 100% cpu cycle as well. Anyone ran into this or know a trick to make it snap out of this?  Runing on Linuxcoin


GPU3 65.5C 4416RPM | (5s):367.7 (avg):377.8 Mh/s | A:4 R:0 HW:0 U:4.28/m I:8
[2011-11-11 05:18:00] Accepted 00000000.20423bc9.16f0315a GPU 3 thread 3 pool 0
GPU3 65.5C 4424RPM | (5s):367.2 (avg):364.7 Mh/s | A:5 R:0 HW:0 U:4.90/m I:8
[2011-11-11 05:18:15] Accepted 00000000.94461584.8ff63b0c GPU 0 thread 0 pool 0
GPU0 49.5C 3894RPM | (5s):381.7 (avg):301.4 Mh/s | A:6 R:0 HW:0 U:4.72/m I:8
[2011-11-11 05:18:20] Accepted 00000000.5cf906f6.e555ca88 GPU 0 thread 4 pool 0
GPU0 49.5C 3893RPM | (5s):360.2 (avg):304.5 Mh/s | A:7 R:0 HW:0 U:5.16/m I:8
[2011-11-11 05:18:30] Accepted 00000000.8b064e1b.0dd4d4b1 GPU 3 thread 3 pool 0
GPU3 67.5C 4408RPM | (5s):365.8 (avg):365.0 Mh/s | A:6 R:0 HW:0 U:3.94/m I:8
[2011-11-11 05:18:30] Accepted 00000000.17fb4ae9.423f126f GPU 0 thread 4 pool 0
GPU0 49.5C 3891RPM | (5s):300.5 (avg):299.0 Mh/s | A:8 R:0 HW:0 U:5.25/m I:8
[2011-11-11 05:18:35] Accepted 00000000.f760b72e.86c3089d GPU 0 thread 4 pool 0
GPU0 49.5C 3899RPM | (5s):248.0 (avg):299.9 Mh/s | A:9 R:0 HW:0 U:5.60/m I:8
[2011-11-11 05:18:43] Accepted 00000000.59468a07.537e6686 GPU 0 thread 4 pool 0
GPU0 49.5C 3903RPM | (5s):379.4 (avg):295.9 Mh/s | A:10 R:0 HW:0 U:5.63/m I:8
[2011-11-11 05:18:52] Accepted 00000000.dad5cb3c.2d27ac9d GPU 1 thread 5 pool 0
full member
Activity: 235
Merit: 100
does CGMiner support NMC?

As in merged mining?

No miner has any concept of what it is mining.  It simply gets data from the pool server and hashes it.

The good news is that it means yes cgminer supports NMC.  The bad news this "dumb miner" concept is what makes large pools dangerous.

yes as in merged mining.
BTCGuild has just enabled it on their pool and was wondering if CGMiner suports it.
i don't know what goes on in the code of CGMiner... or any miner realy...
i just run the app and it makes me coins.

Then yes.  All miners support merged mining because the miner has no clue what it is mining.  It simply gets some data and hashes it returning the good hashes.  It is all just numbers to the mining engine.
Great thanks.
one less thing to configure Smiley
donator
Activity: 1218
Merit: 1079
Gerald Davis
does CGMiner support NMC?

As in merged mining?

No miner has any concept of what it is mining.  It simply gets data from the pool server and hashes it.

The good news is that it means yes cgminer supports NMC.  The bad news this "dumb miner" concept is what makes large pools dangerous.

yes as in merged mining.
BTCGuild has just enabled it on their pool and was wondering if CGMiner suports it.
i don't know what goes on in the code of CGMiner... or any miner realy...
i just run the app and it makes me coins.

Then yes.  All miners support merged mining because the miner has no clue what it is mining.  It simply gets some data and hashes it returning the good hashes.  It is all just numbers to the mining engine.
full member
Activity: 235
Merit: 100
does CGMiner support NMC?

As in merged mining?

No miner has any concept of what it is mining.  It simply gets data from the pool server and hashes it.

The good news is that it means yes cgminer supports NMC.  The bad news this "dumb miner" concept is what makes large pools dangerous.

yes as in merged mining.
BTCGuild has just enabled it on their pool and was wondering if CGMiner suports it.
i don't know what goes on in the code of CGMiner... or any miner realy...
i just run the app and it makes me coins.
donator
Activity: 1218
Merit: 1079
Gerald Davis
does CGMiner support NMC?

As in merged mining?

No miner has any concept of what it is mining.  It simply gets data from the pool server and hashes it.

The good news is that it means yes cgminer supports NMC.  The bad news this "dumb miner" concept is what makes large pools dangerous.

full member
Activity: 235
Merit: 100
does CGMiner support NMC?
jr. member
Activity: 39
Merit: 1
unfortunately it doesn't Sad
Jump to: