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

Activity: 1358


View Profile
November 27, 2012, 10:56:25 AM
 #8261

Just adding my 0.0016 BTC worth here..

Since p2pool has gone berserk, I have half my miners pointing at EMC, and half at Oz.

Oz is using stratum.
EMC is using GBT.

After about 12 hours, there were noticeably more rejects on EMC than on Oz.  That's with using GBT, not stratum, on Oz.

Not sure if it means anything.

M

To give some numbers.  After about 10 hours of mining, 2 identical rigs (3x7970 ~ 2GH/s):

oz:
Code:
cgminer version 2.9.5 - Started: [2012-11-26 19:03:48]
--------------------------------------------------------------------------------
 (5s):2.002G (avg):1.997Gh/s | Q:1398  A:18114  R:14  HW:0  E:1296%  U:28.0/m
 TQ: 7  ST: 0  SS: 0  DW: 2574  NB: 75  LW: 20980  GF: 0  RF: 0  WU: 28.0
 Connected to stratum.ozco.in with stratum as user
 Block: 048858edfdf0a45c5fe39cb2...  Started: [05:49:39]  Best share: 8.65K
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2787RPM | 666.9M/667.3Mh/s | A:6035 R:4 HW:0 U: 9.32/m I: 9
 GPU 1:  73.0C 2908RPM | 666.6M/667.5Mh/s | A:6040 R:5 HW:0 U: 9.32/m I: 9
 GPU 2:  73.0C 3197RPM | 662.3M/662.7Mh/s | A:6041 R:5 HW:0 U: 9.33/m I: 9
--------------------------------------------------------------------------------

eclipse:
Code:
cgminer version 2.9.5 - Started: [2012-11-26 19:04:25]
--------------------------------------------------------------------------------
 (5s):1.958G (avg):1.956Gh/s | Q:1782  A:13009  R:53  HW:0  E:730%  U:20.1/m
 TQ: 0  ST: 11  SS: 0  DW: 3946  NB: 75  LW: 21963  GF: 0  RF: 0  WU: 27.5
 Connected to us1.eclipsemc.com with GBT as user
 Block: 048858edfdf0a45c5fe39cb2...  Started: [05:49:41]  Best share: 572K
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2789RPM | 653.0M/655.3Mh/s | A:4348 R:21 HW:0 U:  6.71/m I: 9
 GPU 1:  73.0C 2606RPM | 654.5M/654.4Mh/s | A:4320 R:10 HW:0 U:  6.67/m I: 9
 GPU 2:  73.0C 2406RPM | 645.0M/646.7Mh/s | A:4341 R:22 HW:0 U:  6.70/m I: 9
--------------------------------------------------------------------------------

That's 0.07% rejects on Oz and 0.4% on Eclipse.  Note that's fewer blocks submitted on eclipse because it is serving me somewhere between 1 and 2 difficulty shares, whereas Oz is 1 (even though I have it on var diff, 2gh must not be enough for auto to raise it).

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481445126
Hero Member
*
Offline Offline

Posts: 1481445126

View Profile Personal Message (Offline)

Ignore
1481445126
Reply with quote  #2

1481445126
Report to moderator
1481445126
Hero Member
*
Offline Offline

Posts: 1481445126

View Profile Personal Message (Offline)

Ignore
1481445126
Reply with quote  #2

1481445126
Report to moderator
hahahafr
Sr. Member
****
Offline Offline

Activity: 241



View Profile
November 27, 2012, 11:21:51 AM
 #8262

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink
Don't go further. This is the issue.
I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue
... only until the current stratum problem is resolved and we move on to 'discussing' the reconnect issue and fixing that Smiley

I've read a certain number of posts from Kano speaking of these problems with Stratum now. If I believe Kano, it looks like the solution are somewhat trivial to implement, by just modifying the specifications we would be good to go. In 2 months from now on, Stratum will be the de facto standard protocol (because GBT has too much stales), now is a good time to correct forgotten cases/issues by Slush, not in 2 months.  Undecided

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 27, 2012, 11:32:38 AM
 #8263

