<<  >> (p.149)
    Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806488 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. (3 posts by 1+ user deleted.)

    • kano
    Legendary
    *
    Offline Offline

    Activity: 4690
    Merit: 1859


    Linux since 1997 RedHat 4


    View Profile
    January 17, 2012, 08:42:46 PM
     #2961
    Quote from: DutchBrat on January 17, 2012, 08:16:40 PM
    ...
    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 - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
    Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
    The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 17, 2012, 08:54:20 PM
     #2962
    Quote from: kano on January 17, 2012, 08:42:46 PM
    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, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • Remember remember the 5th of November
    Legendary
    *
    Offline Offline

    Activity: 1862
    Merit: 1018

    Reverse engineer from time to time


    View Profile
    January 17, 2012, 09:30:57 PM
     #2963
    Quote from: ckolivas on January 17, 2012, 08:54:20 PM
    Quote from: kano on January 17, 2012, 08:42:46 PM
    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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 17, 2012, 09:33:03 PM
     #2964
    Quote from: Remember remember the 5th of November on January 17, 2012, 09:30:57 PM
    Quote from: ckolivas on January 17, 2012, 08:54:20 PM
    Quote from: kano on January 17, 2012, 08:42:46 PM
    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, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • gnar1ta$
    Donator
    Hero Member
    *
    Offline Offline

    Activity: 798
    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: 4690
    Merit: 1859


    Linux since 1997 RedHat 4


    View Profile
    January 17, 2012, 10:43:06 PM
     #2966
    Quote from: gnar1ta$ on January 17, 2012, 09:56:21 PM
    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 - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
    Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
    The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 17, 2012, 10:47:45 PM
     #2967
    Quote from: kano on January 17, 2012, 10:43:06 PM
    Quote from: gnar1ta$ on January 17, 2012, 09:56:21 PM
    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, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • gnar1ta$
    Donator
    Hero Member
    *
    Offline Offline

    Activity: 798
    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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 18, 2012, 12:15:07 AM
     #2969
    Quote from: ckolivas on January 17, 2012, 09:33:03 PM
    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, ckpool/ckproxy, and the -ck kernel
    2% 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
    Quote from: kano on January 15, 2012, 11:46:10 AM
    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 thedev/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: 4690
    Merit: 1859


    Linux since 1997 RedHat 4


    View Profile
    January 18, 2012, 12:23:21 AM
     #2971
    Quote from: gnar1ta$ on January 17, 2012, 11:32:27 PM
    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 - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
    Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
    The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer

  • -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 18, 2012, 12:24:22 AM
     #2972
    Quote from: kano on January 18, 2012, 12:23:21 AM
    Quote from: gnar1ta$ on January 17, 2012, 11:32:27 PM
    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, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck

  • gnar1ta$
    Donator
    Hero Member
    *
    Offline Offline

    Activity: 798
    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
    Quote from: gnar1ta$ on January 18, 2012, 01:05:28 AM
    ... Why does merged mining suck? ...

    You answered that yourself:
    Quote from: gnar1ta$ on January 17, 2012, 11:32:27 PM
    ...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
    Quote from: gnar1ta$ on January 18, 2012, 01:05:28 AM
    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: 1184


    Gerald Davis


    View Profile
    January 18, 2012, 01:21:11 AM
    Last edit: January 18, 2012, 01:58:24 AM by DeathAndTaxes
     #2976
    Quote from: jake262144 on January 18, 2012, 01:13:40 AM
    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: 798
    Merit: 500


    View Profile
    January 18, 2012, 01:38:40 AM
     #2977
    Quote from: DeathAndTaxes on January 18, 2012, 01:21:11 AM
    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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 4550
    Merit: 1672


    Ruu \o/


    View Profile WWW
    January 18, 2012, 01:41:11 AM
     #2978
    Quote from: gnar1ta$ on January 18, 2012, 01:38:40 AM
    Quote from: DeathAndTaxes on January 18, 2012, 01:21:11 AM
    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, ckpool/ckproxy, and the -ck kernel
    2% 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
    Last edit: January 21, 2012, 10:50:57 AM by jake262144
     #2979
    Quote from: DeathAndTaxes on January 18, 2012, 01:21:11 AM
    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: 1184


    Gerald Davis


    View Profile
    January 18, 2012, 02:08:59 AM
     #2980
    Quote from: jake262144 on January 18, 2012, 01:57:22 AM
    Quote from: DeathAndTaxes on January 18, 2012, 01:21:11 AM
    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 ... 843 »
      Print  
Page 148
Viewing Page: 149

IRLBTC™ © 2025 IRLBTC.com