OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0

[juhakall]

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.

[1505835598]

1505835598

[1505835598]

1505835598

[1505835598]

1505835598

[PatMan]

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

[sharky112065]

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

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.

[rav3n_pl]

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

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 lots faster, no double-configure

[Luke-Jr]

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]

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]

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.

[kano]

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

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 lots faster, no double-configure

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

[kano]

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

[-ck]

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

Does it actually fix anything?

[Askit2]

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.

Seems like a solution in search of a problem.

[kano]

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

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

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.

[Luke-Jr]

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.

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]

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.

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
There is nothing to clean up except your retarded brain not being able to understand the simple original code I wrote.

[Luke-Jr]

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.

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]

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

[dlasher]

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?

[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]

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?

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

[sharky112065]

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?

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

[dlasher]

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