Bitcoin Forum
December 09, 2016, 04:23:24 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4824083 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.
amigaman
Sr. Member
****
Offline Offline

Activity: 406



View Profile
October 14, 2012, 06:11:02 PM
 #7581

This post is the most interesting and do you know why? The GPU code is UNCHANGED between 2.7.6 and 2.8.3. The only thing that is different is the stratum code. Now why would that make your GPUs SICK now when they didn't previously? Because with the stratum code, the device is busier than ever. There is no possible way to keep the device as busy as doing it in the c code internally in cgminer. So your devices are no longer getting any rest between work.

EDIT: This is precisely why stratum was developed by the way; in order to be able to keep much higher hashrate devices busy. If you want to test this theory, use version 2.8.3 and connect to the proxy in http mode by using --fix-protocol.

That is quite interesting, i must admit.
My GPUs are mostly at 99% load, i have the CCC open all the time, but must admit i don't look all the time.
Is it that the load drops sometimes for a short period and that makes the GPU cool or recover so it can look like lasting longer, and on stratum it is on 99% load 24h a day?

Also, i have a request:
Is it possible to show the fan percentage with the rpm's? I use CCC to monitor fan percentage, because that is my measure when and if  my computers need to be air condititoned.
As long as fan percentage is below my set max of 55% i declare them sufficient and do not reduce engine clock. (But on the other hand it seems i need to to have stratum work?)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481257404
Hero Member
*
Offline Offline

Posts: 1481257404

View Profile Personal Message (Offline)

Ignore
1481257404
Reply with quote  #2

1481257404
Report to moderator
1481257404
Hero Member
*
Offline Offline

Posts: 1481257404

View Profile Personal Message (Offline)

Ignore
1481257404
Reply with quote  #2

1481257404
Report to moderator
1481257404
Hero Member
*
Offline Offline

Posts: 1481257404

View Profile Personal Message (Offline)

Ignore
1481257404
Reply with quote  #2

1481257404
Report to moderator
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
October 14, 2012, 06:11:32 PM
 #7582

Just updated to 2.8.3.  I have to say I really don't like the new precision on numeric output:

Quote
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.
You might prefer BFGMiner's format:
Code:
BFL 0:  68.3C         | 877.2/868.3/865.6Mh/s | A:14233 R:164 HW:  28 U:12.09/m
BFL 1:  68.3C         | 1.477/1.468/1.465Gh/s | A:28533 R:164 HW:  28 U:24.18/m

Cgminer now displays the actual share difficulty target it hit as well as the current pool difficulty like so:
Code:
[2012-10-12 21:00:31] Accepted 2687d42a Diff 6/3 GPU 1 pool 2
 [2012-10-12 21:00:41] Accepted 00f98044 Diff 262/3 GPU 3 pool 2
 [2012-10-12 21:00:45] Accepted 3840818b Diff 4/3 GPU 2 pool 2
 [2012-10-12 21:00:55] Accepted 35777786 Diff 4/3 GPU 1 pool 2

I'm not understanding this.  Aren't these difficulty numbers multipliers of current difficulty?  How/why would a miner be working on a higher difficulty than the pool is requesting?
Miners are trying to find hashes that meet a minimum of the current difficulty. So if your hash only hit difficulty 1, it is not good enough for a difficulty 3 pool. If your hash hits the Bitcoin difficulty, you found a block.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 14, 2012, 09:27:50 PM
 #7583

This post is the most interesting and do you know why? The GPU code is UNCHANGED between 2.7.6 and 2.8.3. The only thing that is different is the stratum code. Now why would that make your GPUs SICK now when they didn't previously? Because with the stratum code, the device is busier than ever. There is no possible way to keep the device as busy as doing it in the c code internally in cgminer. So your devices are no longer getting any rest between work.

EDIT: This is precisely why stratum was developed by the way; in order to be able to keep much higher hashrate devices busy. If you want to test this theory, use version 2.8.3 and connect to the proxy in http mode by using --fix-protocol.

That is quite interesting, i must admit.
My GPUs are mostly at 99% load, i have the CCC open all the time, but must admit i don't look all the time.
Is it that the load drops sometimes for a short period and that makes the GPU cool or recover so it can look like lasting longer, and on stratum it is on 99% load 24h a day?

Also, i have a request:
Is it possible to show the fan percentage with the rpm's? I use CCC to monitor fan percentage, because that is my measure when and if  my computers need to be air condititoned.
As long as fan percentage is below my set max of 55% i declare them sufficient and do not reduce engine clock. (But on the other hand it seems i need to to have stratum work?)
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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 14, 2012, 10:41:32 PM
 #7584

I was running cgminer 2.5.0 till today, as the latest versions had a performance hit on my 5850's (win x64, SDK 2.5 on Cat 12.1), since the last phatk update (~400MH/s to ~320MH/s).