now is a good time to correct forgotten cases/issues by Slush, not in 2 months.  Undecided

Actually I was thinking about reconnection pretty well, unfortunately I didn't find any proper solution yet. Resuming mining on another TCP connection goes against the KISS of Stratum and it requires advanced methods of load balancing.

That say, when you open two connections to my pool, you will most likely talk to completely different backends. Synchronizing them online so the second one will be able to accept and validate shares generated from another connection is really non-trivial issue...

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
November 27, 2012, 11:57:18 AM
 #8264

Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 232 nonce limit.

True. But there is a limit to ntime. If a pool were to hash a stratum job ad nauseam and finally solve it, and then submit it, it would be rejected based on ntime (being some large time into the future). Stratum doesn't roll ntime and thus depends on the pool pushing new work requests.
Well, if you can't roll ntime (sounds like a major flaw to me), you'd just keep using the same one until you found the block. So if anything, it'd be too old. But Bitcoin itself doesn't care what ntime is as long as it is greater than or equal to the median of the last 10 blocks - in other words, the ntime the pool gives you the first time for each new block remains valid.

Perhaps slush could clarify the current meaning
I don't understand what is unclear here.

a) clean_jobs=False means that previous jobs are still valid.
b) clean_jobs=True means that previous jobs become invalid.
c) If new work is received, miner automatically should use this job. There's no reason why to add a new flag to specify this, it is "by default". However miners can do whatever they want, because with or without a special flag, previous jobs are still valid.

KISS, please.
Ok, so that seems to agree with conman's interpretation somewhat. How do pools say "previous job remain valid for N more seconds"? It's unreasonable to expect pools to accept shares on previous jobs indefinitely, and also harmful to miners to discard shares across the change-over period. In short, there seems to be no possible way to implement the 2 minute expiration over stratum...

How do pools say "previous jobs shouldn't be used, but please submit them anyway"? This was an important fix added to getwork longpolling to correct pool-side statistics as well as avoid losing merged mining shares in some cases.

I've read a certain number of posts from Kano speaking of these problems with Stratum now.
Kano's problem is just one of many...
If I believe Kano,
Sounds like a pretty bad idea.
(because GBT has too much stales)
This is either a myth or a cgminer bug.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 27, 2012, 12:04:40 PM
 #8265

Ya my first several shares are usually rejects. I am mining over wifi, with about a dozen+ other computers on the network, so DCs are a fact of life. Still, I can live with 0.3% for now. Wink
Don't go further. This is the issue.
I'm not complaining. I know it's a problem, but one I sorta have to live with. Tongue
... only until the current stratum problem is resolved and we move on to 'discussing' the reconnect issue and fixing that Smiley

