Bitcoin Forum
February 21, 2019, 05:09:35 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 433 434 435 436 437 438 ... 844 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5776735 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. (2 posts by 2 users deleted.)
chewie
Member
**
Offline Offline

Activity: 75
Merit: 10


View Profile
October 28, 2012, 09:33:13 PM
 #7741

As a side note, I also have been getting a lot of BFL0 Comms Error or garbled message lately.  I also tried moving the BFL single over to a USB 3.0 port on the same rig, but I'm still getting the same messages.
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kano
Legendary
*
Offline Offline

Activity: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 28, 2012, 10:01:43 PM
 #7742

As a side note, I also have been getting a lot of BFL0 Comms Error or garbled message lately.  I also tried moving the BFL single over to a USB 3.0 port on the same rig, but I'm still getting the same messages.
Usually caused by either of throttling or bad USB cables

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!
vapourminer
Legendary
*
Offline Offline

Activity: 2118
Merit: 1127


what is this "brake pedal" you speak of?


View Profile
October 28, 2012, 10:03:26 PM
Last edit: October 29, 2012, 12:22:22 AM by vapourminer
 #7743


Already underway Wink

This is new in the display of the next version:
Code:
Block: 029a31ecc6e1269154fd5c6b...  Started: [08:12:07]  Best share: 7.58M


I wondered when that snuck in (compiled from git yesterday). best share so far 104k.

been running great under windows vista/7 so far.

Thanks!

EDIT: say, what does "rejected <hash, stats etc> job '57f7' not found" mean?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 02:05:34 AM
 #7744

been running great under windows vista/7 so far.

Thanks!

EDIT: say, what does "rejected <hash, stats etc> job '57f7' not found" mean?
With stratum mining that's whatever return code the server has given you for the rejection. That one usually means it has asked you to start on new work and that share is from the old work. i.e. stale.

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

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 02:12:30 AM
Last edit: October 29, 2012, 06:00:04 AM by ckolivas
 #7745

New versions -> 2.8.7, 29th October 2012

Mainly stratum fixes for windows plus minor tweaks and cosmetic changes.


Human readable changelog

After much wrestling I've discovered that windows happily sends stuff into sockets for a long time after they're dead and finally found a workaround that would realise it couldn't send them. I'm assuming the crashes people were seeing on windows are related to overflows with this phenomenon and hopefully this will improve stratum reliability further on windows.
Pool timeouts on unresponsive pools with stratum should be picked up sooner.
Failure to submit shares with stratum now also registers as an RF remote failure.
Kano tracked down a longstanding memory leak which was small but did add up over time when GPU mining.
There is a new "compact" display mode you can specify with --compact or enable it in the menu during runtime which only shows the summary stats and not a line for each device, in case you have heaps of devices and they don't fit on screen.
The best share difficulty is now displayed in the status window at the top, and in the summary on exiting.
Some details have been trimmed from the pool listing in the status window in the interest of screen real estate efficiency.


Full changelog

- Fail on select() failing in stratum thread without needing to attempt
recv_line.
- Add share to stratum database before sending it again in case we get a
response from the pool before it's added.
- Shorten the initiate stratum connect timeout to 30 seconds.
- Shorten the stratum timeout on read to 90 seconds to detect unresponsive pool.
- Display best share difficulty on exit.
- Make stratum socket fail more robust on windows by disabling the send buffer.
- Reuse the same curl handle forcing a new connection instead of risking
derefencing.
- Add information about submission failure to stratum send.
- Only add stratum share to database if we succeeded in submitting it, with a
debug output saying it succeeded.
- Use keepalive with stratum sockets to improve its ability to detect broken
connections.
- Show only the URL in the status bar to avoid long prefixes making for extra
long lines.
- Display compact status in menu and update README to reflect current menu
entries.
- Add a compact display mode that does not list per device statistics in the
status window.
- Add blank spaces after best share displayed.
- Round a few static string arrays up to 4 byte boundaries for ARM.
- Display best share diff for scrypt as well.
- Show the best diff share as "best share" and add info to the README.
- Display the best diff share submitted so far.
- Redundant check.
- The work struct pointer in struct pc_data in findnonce is never freed yet
there is no need to allocate it separately so make struct work a static part of
the struct pc_data.

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: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 29, 2012, 03:26:58 AM
Last edit: October 29, 2012, 04:39:02 AM by kano
 #7746

cut/paste ...

2.8.6
An Xubuntu 11.04 x86_64 executable is in my github downloads called cgminer-2.8.6a
https://github.com/kanoi/cgminer/downloads
(it also works on Fedora 16 and 17)

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

No problems so far on my '2xGPU+2xIcarus', 'BFL' or 'MMQ' rigs (1.5hrs so far) on OzCoin (i.e. no Stratum)

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

---

N.B. MMQ still not working on Windows but of course works great on Linux Smiley

Edit: updated - 1.5hrs

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!
dietwice
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
October 29, 2012, 04:32:05 AM
 #7747

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 04:36:30 AM
 #7748

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.

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

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 05:00:58 AM
 #7749

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.
Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

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

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 05:41:30 AM
 #7750

Hold on while I respin the 2.8.6 release as 2.8.7 Roll Eyes ... it hasn't been out that long  Tongue

Pretend you didn't see anything...

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
dietwice
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
October 29, 2012, 05:58:45 AM
 #7751

Testing 2.8.6 on Win7 x64.

There are lots of messages "Accepted untracked stratum share" among regular "Accepted 68132465..." ones.
What do they mean?

p.s. It took about 50 sec to recover normal operations when I switched to another wifi network.
And it died when I switched back.
That means the stratum pool you are mining with is returning "accepted" messages without the same ID that cgminer sent the share with, so cgminer doesn't know which shares the pool is accepting. The communication is all done asynchronously and cgminer keeps a database of sent shares so that when it gets a response from the pool it can tell you which share it was.
Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 06:00:47 AM
 #7752

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.

