juhakall
|
 |
December 19, 2012, 03:43:47 PM |
|
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.
|
|
|
|
|
|
|
"Apparently, so I am told, there exist "people" who prefer to wipe sitting down. From the front. Initial research indicates it could be up to half the population." -- benjamindees
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
|
|
|
|
PatMan
|
 |
December 19, 2012, 03:46:05 PM |
|
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
|
 |
December 19, 2012, 06:05:58 PM |
|
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.
|
Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1359
Merit: 1000
Don`t panic! Organize!
|
 |
December 19, 2012, 07:09:44 PM |
|
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. CFLAGS="-O2 -msse2" ./autogen.sh --enable-scrypt --without-libudev make clean make
Thx  lots faster, no double-configure 
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
December 19, 2012, 07:15:54 PM |
|
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
|
 |
December 19, 2012, 07:59:15 PM |
|
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/bfab076dQuoting for con, just in case.
|
|
|
|
-ck
Moderator
Legendary
Offline
Activity: 2492
Merit: 1047
Ruu \o/
|
 |
December 19, 2012, 08:23:57 PM |
|
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
Legendary
Offline
Activity: 2422
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 19, 2012, 08:54:48 PM |
|
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. 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 
|
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!
|
|
|
kano
Legendary
Offline
Activity: 2422
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 19, 2012, 09:05:55 PM |
|
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/bfab076dLulz - replacing my one function I wrote 15 months ago with 5 - and slower 
|
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!
|
|
|
-ck
Moderator
Legendary
Offline
Activity: 2492
Merit: 1047
Ruu \o/
|
 |
December 19, 2012, 10:27:56 PM |
|
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/bfab076dLulz - replacing my one function I wrote 15 months ago with 5 - and slower  Does it actually fix anything?
|
|
|
|
Askit2
|
 |
December 19, 2012, 10:38:34 PM |
|
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
Legendary
Offline
Activity: 2422
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 19, 2012, 11:02:52 PM |
|
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/bfab076dLulz - 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.
|
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!
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
December 20, 2012, 12:02:26 AM |
|
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/006faacThis 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
Activity: 2422
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 20, 2012, 01:44:03 AM |
|
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/006faacThis 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.
|
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!
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
December 20, 2012, 03:44:17 AM |
|
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/006faacThis 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
Activity: 1610
Merit: 1000
|
 |
December 20, 2012, 09:02:57 PM |
|
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
|
 |
December 20, 2012, 10:06:26 PM |
|
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
Moderator
Legendary
Offline
Activity: 2492
Merit: 1047
Ruu \o/
|
 |
December 20, 2012, 10:10:08 PM |
|
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
|
 |
December 20, 2012, 10:11:54 PM |
|
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.
|
Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
|
|
|
dlasher
|
 |
December 20, 2012, 10:22:27 PM |
|
...... 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.
|
|
|
|
|