<<  >> (p.378)
    Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806573 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.)
    -ck (OP)
    Legendary
    *
    Offline Offline

    Activity: 4578
    Merit: 1695


    Ruu \o/


    View Profile WWW
    October 15, 2012, 12:53:13 AM
     #7541

    Yes that is interesting. I'm guessing you have underclocked your memory exceptionally low, as that was found to be an issue with use of atomic ops. Some people found a bump of 15 in memory was enough to correct it. Lack of atomic functions there could lead to HW errors and loss of shares. It's a tradeoff either way. The change was put in there to make sure no shares were lost, which can happen with the old opencl code (though it's only a very small number that would be lost).

    Ah, ok! Thanks for the info. Yep, I'm at 150MHz mem clock. It's to prevent the case of simultaneous nonce finds on different vectors to overwrite the result on the same address, right?

    I prefer the tradeoff tbh, I did the math a while ago on the probability of that happening (P=1/(2^32)*1/(2^32)=1/(2^64). On a 1GH/s card, that will happen on average once every ~585 years)

    I'm still using that optimization tradeoff I posted for more than a year now! Grin
    Code:
    #elif defined VECTORS2
    uint result = W[117].x ? 0u:W[3].x;
                 result = W[117].y ? result:W[3].y;
    if (result)
         SETFOUND(result);
    No, you're not quite right there btw. There are a few issues that made me use the atomic ops instead.

    There is no way to return a nonce value of 0.
    Bitmasked nonce values can also be zero meaning they get lost.
    It is not just vectors that find nonces at the same time, it's a whole wave front of threads finding nonces at the same time and corrupting both values.
    Bitmasked nonce values from results found in the same global worksize can come out the same value and overwrite each other.
    It's to consolidate the return values from different kernels and decrease the CPU usage of the return code that checks the nonce values.

    Again, very small but far from 2^64. Since bitcoin mining is a game of odds, I didn't see the point of losing that - provided you don't drop the hashrate of course. It's unusual that some devices need higher memory speed just for one atomic op but clearly it's a massively memory intensive operation that affects the whole wave front. Considering increasing ram speed by 15 or 20 would not even register in terms of extra power usage and temperature generated, to me at least it seems a better option.

    But the beauty of free software is you can do whatever you like to the code if you don't like the way I do it Wink

    Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
    2% Fee Solo mining at solo.ckpool.org
    -ck
Page 377
Viewing Page: 378