Yes, being a local proxy it responds quickly which is why you can reproduce it. Try 2.8.7 please.

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: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 29, 2012, 06:17:25 AM
 #7753

cut/paste ...

2.8.7

... like he said above ... Smiley

No one had already downloaded 2.8.6a it would appear except me to test the download
So I deleted it and put up 2.8.7a

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!
dietwice
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
October 29, 2012, 06:38:37 AM
 #7754

Actually come to think of it, perhaps the results are coming back before the database entry is even being created. Hmm

I connect cgminer to the mining_proxy which itself connects to the Slush's pool.
Both connections are via Stratum.
This way I get cgminer stable on network outages.

Maybe it is also a reason of getting an extra-fast response by cgminer from the other end of Stratum.

Yes, being a local proxy it responds quickly which is why you can reproduce it. Try 2.8.7 please.


Trying.
No more "untracked" shares Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2800
Merit: 1154


Ruu \o/


View Profile WWW
October 29, 2012, 11:34:45 AM
 #7755

By the way I spotted that it is still possible for a few untracked shares to rarely show up, but for the most part it is only a cosmetic issue and is corrected in the current git tree.

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: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 29, 2012, 12:29:30 PM
Last edit: October 29, 2012, 02:51:56 PM by kano
 #7756

By the way I spotted that it is still possible for a few untracked shares to rarely show up, but for the most part it is only a cosmetic issue and is corrected in the current git tree.
I've added a 2.8.7b to my downloads that is 2.8.7 + commit e19c5d9d

2.8.7b includes the extra commit coz I was seeing the untracked shares ... and this resolved it.

There's no work lost with 2.8.7a so no need to change unless you want to get rid of the occasional incorrect message when mining using stratum.

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!
Fiyasko
Legendary
*
Offline Offline

Activity: 1428
Merit: 1000


Okey Dokey Lokey


View Profile
October 29, 2012, 01:51:52 PM
 #7757

I got a share that registered a diff of 7.58M  Grin

That was a block solve for mtred since current difficulty is just over 3 million. Smiley

Woah, I was gonna make a thread aobut "whats the hardest share you've seen"
Mine is 901...
You had a 7580000 difficulty share? Woah.

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
kano
Legendary
*
Offline Offline

Activity: 2730
Merit: 1103


Linux since 1997 RedHat 4


View Profile
October 29, 2012, 03:04:02 PM
 #7758

My highest (failed) share since it was added a few weeks ago is 802K (a week after my last block)
[2012-10-29 14:24:49] Accepted 000014e8 Diff 802K/1 MMQ 0 pool 0
(11.5 hours ago - an MMQ mining on OzCoin)
That one was 1 bit away from being a block ...

But when they aren't blocks and the higher they get - the worse it is Sad

The highest difficulty share ever found will of course be in the blockchain already - but no idea which block it was - just get all the block hashes and sort them Smiley
Should be somewhere in the 100M to 1Billion range.
Though ... soon all blocks will be at least in that range ...

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!
dooferorg
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile
October 29, 2012, 05:31:53 PM
 #7759

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0:  ~400Mh
GPU 1:  OFF

to

GPU 0:   ~100Mh
GPU 1:   ~300Mh

Anyone else had this problem? It's really frustrating. I've tried an older AMD SDK (2.5) but even with reboots, driver reinstallation and cgminer recompilation it simply makes cgminer segfault on startup.

Any hints would be really appreciated.

EDIT: I realized I left out some information that might help.

I am using 'phatk' kernel, worksize 256, vectors 2 and the variables:

export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

are set before cgminer runs. CPU usage seems high though (Xorg is the top), which is concerning. The CPU in the system is an AMD FX 4170 (4.2Ghz) quad core.

BTC: 1dooferoD3vnwgez3Jo1E4bFfgMf81LR2
ZEC: t1gnToN2HZW4GD52kofEVdijhRijWjCNfYi
burger
Full Member
***
Offline Offline

Activity: 195
Merit: 100


View Profile
October 29, 2012, 07:51:08 PM
 #7760

I'm using cgminer on Linux for the particular machine I'm discussing here. It had one 5870 card in it and I was getting ~430Mh/s out of it. Not too bad.

I happened to get my hands on another 5870 so I thought I'd pop that in too. I have both GPUs turning up in cgminer (after a little trouble, but 'aticonfig -f --adapter=all --initial' worked wonders.

I have cgminer 2.8.7 (same behavior with 2.8.5), AMD SDK 2.7 and Catalyst 12.10.

If I only enable one GPU, I get the hashrate as before. If I enable both GPUs, the first GPUs hashrate plummets. Net result is I'm still only getting the same hashrate but now it's 'using' both GPUs.

e.g.
GPU 0:  ~400Mh
GPU 1:  OFF

to

GPU 0:   ~100Mh
GPU 1:   ~300Mh

Anyone else had this problem? It's really frustrating. I've tried an older AMD SDK (2.5) but even with reboots, driver reinstallation and cgminer recompilation it simply makes cgminer segfault on startup.

Any hints would be really appreciated.

EDIT: I realized I left out some information that might help.

I am using 'phatk' kernel, worksize 256, vectors 2 and the variables:

export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

are set before cgminer runs. CPU usage seems high though (Xorg is the top), which is concerning. The CPU in the system is an AMD FX 4170 (4.2Ghz) quad core.


You might have to use other intensity for that, I get high cpu usuage when intensity is at 1 on windows and cpu at about 0% with I: 9.

Pages: « 1 ... 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 433 434 435 436 437 438 ... 844 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
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!