Bitcoin Forum
November 18, 2017, 11:55:40 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 ... 841 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5650526 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.
juhakall
Sr. Member
****
Offline Offline

Activity: 406



View Profile
December 19, 2012, 03:43:47 PM
 #8561

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511049340
Hero Member
*
Offline Offline

Posts: 1511049340

View Profile Personal Message (Offline)

Ignore
1511049340
Reply with quote  #2

1511049340
Report to moderator
1511049340
Hero Member
*
Offline Offline

Posts: 1511049340

View Profile Personal Message (Offline)

Ignore
1511049340
Reply with quote  #2

1511049340
Report to moderator
1511049340
Hero Member
*
Offline Offline

Posts: 1511049340

View Profile Personal Message (Offline)

Ignore
1511049340
Reply with quote  #2

1511049340
Report to moderator
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
December 19, 2012, 03:46:05 PM
 #8562

I was time, when 64KB total ram+rom+video was enough to do great things. Now this is forgotten.
If I can make something smaller and still working - why not? Accesing to HDD is 1000x slower than ram, sometimes 1MB more space on pen or CD/DVD is need.
I made this bins for myself - I not need USB and/or FPGA and other stuff, just GPU.
There are alot of ppl that only mine and have no clue about compiling or setting up git or mingw on windows.
It is only up to them to use or not use my binaries. I`m putting then to skydrive to have them accesible from my other machine where I not have mingw.


That would be me, I'm one of those people....lol

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
sharky112065
Sr. Member
****
Offline Offline

Activity: 303



View Profile
December 19, 2012, 06:05:58 PM
 #8563

rav3n_pl ... FYI ... you only need 3 lines to build cgminer... and it's the same on mingw - you can specify everything before make on the single autogen line on mingw and linux, so your first 4 lines become a single command.
It was posted many times, that if I use git version I should always use ./autogen.sh b4 I do anything else.
And I found today that not running "make clean" can generate errors Smiley

I believe what he was saying is that if you use autogen.sh you do not need to run configure. You can put all the options after autogen.sh.

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
rav3n_pl
Legendary
*
Offline Offline

Activity: 1253


Don`t panic! Organize!


View Profile WWW
December 19, 2012, 07:09:44 PM
 #8564

rav3n_pl ... FYI ... you only need 3 lines to build cgminer... and it's the same on mingw - you can specify everything before make on the single autogen line on mingw and linux, so your first 4 lines become a single command.
It was posted many times, that if I use git version I should always use ./autogen.sh b4 I do anything else.
And I found today that not running "make clean" can generate errors Smiley

I believe what he was saying is that if you use autogen.sh you do not need to run configure. You can put all the options after autogen.sh.
Code:
CFLAGS="-O2 -msse2" ./autogen.sh --enable-scrypt --without-libudev
make clean
make
Thx Smiley lots faster, no double-configure Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
Luke-Jr
Legendary
*
Offline Offline

Activity: 2268



View Profile
December 19, 2012, 07:15:54 PM
 #8565

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d

The00Dustin
Hero Member
*****
Offline Offline

Activity: 616


View Profile
December 19, 2012, 07:59:15 PM
 #8566

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d
Quoting for con, just in case.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
December 19, 2012, 08:23:57 PM
 #8567

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Hmm ok. As an aside, best share does show rejected shares or even shares not submitted if they're below the target. The reason for this is that there is no way of knowing what your best share is when you're solo mining.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
December 19, 2012, 08:54:48 PM
 #8568

rav3n_pl ... FYI ... you only need 3 lines to build cgminer... and it's the same on mingw - you can specify everything before make on the single autogen line on mingw and linux, so your first 4 lines become a single command.
It was posted many times, that if I use git version I should always use ./autogen.sh b4 I do anything else.
And I found today that not running "make clean" can generate errors Smiley

I believe what he was saying is that if you use autogen.sh you do not need to run configure. You can put all the options after autogen.sh.
Code:
CFLAGS="-O2 -msse2" ./autogen.sh --enable-scrypt --without-libudev
make clean
make
Thx Smiley lots faster, no double-configure Smiley
i.e. every time I post the linux link for 11.04 that's what I post at the end ... yeah the usual ... people don't read Tongue

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

Activity: 2268


Linux since 1997 RedHat 4