I've read a certain number of posts from Kano speaking of these problems with Stratum now. If I believe Kano, it looks like the solution are somewhat trivial to implement, by just modifying the specifications we would be good to go. In 2 months from now on, Stratum will be the de facto standard protocol (because GBT has too much stales), now is a good time to correct forgotten cases/issues by Slush, not in 2 months.  Undecided
I've considered (and mentioned to one) a way to solve this Smiley
Ask a pool to implement it fixed so they can call it something else (since it isn't what slush wants he has no claim over it) and then all the other pools can see it's better and switch over to it.
If it goes on for much longer I'll try to push this.

LOL at above post, he's getting lonely with his GBT and BarbieMiner that's people are slowly realising what's wrong with it and no one wants Smiley

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
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 27, 2012, 12:55:27 PM
 #8266

How do pools say "previous job remain valid for N more seconds"?

Is there any use case for this feature? Except pools which "pay for stales" (=pay bad miners on behalf good ones).

Quote
This was an important fix added to getwork longpolling

Is there any pool actually using it? As we're primary talking about bitcoin mining, there's no economic motivation to work with stale shares on pool side...

Quote
avoid losing merged mining shares in some cases.

Well, this is valid point. We can discuss if losing less than 0.1% of merged mining shares is worth of complicating the mining protocol. I'm personally strictly for "keep it simple" and minimalistic design, otherwise implementations became monsters full of checking edge cases. Actually there's only one condition in whole Stratum protocol, and it is (I think necessary) "clean_jobs" flag.  The rest is plain simple algorithm without exceptions.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
November 27, 2012, 12:58:03 PM
 #8267

How do pools say "previous job remain valid for N more seconds"?
Is there any use case for this feature? Except pools which "pay for stales" (=pay bad miners on behalf good ones).
Um, yes? So you don't need to keep around old jobs indefinitely...

Quote
This was an important fix added to getwork longpolling
Is there any pool actually using it? As we're primary talking about bitcoin mining, there's no motivation to work with stale shares on pool side...
Motivation: Don't lie to miners about their stale rate.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
November 27, 2012, 01:10:49 PM
 #8268

Looks like there's discrepancy between your and mine expectations about the ideal protocol. I've been focused to minimalistic design, and the lack of any extended features is benefit for me. I'm open to designing some (optional) calls like "report me your stale ratio", which will do the same job, it allows handy graphics on pool website, but it doesn't make the protocol core more complicated.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
November 27, 2012, 01:42:42 PM
 #8269

With the clarifications from slush, I've fixed 2 bugs in eloipool's stratum server:
  • clean_jobs is now sent true when previous jobs are immediately invalid
  • idle job updates occur every 55 seconds instead of 96 (stratum expects a 60 second grace window on old jobs)

This should get things working in the new block case of cgminer, but the fact that cgminer was still working on an old job after 24 seconds (at 800+ Mh/s) means it isn't switching to the new job when giving devices more work right away, so there's still a (cgminer) bug there (althrough the reduced 55 second update period will likely avoid that being as common).

Note that these changes won't affect EMC until Inaba updates it there.

optimator
Sr. Member
****
Offline Offline

Activity: 351



View Profile WWW
November 27, 2012, 05:40:26 PM
 #8270

Well, if you can't roll ntime (sounds like a major flaw to me)

Not a flaw - just not needed.

girafon
Member
**
Offline Offline

Activity: 60


View Profile
November 27, 2012, 07:34:26 PM
 #8271

Not sure this is intended or not : using cgminer 2.9.5 under windows7 (64), downloaded from http://ck.kolivas.org/apps/cgminer/cgminer-2.9.5-win32.7z while connected to a GBT-enabled pool, the "Q" value reported by cgminer stays at "3" and won't change, even after hours of running.

This gives giant efficiency values (which may alter the various load-balance algorithms ?)

Part of my conf file:
Code:
"failover-only" : true,
"submit-stale" : false,

"intensity" : "d",
"gpu-threads" : "1",
"gpu-dyninterval" : "7",

"expiry" : "110",
"scan-time" : "60",

"log" : "1",
"queue" : "1",


EDIT : downgrading to 2.9.4 fixes that "issue" ; "Q" indicator increases again.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
November 27, 2012, 10:26:42 PM
 #8272

All servers are updated on EMC.  I'll be curious to see how it works.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 27, 2012, 11:08:38 PM
 #8273

All servers are updated on EMC.  I'll be curious to see how it works.
Great!

Trying it out now on stratum. Will report back.
Half hour of mining with 2.7GH:

 Accepted shares: 723
 Rejected shares: 1

I watched diff go from .99 to 2 and fluctuate frequently during that time and a handful of block changes went by as well.

I happened to see the rejected share as well, and it was a diff 1/2 high hash reject.
This means diff had risen, and cgminer knew about the rise, but being conservative as per a scenario A described here: https://bitcointalk.org/index.php?topic=28402.msg1357099#msg1357099 cgminer still submitted it.

All in all, great stuff. I'm glad to see this issue sorted out for both the pool and the miners.

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

Activity: 1260



View Profile WWW
November 27, 2012, 11:11:18 PM
 #8274

US2 is having some trouble, I'm looking into it now.  US3 and US1 are fine though, it's kind of strange.  Definitely good to see things get sorted out.

Quote
This should get things working in the new block case of cgminer, but the fact that cgminer was still working on an old job after 24 seconds (at 800+ Mh/s) means it isn't switching to the new job when giving devices more work right away, so there's still a (cgminer) bug there (althrough the reduced 55 second update period will likely avoid that being as common).

Can you comment on that by chance?

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Askit2
Hero Member
*****
Offline Offline

Activity: 524


View Profile
November 28, 2012, 12:40:59 AM
 #8275

US2 is having some trouble, I'm looking into it now.  US3 and US1 are fine though, it's kind of strange.  Definitely good to see things get sorted out.

Quote
This should get things working in the new block case of cgminer, but the fact that cgminer was still working on an old job after 24 seconds (at 800+ Mh/s) means it isn't switching to the new job when giving devices more work right away, so there's still a (cgminer) bug there (althrough the reduced 55 second update period will likely avoid that being as common).

Can you comment on that by chance?

Dropping scantime to 80 and expiry to 100 seconds did not fix it on Stratum. Since I should have a 120 second window to submit shares and the oldest shares I could be trying to submit (short of an unintended bug) are 100 seconds old I see no way to actually have run afoul of this reject overnight. My stales seemed just as high this morning and I noted some of the same invalid work type stales as I previously named. The rate despite only working on a work unit for (it appears) the higher of server or scan time and expiry set low should have fixed it if the issue was cgminer. Well unless somehow I was actually getting work results far in excess of the time alloted but even there I would have 2-3 results that met difficulty and 1 would be rejected sometimes the last sometimes the first usually the middle. Timing is either because its an old submission (expiry should have dropped it) or its being
rejected out of hand.

With the upgrade (on Eclipse) I am restarting cgminer to get my stats in line with only the new setup.

EDIT: added On Stratum to 1st sentance for clarity.

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 28, 2012, 12:53:27 AM
 #8276

Was this with getwork, gbt or stratum? One thing about share submission for non-stratum on cgminer - it will keep retrying to submit if for some reason the submission failed (server responded with empty reply, busy etc.) until it has deemed there is no chance it is still valid. It retries sending every 5 seconds. Perhaps that is what's going on here? cgminer certainly does throw out all work on a longpoll equivalent, and checks if it should on every "cycle" through the work in GPUs at least.

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

Activity: 241



View Profile
November 28, 2012, 07:06:05 AM
 #8277

Where does the name 'cgminer' come from? Are you French ckolivas?

Askit2
Hero Member
*****
Offline Offline

Activity: 524


View Profile
November 28, 2012, 07:16:34 AM
 #8278

I am using eclipses stratum on US1.
3849 accepted so far
2 rejected.
Compared to 2 days of 1.2% I am very happy with the improvement.

CPU Miner was abandoned and Con made Cpu Gpu Miner

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
November 28, 2012, 11:48:17 AM
 #8279

In case anyone wants me to try something else...
Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.
I'm getting "No stack."  I assume that makes it obvious I've never done this before...

ETA:
Code:
cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g
Also, FYI, this is the exact error I was getting in 2.9.4 on GBT only:
Code:
Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing
latest version, x86_64 linux, build with -02 -Wall
I'm not sure whether the fact that it is also happening on that other miner will make you laugh or cry...
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 28, 2012, 12:23:47 PM
 #8280

In case anyone wants me to try something else...
Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.
I'm getting "No stack."  I assume that makes it obvious I've never done this before...

ETA:
Code:
cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g
Also, FYI, this is the exact error I was getting in 2.9.4 on GBT only:
Code:
Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing
latest version, x86_64 linux, build with -02 -Wall
I'm not sure whether the fact that it is also happening on that other miner will make you laugh or cry...
Well that's my code so it's no surprise...

Please add --no-restart
That way it will not try to restart if it crashes, which is stopping it from dumping properly. Thanks.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 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 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 ... 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!