Since I had some free time today I went to check what had changed from phatk120223 to phatk120823 and found what was causing me that performance hit. Commenting the problematic lines fixed it:

Code:
//#if defined(OCL1)
#define SETFOUND(Xnonce) output[output[FOUND]++] = Xnonce
//#else
// #define SETFOUND(Xnonce) output[atomic_add(&output[FOUND], 1)] = Xnonce
//#endif

I still find it strange how the atomic_add could be responsible for that much of a mhash hit, since it will only be called on found nonces. Tongue

(Running 2.8.3 now, will keep monitoring performance for any issues)
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).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
ice_chill
Sr. Member
****
Offline Offline

Activity: 336


View Profile
October 14, 2012, 10:54:16 PM
 #7585

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.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 14, 2012, 10:57:02 PM
 #7586

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 14, 2012, 11:27:40 PM
 #7587

Just updated to 2.8.3.  I have to say I really don't like the new precision on numeric output:

Quote
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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jasinlee
Hero Member
*****
Offline Offline

Activity: 742


Its as easy as 0, 1, 1, 2, 3


View Profile
October 14, 2012, 11:30:33 PM
 #7588

Current code

Code:
./cgminer --scrypt -o http://ltc.kattare.com:9332 -u jasinlee.1 -p 1 -g 1 --thread-concurrency 8000 -I 18 -w 256 --auto-fan


I Assume this probably has to do something with it.

Code:
[2012-10-14 21:35:49] Failed to init GPU thread 0, disabling device 0
 [2012-10-14 21:35:49] Restarting the GPU from the menu will not fix this.
 [2012-10-14 21:35:49] Try restarting cgminer.
Press enter to continue:

 [2012-10-14 21:36:09] Your scrypt settings come to 524288000
 [2012-10-14 21:36:09] Error -61: clCreateBuffer (padbuffer8), decrease CT or i
ncrease LG
 [2012-10-14 21:36:09] Failed to init GPU thread 7, disabling device 7

Oh,

use --thread-concurrency 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.

BTC 1JASiNZxmAN1WBS4dmGEDoPpzN3GV7dnjX DVC 1CxxZzqcy7YEVXfCn5KvgRxjeWvPpniK3                     Earn Devcoins Devtome.com
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 15, 2012, 12:16:51 AM
 #7589

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);
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


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

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 15, 2012, 03:46:37 AM
 #7591

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
Code:
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 BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Lem
Member
**
Offline Offline

Activity: 78


View Profile
October 15, 2012, 07:10:04 AM
 #7592

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:
Code:
"url" : "http://api.bitcoin.cz:8332"
so I leave it to cgminer to recognize ad activate the stratum protocol, which it does:
Code:
Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://api-stratum.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:
Code:
[2012-10-15 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding!
[2012-10-15 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
Hero Member
*****
Offline Offline

Activity: 591



View Profile WWW
October 15, 2012, 07:24:47 AM
 #7593

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:
Code:
"url" : "http://api.bitcoin.cz:8332"
so I leave it to cgminer to recognize ad activate the stratum protocol, which it does:
Code:
Switching pool 7 http://api.bitcoin.cz:8332 to stratum+tcp://api-stratum.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:
Code:
[2012-10-15 01:31:50] Pool 7 http://api.bitcoin.cz:8332 not responding!
[2012-10-15 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. Tongue

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 15, 2012, 09:51:45 AM
 #7594

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

Thanks for the detailed explanation! Wink

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. Grin

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

Btw, since I haven't yet, 1btc donation sent! Smiley I can only imagine the number of hours you spent writing and optimizing cgminer's code!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 15, 2012, 10:35:17 AM
 #7595

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
amigaman
Sr. Member
****
Offline Offline

Activity: 406



View Profile
October 15, 2012, 10:50:34 AM
 #7596

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
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 15, 2012, 01:36:50 PM
 #7597

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 Smiley

Still, the odds for concurrency are very very low. Smiley

A nonce find can be modeled by a Poisson distribution with lambda=1/(2^32).
Code:
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.7105e-11 = ~.0000000027%
Lem
Member
**
Offline Offline

Activity: 78


View Profile
October 15, 2012, 02:52:16 PM
 #7598

Still, the odds for concurrency are very very low. Smiley

A nonce find can be modeled by a Poisson distribution with lambda=1/(2^32).
Code:
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.7105e-11 = ~.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? Shocked

And what do you mean with:
Quote
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. Smiley

--
Bye
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 15, 2012, 03:48:01 PM
 #7599

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? Shocked

And what do you mean with:
Quote
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. Smiley

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 32-bit 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
Member
**
Offline Offline

Activity: 78


View Profile
October 15, 2012, 05:31:14 PM
 #7600

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
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 ... 830 »
  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!