View Profile
December 19, 2012, 09:05:55 PM
 #8569

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d

Lulz - replacing my one function I wrote 15 months ago with 5 - and slower Tongue

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

Activity: 2338


Ruu \o/


View Profile WWW
December 19, 2012, 10:27:56 PM
 #8570

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d

Lulz - replacing my one function I wrote 15 months ago with 5 - and slower Tongue
Does it actually fix anything?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 609


Trust management on Blockchain


View Profile
December 19, 2012, 10:38:34 PM
 #8571

It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Cool

Seems like a solution in search of a problem.

kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
December 19, 2012, 11:02:52 PM
 #8572

After starting up 2.10.2 for the first time, I almost immediately got "Best share: 25", but no accepted shares for a while. Then I finally got an accepted share 4/4. Looks like the Best share display still isn't fixed, unless for some reason my target was above 25 (never been above 8 for me at BitMinter). Also, now Best share is at 207, even though all the accepted shares for this run are still on screen, and the highest is 55/4.
Fix for this is https://github.com/luke-jr/bfgminer/commit/bfab076d

Lulz - replacing my one function I wrote 15 months ago with 5 - and slower Tongue
Does it actually fix anything?
No Idea.
There's nothing wrong with the function he replaced.
If I had to guess without looking at the code I'd guess there is a static variable somewhere (or similar).
Working on the BFL->USB today, I'll have a look at this, after the code changes I'm doing are working Smiley

That change is: Showing 4 changed files with 72 additions and 83 deletions.
No doubt the fix will be something quite simple, not an attempted rewrite of anything Luke-Jr doesn't understand.

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

Activity: 2268



View Profile
December 20, 2012, 12:02:26 AM
 #8573

It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Cool

Seems like a solution in search of a problem.
Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations.

I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faac
This one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was.

kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
December 20, 2012, 01:44:03 AM
 #8574

It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Cool

Seems like a solution in search of a problem.
Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations.

I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faac
This one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was.
The function you replaced works fine and does exactly what I wrote it to do 15 months ago.
Check and see if it was a block based on the block header difficulty.
... though as I said, it's way faster that your replacement - which most likely is code you just copied out of elsewhere (and now say it's yours)

Oddly enough that's still required in cgminer - I guess the clone doesn't need that any more Tongue
There is nothing to clean up except your retarded brain not being able to understand the simple original code I wrote.

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

Activity: 2268



View Profile
December 20, 2012, 03:44:17 AM
 #8575

It fixes the shares looking high because the (I am guessing backup Bitcoin) target is far higher. I would rather see what the highest achieved was not the highest accepted was. Cool

Seems like a solution in search of a problem.
Both before and after intend to show the highest achieved. But the cgminer code calculated the hash twice, in two different ways, and the hash-to-difficulty code assumed it was one of those ways. When the share doesn't meet the pool target, the hash-to-difficulty code was run on it with its hash calculated the opposite way, and as a result gave the wrong result. My rewrite cleans up the code so it's actually readable, and makes the share->hash value always consistent with SHA256 and the share_diff function expectations.

I also wrote a much-less-changed fix for BFGMiner 2.8.x and 2.9.x: https://github.com/luke-jr/bfgminer/commit/006faac
This one doesn't clean up the code to make it more readable, though. But as a diff, it is easier to see what the problem was.
The function you replaced works fine and does exactly what I wrote it to do 15 months ago.
Trolling and lies ignored... the function you wrote (regeneratehash) indeed does work just fine. The problem is in fulltest, as is clear from the much-less-changed patch.

loshia
Legendary
*
Offline Offline

Activity: 1610


View Profile
December 20, 2012, 09:02:57 PM
 #8576

Kano,
There might be version mismatch between core and executable
I will post correct info when it crashes again
I am not quite sure if that info is useful at all
Flowing your advise i got some gdb core info to share. cgminer 2.10.2 coredumps
[91932.126721] cgminer[2138]: segfault at 260 ip 000000000040be10 sp 00007fff4c6b48b0 error 4 in cgminer[400000+57000]

[New LWP 2680]
[New LWP 2731]
[New LWP 2618]

warning: Error reading shared library list entry at 0x780000003c

