ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 14, 2012, 10:57:02 PM 

Sorry if this has been asked many times, but why is one version stable, and another version is simply latest, what does it take to get a version to be stable. I ask because 2.8.3 is crashing about every 3 days.
I think you answered your own question... I will only call 2.8.x stable once it is stable everywhere. I'm trying hard to find the remaining bug(s) in 2.8.3, and it appears to only be affecting windows users, but the bug is eluding me.







BOUNTY PORTALS BLOG WHERE BOUNTY MANAGEMENT MEETS AUTOMATION SIGNATURE CAMPAIGNS TWITTER FACEBOOK MEDIA CAMPAIGNS AND MORE!



Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 14, 2012, 11:27:40 PM 

Just updated to 2.8.3. I have to say I really don't like the new precision on numeric output: GPU 0: 73.0C 2900RPM  604.2M/661.2Mh/s  A:3 R:0 HW:0 U: 7.03/m I: 9 GPU 1: 74.0C 2912RPM  595.1M/659.3Mh/s  A:5 R:0 HW:0 U:11.72/m I: 9 GPU 2: 74.0C 2922RPM  611.8M/658 Mh/s  A:10 R:0 HW:0 U:23.44/m I: 9 Could you put a .0 on there instead of all that blank space? It's a minor thing, but I like it better that way. This is a side effect of trying to find a generic format that is aligned on the screen and fits values from 0 to 18,446,744,073,709,551,616 in a generic way, while still maintaining adequate precision for the relative rate for that device. It is not entirely straight forward and what to do about zeroes is not ever going to be to everyone's satisfaction. 001.0 or 01.00 or 1.000 ? By the way, that massive value would show up as 18.45EH/s with that current scheme, so that it could show up aligned on the same screen as something with 0.001 H/s.




jasinlee


October 14, 2012, 11:30:33 PM 

Current code ./cgminer scrypt o http://ltc.kattare.com:9332 u jasinlee.1 p 1 g 1 threadconcurrency 8000 I 18 w 256 autofan I Assume this probably has to do something with it. [20121014 21:35:49] Failed to init GPU thread 0, disabling device 0 [20121014 21:35:49] Restarting the GPU from the menu will not fix this. [20121014 21:35:49] Try restarting cgminer. Press enter to continue:
[20121014 21:36:09] Your scrypt settings come to 524288000 [20121014 21:36:09] Error 61: clCreateBuffer (padbuffer8), decrease CT or i ncrease LG [20121014 21:36:09] Failed to init GPU thread 7, disabling device 7
Oh, use threadconcurrency 7168 or 5632. that's cgminer sucking because of ocl memory consumption problems. Any ideas you could give us on this ? Tried so many things already and its just not quite working.




Vbs


October 15, 2012, 12:16:51 AM 

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! #elif defined VECTORS2 uint result = W[117].x ? 0u:W[3].x; result = W[117].y ? result:W[3].y; if (result) SETFOUND(result);




ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 15, 2012, 12:53:13 AM 

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! #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




kano
Legendary
Offline
Activity: 2548
Merit: 1052
Linux since 1997 RedHat 4


October 15, 2012, 03:46:37 AM 

