Bitcoin Forum
December 11, 2016, 08:31:20 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 431 432 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4827990 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.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 16, 2012, 07:53:20 AM
 #7621

Code:
[2012-10-16 00:26:14] Creating extra submit work thread
 [2012-10-16 00:26:14] Submitting share fdb15728 to pool 0

that is the last output from debugging after the miners dieded last night.
The machines with miner 2.8.3 - win32 and started with --fix-protocol didn't die.
so it seems it has todo with stratum and win32.

Thanks! That at least helps me as to where I can look for potential bugs. I'm quite sure it's stratum related.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481445080
Hero Member
*
Offline Offline

Posts: 1481445080

View Profile Personal Message (Offline)

Ignore
1481445080
Reply with quote  #2

1481445080
Report to moderator
1481445080
Hero Member
*
Offline Offline

Posts: 1481445080

View Profile Personal Message (Offline)

Ignore
1481445080
Reply with quote  #2

1481445080
Report to moderator
Lem
Member
**
Offline Offline

Activity: 78


View Profile
October 16, 2012, 09:00:20 AM
 #7622

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

I think that, thanks to your patience, now I see how you approached the problem. Smiley

I wouldn't say "at the same time": Poisson distribution tells you the probability that an event happens N times in a fixed time interval (or in a fixed space interval) when you know that the mean in that period is lambda. So with Poisson you have first to choose an interval, and then go on. It can be as short as a... wavefront, or the clock of your hardware, I don't know how to say it well. You chose a hash computation time as the interval, of course.

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

Oh, ok! I'm sorry to say that I don't know how hardware and software work, so please forgive me for my past assumptions. :-p

The problem is: "every n clocks, we don't care about n, we have our bunch of exactly X simultaneous hashes, all toghether in a wavefront, given by our X concurrent threads (I hope that "threads" is the right word here). Each thread gives us one and only one hash. Since we know that the probability for a hash to be a nonce is 1/2^32, how many Y nonces (with 0<=Y<=X) are we likely to find in a bunch?"

Well, then Poisson is not the most proper distribution for us: it isn't meant to describe this situation.
AFAIK Poisson is thought to calculate the probability of a number of sequential events in a fixed interval. You are using it to calculate the probability of simultaneous events in... no interval. Smiley
Using Poisson completely confused me, and led me to guess a different situation and a different problem. I'm sorry for that.

Of course Binomial is the proper distribution, but you're completely right writing that Poisson gives a very good approximation, as you showed, setting lambda = X/(2^32). So Poisson is numerically right, too, for our case.

I think I got your point, now. Thanks again. Smiley

--
Bye
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 16, 2012, 10:22:32 AM
 #7623

Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.
I've created a (unnecessarily complex) workaround and committed it to git so it's always padded on the right by zeroes. I agree it looks better.

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

Activity: 700



View Profile
October 16, 2012, 10:36:26 AM
 #7624

There seems to be a severe bug with 2.8.3 and ztex FPGAs.

I was running my ztex on 2.8.3 a few times always with the same result. After a random amount of time (ranging from 10min to 10hrs for me) the ztex only produces "hardware errors" and my gpu is only running at 100% with no shares produced (or send to the pool?). Also CPU goes up to 100% basically leaving my system unresponsive until cgminer is stopped hard.

Using
2.8.3 on Windows7 x64
GPU: ATI6850
ztex 1.15x
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
October 16, 2012, 10:52:00 AM
 #7625

There seems to be a severe bug with 2.8.3 and ztex FPGAs.

I was running my ztex on 2.8.3 a few times always with the same result. After a random amount of time (ranging from 10min to 10hrs for me) the ztex only produces "hardware errors" and my gpu is only running at 100% with no shares produced (or send to the pool?). Also CPU goes up to 100% basically leaving my system unresponsive until cgminer is stopped hard.

Using
2.8.3 on Windows7 x64
GPU: ATI6850
ztex 1.15x

Maybe "cure" will be compile "GPU-only" and "FPGA-only" versions? And run 2 programs?

Edit: compiled GPU-only+scrypt 2.8.3-15
http://sdrv.ms/NtmDt5
if someone want to try it Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 16, 2012, 10:57:01 AM
 #7626

I think I got your point, now. Thanks again. Smiley

You're welcome, it's always nice to have someone for debate! Grin
Vbs
Hero Member
*****
Offline Offline

Activity: 504


View Profile
October 16, 2012, 11:56:51 AM
 #7627

Nice, but it doesn't actually achieve any demonstrable performance advantage.
You know something? You are quite right! We can write off all of this saga with a "human tries to beat compiler again"! Grin