warning: Corrupted shared library list: 0x0 != 0x4830408b48d00148
Core was generated by `/usr/local/bin/cgminer xxxxxx.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000410ea1 in stage_thread (userdata=0x1c4a080) at cgminer.c:3576
3576    cgminer.c: No such file or directory.


line 3576   tq_freeze(mythr->q);


10X

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
dlasher
Sr. Member
****
Offline Offline

Activity: 417



View Profile WWW
December 20, 2012, 10:06:26 PM
 #8577


Just upgraded from 2.9.7 to 2.10.2 (pulled from git, compiled myself), and I'm noticing VERY long startup times before mining begins when primary pool is down.. by very long, I'm talking 2-3 minutes. I don't recall it taking that long under previous versions.

Is there some new timeout value I might be missing, or need to set?


Quote
[2012-12-20 14:00:19] Started cgminer 2.10.2
 [2012-12-20 14:00:19] Probing for an alive pool
 [2012-12-20 14:02:49] Pool 0 slow/down or URL or credentials invalid
 [2012-12-20 14:02:49] Unable to get work from pool 0 http://btcguild.com:8332
 [2012-12-20 14:02:50] Switching pool 1 http://de.btcguild.com:8332 to stratum+tcp://176.9.42.247:3333

in this case, the URL changed for btcguild primary connection, once I fixed that, and the pool is 'reachable' it starts up immediately... invalid or down pool as pool #1 still gives almost 3 minutes delay on startup
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
December 20, 2012, 10:10:08 PM
 #8578


Just upgraded from 2.9.7 to 2.10.2 (pulled from git, compiled myself), and I'm noticing VERY long startup times before mining begins when primary pool is down.. by very long, I'm talking 2-3 minutes. I don't recall it taking that long under previous versions.

Is there some new timeout value I might be missing, or need to set?


Quote
[2012-12-20 14:00:19] Started cgminer 2.10.2
 [2012-12-20 14:00:19] Probing for an alive pool
 [2012-12-20 14:02:49] Pool 0 slow/down or URL or credentials invalid
 [2012-12-20 14:02:49] Unable to get work from pool 0 http://btcguild.com:8332
 [2012-12-20 14:02:50] Switching pool 1 http://de.btcguild.com:8332 to stratum+tcp://176.9.42.247:3333

in this case, the URL changed for btcguild primary connection, once I fixed that, and the pool is 'reachable' it starts up immediately... invalid or down pool as pool #1 still gives almost 3 minutes delay on startup

That's just the nature of how long the timeout needs to be on a raw socket to reasonably know it's dead with stratum. There is nothing you can manually change to alter that apart from not putting a dead pool first in line. This is not a new issue with 2.10.2, it's just that btcg is suffering a DDoS. If it were a getwork pool it could take up to 60 seconds. With stratum it's over 2 mins.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
sharky112065
Sr. Member
****
Offline Offline

Activity: 303



View Profile
December 20, 2012, 10:11:54 PM
 #8579


Just upgraded from 2.9.7 to 2.10.2 (pulled from git, compiled myself), and I'm noticing VERY long startup times before mining begins when primary pool is down.. by very long, I'm talking 2-3 minutes. I don't recall it taking that long under previous versions.

Is there some new timeout value I might be missing, or need to set?


Quote
[2012-12-20 14:00:19] Started cgminer 2.10.2
 [2012-12-20 14:00:19] Probing for an alive pool
 [2012-12-20 14:02:49] Pool 0 slow/down or URL or credentials invalid
 [2012-12-20 14:02:49] Unable to get work from pool 0 http://btcguild.com:8332
 [2012-12-20 14:02:50] Switching pool 1 http://de.btcguild.com:8332 to stratum+tcp://176.9.42.247:3333

in this case, the URL changed for btcguild primary connection, once I fixed that, and the pool is 'reachable' it starts up immediately... invalid or down pool as pool #1 still gives almost 3 minutes delay on startup


I think they were under DDOS. Maybe that has something to do with it, as in btcguild was not completely down.

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
dlasher
Sr. Member
****
Offline Offline

Activity: 417



View Profile WWW
December 20, 2012, 10:22:27 PM
 #8580

...... If it were a getwork pool it could take up to 60 seconds. With stratum it's over 2 mins.

Perfect, that's what I'm seeing. Appreciate the response.

Pages: « 1 ... 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 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 ... 841 »
  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!