After messing with the MMQ initialisation code for a while I've rewritten it and solved the hang I was getting. It's not in any git yet. Is anyone using (working) cgminer on an MMQ on linux at the moment? If so  what do all of uname r cat /etc/*release ls las /dev/tty[AU]* return? As I've mentioned before, the current git code just hangs during initialisation for me on Xubu 11.04 and Fedora 17 and it's due to termios not handling the ACM device as a tty on both my linux versions I'm going to redo the old Frequency management code (cgminer doesn't currently contain the newer Frequency code in BarbieMiner) then put up a pull with just those 2 changes so people can try it out and let me know if there are any problems with them The initialisation change is only for linux Redoing the threading will be done next after that

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1 KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU 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!



Lem
Jr. Member
Offline
Activity: 78
Merit: 0


October 15, 2012, 07:10:04 AM 

I'm using 2.8.3 with Linux. I mine on many pools, and I do hop on some of them, having the others as backups, so pool switches are common here. My only stratum pool is Slush. I have it in my configuration file as: "url" : "http://api.bitcoin.cz:8332" so I leave it to cgminer to recognize ad activate the stratum protocol, which it does: Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://apistratum.bitcoin.cz:3333 But after a few hours that cgminer is running, I always find this stratum pool as "Enabled Dead". While mining on another pool, in the log I see things like: [20121015 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding! [20121015 01:31:51] Pool 7 http://api.bitcoin.cz:8332 alive but, checking immediately after that, in the Pools section the pool is showed as "Enabled Dead", and it will remain dead forever. As soon as I restart cgminer, the pool is alive again (so it's not a pool problem). I don't know if it happens every time the pool doesn't respond for a while, or whenever my box changes its IP address. I'm just sure it happens at least every few hours. HTH.

 Bye



Krak


October 15, 2012, 07:24:47 AM 

I'm using 2.8.3 with Linux. I mine on many pools, and I do hop on some of them, having the others as backups, so pool switches are common here. My only stratum pool is Slush. I have it in my configuration file as: "url" : "http://api.bitcoin.cz:8332" so I leave it to cgminer to recognize ad activate the stratum protocol, which it does: Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://apistratum.bitcoin.cz:3333 But after a few hours that cgminer is running, I always find this stratum pool as "Enabled Dead". While mining on another pool, in the log I see things like: [20121015 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding! [20121015 01:31:51] Pool 7 http://api.bitcoin.cz:8332 alive but, checking immediately after that, in the Pools section the pool is showed as "Enabled Dead", and it will remain dead forever. As soon as I restart cgminer, the pool is alive again (so it's not a pool problem). I don't know if it happens every time the pool doesn't respond for a while, or whenever my box changes its IP address. I'm just sure it happens at least every few hours. HTH. I noticed this also when I used BTC Guild as a backup for a while. I just assumed they were sick of me using them for detecting new blocks sooner without actually giving much work back; I had just as many getworks with them as I did with my primary pool.

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn



Vbs


October 15, 2012, 09:51:45 AM 

#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 Thanks for the detailed explanation! Some more food for thought: I think the bitmasked stuff was probably the biggest problem (because the less 1's the nonce has, the bigger the probability of it being lost IIRC), that's why on the above code there is no bitmasking for checking for nonces, it uses the SETA op code IIRC (the C "?" operand gets a specific gpu isa op code). A specific nonce value of 0 also happens at a rate of P = 1/(2^64) [P_finding_nonce = 1/(2^32), P_nonce_is_all_zeros = 1/(2^32)], so that's also fine by me. About the global worksize bitmasked problem, if not using bitmasks, the only way for overwrites to happen would be if 2 identical bitwise nonces were found, correct? I will also try the tiny mem o/c to see the hashrate diference when using the atomic_add, I like to try all angles to solve a problem, thanks! Btw, since I haven't yet, 1btc donation sent! I can only imagine the number of hours you spent writing and optimizing cgminer's code!




ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 15, 2012, 10:35:17 AM 

About the global worksize bitmasked problem, if not using bitmasks, the only way for overwrites to happen would be if 2 identical bitwise nonces were found, correct? Btw, since I haven't yet, 1btc donation sent! I can only imagine the number of hours you spent writing and optimizing cgminer's code! With bitmasked ones, if the bitmask is only 127, 7 bits need to be in common with anything out of the 4 billion nonces. Again rare but not 2^64 rare. With non bitmasked, 2 or more nonces need to be found in a "wavefront" concurrently and can race on the array variable in FOUND. They can be completely different nonces in that case since they're just trying to access exactly the same variable at the same time without protection. Instead of there being 2 nonces flagged as existing, it could be 0,1,2 or a much larger number, and the slots used for the nonces could be anywhere. In other words, the only "strictly correct" way to do it without there being any chance of error is with the atomic ops. Now how well implemented the atomic ops are in hardware and how much they depend on software is a totally different equation that I can't answer, and AMD is unlikely to tell us. Thanks for the donation




amigaman


October 15, 2012, 10:50:34 AM 

Yes but it is only absolutely tiny amounts of time the load drops and may not even visible in the reported GPU load which isn't an accurate measure anyway.
I only show fan percentage when fan RPM is not available for that particular device. The reason? The fan percentage is just the value you have told the device to run... it could happily say 55% and the fan may have stopped spinning for some reason which is inherently dangerous. The fan speed rpm is a monitor, it is not a setting.
Yes, that is right, but it is hard for me to recognize if 2857rpms are ok or not. All my 6 units have slightly different rpms for the given percent. But: the regulation uses temperature to calculate the needed percentage. So as long as temperature is in ok ranges, fan percentage is lower then the set max, and when i see 52% i know all is well, at 55% i know something gets too warm, either i have to check fans or switch my ac on. But fan rpm is needed also, so my request was to display fan percentage additionally.




Vbs


October 15, 2012, 01:36:50 PM 

With bitmasked ones, if the bitmask is only 127, 7 bits need to be in common with anything out of the 4 billion nonces. Again rare but not 2^64 rare. With non bitmasked, 2 or more nonces need to be found in a "wavefront" concurrently and can race on the array variable in FOUND. They can be completely different nonces in that case since they're just trying to access exactly the same variable at the same time without protection. Instead of there being 2 nonces flagged as existing, it could be 0,1,2 or a much larger number, and the slots used for the nonces could be anywhere. In other words, the only "strictly correct" way to do it without there being any chance of error is with the atomic ops. Now how well implemented the atomic ops are in hardware and how much they depend on software is a totally different equation that I can't answer, and AMD is unlikely to tell us. Thanks for the donation Still, the odds for concurrency are very very low. A nonce find can be modeled by a Poisson distribution with lambda=1/(2^32). Taking the example of a 1GHS card (sum of all wavefronts speed/second):
lambda = 1/(2^32) Poisson(k) = (lambda^k)*(exp^(lambda))/(k!)
Probability of finding 2 nounces (at the same time) per second: P = Poisson(2)*1E9 = 2.7105e11 = ~.0000000027%




Lem
Jr. Member
Offline
Activity: 78
Merit: 0


October 15, 2012, 02:52:16 PM 

Still, the odds for concurrency are very very low. A nonce find can be modeled by a Poisson distribution with lambda=1/(2^32). Taking the example of a 1GHS card (sum of all wavefronts speed/second):
lambda = 1/(2^32) Poisson(k) = (lambda^k)*(exp^(lambda))/(k!)
Probability of finding 2 nounces (at the same time) per second: P = Poisson(2)*1E9 = 2.7105e11 = ~.0000000027%
Sorry, I haven't followed your whole discussion, but as soon as I read this message it looked to me a bit weird. I apologize in advance if I have misread or misunderstood something. In Poisson distribution, the period of time taken into account is fixed. Let's call it T. Lambda is the mean of Poisson distribution (and its variance too). So with lambda=1/2^32 you're stating that you expect to find 1/2^32 nonces in T. That is: you expect to wait (2^32) Ts to find a single nonce. R U sure? And what do you mean with: Poisson(2)*1E9 Besides, your calculation looks wrong. With lambda=1/2^32, P(2) is ... almost zero. P(2)*1E9 isn't much more, and we can round it to zero as well.

 Bye



Vbs


October 15, 2012, 03:48:01 PM 

Sorry, I haven't followed your whole discussion, but as soon as I read this message it looked to me a bit weird. I apologize in advance if I have misread or misunderstood something. In Poisson distribution, the period of time taken into account is fixed. Let's call it T. Lambda is the mean of Poisson distribution (and its variance too). So with lambda=1/2^32 you're stating that you expect to find 1/2^32 nonces in T. That is: you expect to wait (2^32) Ts to find a single nonce. R U sure? And what do you mean with: Poisson(2)*1E9 Besides, your calculation looks wrong. With lambda=1/2^32, P(2) is ... almost zero. P(2)*1E9 isn't much more, and we can round it to zero as well. That's correct, you are expecting to find 1 nonce out of 2^32 cases in T=1/(GPU hashes per timeframe). On the example above, T=1/(1E9). Each processed 32bit hash has a probability of 1/(2^32) of being a nonce. So a card that processes 1.000.000 hashes/s has a probability of finding one each (2^32)/1E9 = 4.3 seconds. My above Poisson math is for the case of 2 simultaneous nonce finds (that's why lambda=1/(2^32) and not lambda=1/(2^32)*1E9).




Lem
Jr. Member
Offline
Activity: 78
Merit: 0


October 15, 2012, 05:31:14 PM 

My above Poisson math is for the case of 2 simultaneous nonce finds (that's why lambda=1/(2^32) and not lambda=1/(2^32)*1E9).
This is what I don't understand too well (sorry to bother you). Let's assume, as you wrote, that your device has 1GH/s of computing power. So what T do you like to choose? If you choose T=1 sec, then the probabilty to find one nonce in T is the mean, so is lambda. Lambda is 1/4.3=0.23. 23%. The probability to find two nonces in T, according to Poisson distribution, is ((0.2325^2)*e^0.2325)/2!=0.021. 2,1%. If you choose T=1/1E9 sec, AKA the clock tick duration of your device, then I calculate the probability to simultaneously find two or more nonces this way: a) if your device processes hashes sequentially (one thread), of course there cannot be simultaneous nonces if we consider T=1/1E9 sec =1/(GPU hashes per timeframe); b) if your device processes more than one hash simultaneously (more threads), there can be simultaneous nonces, but every thread uses just a part of the device computing power. Let's say we have five threads. Each thread is capable of 200MH/s, so it finds a nonce in about 21.47 sec (that is: 2^32 H / 200MH/s) In 1/1E9 sec each thread finds a mean of 1/21.47G nonces. The probability that at least N of our five threads find a nonce in the same clock is 1/21.47G^N. We can say zero, and we don't need any Poisson distribution for it.

 Bye



ryann
Member
Offline
Activity: 70
Merit: 10


October 15, 2012, 08:11:18 PM 

I used the new 2.8.3 and its noticeably slower for some reason. My Mhash is the same as 2.7.5 but the the accepts shares are like significantly less. I usually do about 600 shares an hour with this im doing 120 shares




amigaman


October 15, 2012, 08:26:34 PM 

Do you have higher difficulty? If you use stratum protocol and your workers give too much hashes, the pool increases difficulty for you, so you have less shares but get paid better per share. CGM shows that in the shares line.




ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 15, 2012, 08:28:27 PM 

I'm using 2.8.3 with Linux. I mine on many pools, and I do hop on some of them, having the others as backups, so pool switches are common here. My only stratum pool is Slush. I have it in my configuration file as: "url" : "http://api.bitcoin.cz:8332" so I leave it to cgminer to recognize ad activate the stratum protocol, which it does: Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://apistratum.bitcoin.cz:3333 But after a few hours that cgminer is running, I always find this stratum pool as "Enabled Dead". While mining on another pool, in the log I see things like: [20121015 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding! [20121015 01:31:51] Pool 7 http://api.bitcoin.cz:8332 alive but, checking immediately after that, in the Pools section the pool is showed as "Enabled Dead", and it will remain dead forever. As soon as I restart cgminer, the pool is alive again (so it's not a pool problem). I don't know if it happens every time the pool doesn't respond for a while, or whenever my box changes its IP address. I'm just sure it happens at least every few hours. HTH. I noticed this also when I used BTC Guild as a backup for a while. I just assumed they were sick of me using them for detecting new blocks sooner without actually giving much work back; I had just as many getworks with them as I did with my primary pool. I haven't seen this myself but there could well still be a bug in there. I'll keep auditing code.




Vbs


October 15, 2012, 10:27:14 PM 

This is what I don't understand too well (sorry to bother you).
Let's assume, as you wrote, that your device has 1GH/s of computing power.
So what T do you like to choose?
If you choose T=1 sec, then the probabilty to find one nonce in T is the mean, so is lambda. Lambda is 1/4.3=0.23. 23%. The probability to find two nonces in T, according to Poisson distribution, is ((0.2325^2)*e^0.2325)/2!=0.021. 2,1%.
Depends on what question you are trying to solve. The question you answered above is "What is the probability of finding k nonces in a period of 1s? And in a period of 2s?" That was not the question I was answering. My question was "What is the probability of finding k nonces at the same time?" If you choose T=1/1E9 sec, AKA the clock tick duration of your device, then I calculate the probability to simultaneously find two or more nonces this way: a) if your device processes hashes sequentially (one thread), of course there cannot be simultaneous nonces if we consider T=1/1E9 sec =1/(GPU hashes per timeframe); b) if your device processes more than one hash simultaneously (more threads), there can be simultaneous nonces, but every thread uses just a part of the device computing power. Let's say we have five threads. Each thread is capable of 200MH/s, so it finds a nonce in about 21.47 sec (that is: 2^32 H / 200MH/s). In 1/1E9 sec each thread finds a mean of 1/21.47G nonces.
The problem is independent of thread execution time, because that is relatively constant. They all end at mostly the same time in a wavefront. The problem is: when they all end, how many have nonces? The probability that at least N of our five threads find a nonce in the same clock is 1/21.47G^N. We can say zero, and we don't need any Poisson distribution for it.
When n>inf and p>0 the Poisson follows the Binomial, so either gives the same results: https://en.wikipedia.org/wiki/Poisson_limit_theoremI can rewrite everything in another way, using another example: Assuming each wavefront composed of 256 threads with 2 vectors each:
lambda = 1/(2^32)*256*2 Poisson(k) = (lambda^k)*(exp^(lambda))/(k!)
Probability of finding 1 nounce in a wavefront: P = Poisson(1) = 1.1921e07 P = Binomial(1, 512, 1/(2^32)) = 1.1921e07
Probability of finding 2 nounces in a wavefront: P = Poisson(2) = 7.1054e15 P = Binomial(2, 512, 1/(2^32)) = 7.0915e15
Either way we look at the problem, the answer is always the same: the probability of finding 2 nonces at the same time is 10^8 smaller than for finding 1 nonce! In another words, a ~0.1 Exahash/s hardware will find 2 nonces simultaneously at about the same rate a 1GH/s card finds 1 nonce right now.




ck
Moderator
Legendary
Offline
Activity: 2618
Merit: 1123
Ruu \o/


October 15, 2012, 10:34:38 PM 

Don't forget modern GPUs have up to 2048 shaders...




