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

[chewie]

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.

[1713410374]

1713410374

[1713410374]

1713410374

[1713410374]

1713410374

[1713410374]

1713410374

[1713410374]

1713410374

[kano]

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

[vapourminer]

Already underway

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]

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.

[-ck]

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.

[kano]

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

Edit: updated - 1.5hrs

[dietwice]

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]

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.

[-ck]

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

[-ck]

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

Pretend you didn't see anything...

[dietwice]

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]

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.

[kano]

cut/paste ...

2.8.7

... like he said above ...

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

[dietwice]

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

[-ck]

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.

[kano]

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.

[Fiyasko]

I got a share that registered a diff of 7.58M 

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

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.

[kano]

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

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
Should be somewhere in the 100M to 1Billion range.
Though ... soon all blocks will be at least in that range ...

[dooferorg]

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.

[burger]

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.