Bitcoin Forum
September 20, 2018, 03:36:55 PM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 [149] 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5761932 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kano
Legendary
*
Offline Offline

Activity: 2576
Merit: 1053


Linux since 1997 RedHat 4


View Profile
January 17, 2012, 08:42:46 PM
 #2961

...
Yes unfortunately I do, I have 9 rigs, 2 with 2 GPU's and the rest with only 1.

I know what efficiency means, was just wondering why it is so different for different people.
I have no idea what influences efficiency

Using mainly 5800's 2 6950's

I am using default settings, no overclocking, intensity 8

I am not worried about the Performance, was just wondering about the low efficiency
Ah they're not your computers?
No one would run an extra 120+W per card on purpose Tongue
Maybe work owns them?

A work request represents 2^32 hash attempts (without using rollntime)
For a good quality 6950 on default settings (e.g. GB HD 6950 900Mhz/775Mhz = ~365Mh/s) it should take about 11.77 seconds to complete the full 2^32 hash tests.
However, if it should get any LP messages during that 11.77 seconds then (by supposed definition) all the work requests queued and being worked on will be thrown away and give no more results than what has already been submitted - thus reducing your efficiency.

A higher intensity will make that worse also since it increases how long the GPU is working without replying.
A lower hash rate will also decrease efficiency for the same reason.

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
1537457815
Hero Member
*
Offline Offline

Posts: 1537457815

View Profile Personal Message (Offline)

Ignore
1537457815
Reply with quote  #2

1537457815
Report to moderator
1537457815
Hero Member
*
Offline Offline

Posts: 1537457815

View Profile Personal Message (Offline)

Ignore
1537457815
Reply with quote  #2

1537457815
Report to moderator
1537457815
Hero Member
*
Offline Offline

Posts: 1537457815

View Profile Personal Message (Offline)

Ignore
1537457815
Reply with quote  #2

1537457815
Report to moderator
Some PGP public keys you should import: theymos, Wladimir, Gregory, Pieter
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537457815
Hero Member
*
Offline Offline

Posts: 1537457815

View Profile Personal Message (Offline)

Ignore
1537457815
Reply with quote  #2

1537457815
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 17, 2012, 08:54:20 PM
 #2962

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.
This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1750
Merit: 1001

Reverse engineer from time to time


View Profile
January 17, 2012, 09:30:57 PM
 #2963

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.
This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.
This sounds a bit wrong. The scantime would be understandable for a slower card that cannot do 2^32 in 60 seconds, but, for a fast card it takes seconds to test them all.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 17, 2012, 09:33:03 PM
 #2964

If the pool does merged mining and is sending non-BTC LP's (i.e. more than just a single BTC LP per network block) to you, it will reduce your efficiency that way.
This is the most likely reason.