Out of curiosity, I went to dig deeper on how AMD would do branch prediction (it doesn't), but it does branch predication for branches with few ops!
Basically, the instructions inside the if branches are only executed based on a comparison result (they are not done in paralell), each op inside gets a true/false predicate flag for execution. So the most efficient code for this part is simply removing the main "if" (using the phatk v2 example):
Code:
#elif defined VECTORS2
    if (!W[117].x)
        SETFOUND(W[3].x);
    if (!W[117].y)
        SETFOUND(W[3].y);

Each of the if(!...) starts with something as:
1351  x: PREDE_INT   ____,  R0.x,  0.0f      UPDATE_EXEC_MASK UPDATE_PRED
for updating the predicate flag

This means that if no nonce is found, the most common path, the penalty is only the execution of two PREDE_INT ops, with zero misfires for false positives (min path has the same exec time as with bitmasking). This also allows for simultaneous nonces in both vectors and allows for the nonce itself to be all zeros. Check the GPU ISA code, the execution path is clearer there! Smiley
Nachtwind
Hero Member
*****
Offline Offline

Activity: 700



View Profile
October 16, 2012, 12:13:12 PM
 #7628

Maybe "cure" will be compile "GPU-only" and "FPGA-only" versions? And run 2 programs?

Thats what i try to accomplish not to have: I would love to have my miners in one single program.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 16, 2012, 12:15:14 PM
 #7629

Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.

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

Activity: 1320


Don`t panic! Organize!


View Profile
October 16, 2012, 12:58:28 PM
 #7630

Maybe "cure" will be compile "GPU-only" and "FPGA-only" versions? And run 2 programs?

Thats what i try to accomplish not to have: I would love to have my miners in one single program.
Tried that for GPU+CPU but looks like CPU alone is 3x faster than combo Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Nachtwind
Hero Member
*****
Offline Offline

Activity: 700



View Profile
October 16, 2012, 01:07:57 PM
 #7631

Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.

meh...
But ok, at least i know where i am standing. Thanks.
ralree
Hero Member
*****
Offline Offline

Activity: 518


Manateeeeeeees


View Profile
October 16, 2012, 02:15:18 PM
 #7632

Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.

HA!  OK, OK fine.  I guess that's somewhat reasonable.

1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
ralree
Hero Member
*****
Offline Offline

Activity: 518


Manateeeeeeees


View Profile
October 16, 2012, 02:17:52 PM
 #7633

Yes but that would make my 2.722 Gh only appear as 2.7GH which is not accurate enough. Significant digits is the key.
I've created a (unnecessarily complex) workaround and committed it to git so it's always padded on the right by zeroes. I agree it looks better.

Thank you very much for this.  You are awesome.

1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
Nite69
Hero Member
*****
Offline Offline

Activity: 477


View Profile
October 16, 2012, 02:31:53 PM
 #7634

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

But if it is not, could there be some law behind it which could maybe used to make somehow better digging algorihtm? Currently just guessing, but maybe..

first; hash function is designed so that changing one bit in the input would change as many bits on the output as possible. However, all of the outputbits cannot (ans should not) be changed.

Could it be so that certain parts of the input makes it more possibly that the upper bits of the output is zero when nonce is changed? For example the block hash compined with certain timestamp (or part of it) could cause more hashes with zeroes on the up?

If so, the algorihtm could be changed so that if good hashes are not found, the miner should try to somehow change the input (in addition to nonce). If 'quite good' hashes has been found, it should keep the block as stable as possible, maybe not accept new transactions or try not to change the timestamp or change it as little as possible?

Just guessing, but maybe worth trying? Maybe this theory (or hypothesis or guessing..) could be checked by some statistic from simulated block headers? Certain bits in the simulated headers could be found to generate more hashes with zeroes up?

hmm. maybe this should be on the pool sw, not mining software.

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
October 16, 2012, 02:46:49 PM
 #7635

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?
(...)
Double SHA256 excludes this IMO, one bit on input makes output totally different, and for 2 totally different inputs it is almost impossible get similar outputs...
Some match formula like that would be "easy" SHA256 break/collision maker.
So far noone found collision in this algo Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
October 16, 2012, 02:57:35 PM
 #7636

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
October 16, 2012, 04:09:28 PM
 #7637

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

It's actually just your brain's natural pattern recognition.  When looking at huge sets of data, you will subconsciously try to pick out groups that stick out from the rest.  Statistically speaking, large sets of random numbers will have lots of groups close together, and lots of large gaps.  If you average it all out, you'll have very consistent "randomness".  It's just that the human brain is efficient at trying to find patterns/meaning in things that can be grouped together.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Nite69
Hero Member
*****
Offline Offline

Activity: 477


View Profile
October 16, 2012, 04:23:40 PM
 #7638

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?

You answered it by youself. It is just your imagination.

Yes, that's the most likely explanation :-) But worth mentioning, anyway (I think?). Suppose this pops up every now and then?

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 16, 2012, 05:07:22 PM
 #7639

I have noticed that usually the successfull hit's (found hashes) seems to be in pairs or groups. Maybe it is just my imagination?
...
No the statistical expectation is on average one 1diff share per 2^32 hashes.

To see this, try mining on an Icarus device.
The Icarus device aborts after it finds a share - thus usually doesn't complete the full 2^32 hashes
Yet ... they still get expected performance.

However ... if you mine with a BFL Single then you will certainly see groups of shares.
Sometimes as many as 5 or 6 (and of course possible to find more)
The BFL design is such that it returns 'all' shares found in the nonce range after it completes the nonce range (and not before)
So it is common to see groups of shares turning up when using a BFL Single.

Edit: the discussion of the expected probability of finding a share, when not completing the full nonce range, has popped up before ...

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
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
October 16, 2012, 05:31:12 PM
 #7640

Alas the ztex code is in complete bitrot. The only code maintainer for it (nelisky) has long since disappeared and made no attempt to come back and maintain or bugfix it. So you're screwed.
I am maintaining the Ztex driver in BFGMiner.

Pages: « 1 ... 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 431 432 ... 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!