If you want to increase efficiency (for the pool's sake, not yours), decrease thread count to 1 and increase scan time to say 115 seconds.
This sounds a bit wrong. The scantime would be understandable for a slower card that cannot do 2^32 in 60 seconds, but, for a fast card it takes seconds to test them all.
Increasing scantime will allow cgminer to roll the work for longer. Scantime affects rolltime expiration as well.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 784
Merit: 500


View Profile
January 17, 2012, 09:56:21 PM
 #2965

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
kano
Legendary
*
Offline Offline

Activity: 2576
Merit: 1053


Linux since 1997 RedHat 4


View Profile
January 17, 2012, 10:43:06 PM
 #2966

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?
U is proportional to income ... directly ...
If it is now 1/10 over a long period of time - that's bad.
Edit: assuming a share is still worth the same amount ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 17, 2012, 10:47:45 PM
 #2967

On the scantime and intensity topic.  Should scantime be increased and intensity decreased when mining on p2pool? I know it works a bit different than regular pools and on my 6950 rig where I usually have an E of 140% and U of 29.xx I now have an E of 4% and U of 3.45.  Am I overworking or underworking the cards?
U is proportional to income ... directly ...
If it is now 1/10 over a long period of time - that's bad.
No, changing to p2pool changes the meaning of everything. I can't directly equate the numbers changing from one to the other, but this is not bad. I don't know enough about p2pool to suggest how to tune it, but I suspect the cgminer defaults are best still.

Also note I wasn't suggesting people try to improve their efficiency since it usually adversely affects the miner... I was just explaining how you might go about it.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 784
Merit: 500


View Profile
January 17, 2012, 11:32:27 PM
 #2968

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 18, 2012, 12:15:07 AM
 #2969

Increasing scantime will allow cgminer to roll the work for longer. Scantime affects rolltime expiration as well.
This is assuming you are on a pool that supports rolltime and allows it for cgminer by the way...

edit: Oh and decreasing -q would also "help" efficiency.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
January 18, 2012, 12:20:35 AM
 #2970

I will also add that the detection explanation seems extremely strange.
Whenever you plug a USB device into a linux system you see messages in dmesg about the identity of the device.
That information (however you get access to it) should be enough to know what it is shouldn't it?
Or are they not handling the USB connection with identity information like every other USB device on the planet I've plugged into a linux box?
It may already be obvious to you, but since no one else responded to this, and it seems rather obvious to me (granted, I only have a guess as they didn't state this in their post), I will.  The reason you have to query the device is because it is communicating through an emulated serial port (hence the /dev/tty# in *nix and COM# in Windows).  The benefit to that is there is no driver to maintain, dmesg will detect a new serial port for which most OSes already have a native driver.  If I am correct, they could have manufactured the device with a real serial port instead, but I'm not sure there would be much to gain from that.  One downside I just thought of, if I am correct, is that the usb devices per port/hub limit may not matter if the operating systems in question have a lower limit on the number of com ports they will support.
kano
Legendary
*
Offline Offline

Activity: 2576
Merit: 1053


Linux since 1997 RedHat 4


View Profile
January 18, 2012, 12:23:21 AM
 #2971

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.
Yeah merged mining sux doesn't it ...
Edit: or is p2pool using that same bad design?

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 18, 2012, 12:24:22 AM
 #2972

I'll buy your suspected defaults theory.  I've only been running it constant for 24 hrs (on defaults) but it looks like the reject ratio and payout are the same - short time to make that assumption though.  Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.
Yeah merged mining sux doesn't it ...
Actually he was on p2pool...

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 784
Merit: 500


View Profile
January 18, 2012, 01:05:28 AM
 #2973

p2pool with merged mining for 24hrs and bitcoin only for 24 hrs...numbers were the same, but maybe too short timeframe for real comparison.  Why does merged mining suck? Doesn't the miner just hash what it's given?

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
jake262144
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
January 18, 2012, 01:13:40 AM
 #2974

... Why does merged mining suck? ...

You answered that yourself:
...Just a bit odd looking at those low numbers and seeing 5 longpoll requests to every accepted share.

A NMC block is much easier to find than a BTC block. Each time a NMC block is found, your work is being interrupted by a LP message. The current work and queue needs to be dumped and new work needs to be fetched. If your miner is slow, you might be interrupted relatively often.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
January 18, 2012, 01:17:56 AM
 #2975

p2pool with merged mining for 24hrs and bitcoin only for 24 hrs...numbers were the same, but maybe too short timeframe for real comparison.  Why does merged mining suck? Doesn't the miner just hash what it's given?
Merged mining increases longpolling frequency due to multiple chains experiencing changes, especially when the difficulty of one of those chains is significantly lower.  The negative effect on your mining is a bit of lost work per change.  It would actually potentially be a lot more negative it weren't for longpolling.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
January 18, 2012, 01:21:11 AM
 #2976

A NMC block is much easier to find than a BTC block. Each time a NMC block is found, your work is being interrupted by a LP message. The current work and queue needs to be dumped and new work needs to be fetched. If your miner is slow, you might be interrupted relatively often.

Relatively often is all relative.  NMC block is roughly 2.4x as easy.  That is an extra 1 to 2 LP per block.  When NMC merge mining was new it was more of an issue with 20 to 30 LP per block.

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by someone on the p2pool network and thus requires an LP.
gnar1ta$
Donator
Hero Member
*
Offline Offline

Activity: 784
Merit: 500


View Profile
January 18, 2012, 01:38:40 AM
 #2977

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by the network and thus an LP.

Right, so if my work is being discarded roughly every 10 seconds due to an LP, shouldn't my scantime roughly match that to not waste so much work?

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2646
Merit: 1142


Ruu \o/


View Profile WWW
January 18, 2012, 01:41:11 AM
 #2978

The LP gnar1ta$ was refering to (5 per share) had nothing to do w/ merge mining.  p2pool uses larger shares.  1 p2pool share ~= 150 difficulty 1 shares.  It also builds a share chain to continually recalculate reward split and roughly every 10 seconds a new share will be found by the network and thus an LP.

Right, so if my work is being discarded roughly every 10 seconds due to an LP, shouldn't my scantime roughly match that to not waste so much work?
Exactly the opposite. If you're already forced to throw out work every 10 seconds, the last thing you want to do is throw out any more work than necessary.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
jake262144
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
January 18, 2012, 01:57:22 AM
 #2979

Relatively often is all relative.

***I was hopelessly, utterly, and pathetically wrong, disregard***

His hardware solves 3.45 shares per minute, taking on average 17.3 seconds to find each share.
Statistically, that's just over 34 solved shares per BTC block.
Let's for the sake of clarity of argument (ease of calculations) assume 2 NMC blocks per 1 BTC block.
It translates to over 17 seconds of his work being lost, on average, during each BTC block.
That's nearly 3% performance hit due to merged mining right there.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
January 18, 2012, 02:08:59 AM
 #2980

Relatively often is all relative.

Roger that, here's how I see it from my POV:

His hardware solves 3.45 shares per minute, taking on average 17.3 seconds to find each share.
Statistically, that's just over 34 solved shares per BTC block.

Let's for the sake of clarity of argument (ease of calculations) assume 2 NMC blocks per 1 BTC block.

It translates to over 17 seconds of his work being lost, on average, during each BTC block.
That's nearly 3% performance hit due to merged mining right there.
There's no escaping that, it's just the nature of the beast.

That isn't how it works.  That assumes that the GPU will hash an entire nonce range at one time (2^32 hashes) but it does't.  The number of hashes performed is a fraction of that.  It depends on difficulty, maybe ckolivas can give us the formula.  So when an LP occurs the amount of work lost is much less.

Another way to look at it is the hypothetical miner above processes 34 shares.  If your analysis was right it would have 1 stale out of 34 even when not merged mining and thus could never have a stale rate of <3%.
Pages: « 1 ... 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 [149] 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 ... 847 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!