chewie
Member
Offline
Activity: 75
Merit: 10
|
|
October 28, 2012, 09:33:13 PM |
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 28, 2012, 10:01:43 PM |
|
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
Legendary
Offline
Activity: 4466
Merit: 4017
what is this "brake pedal" you speak of?
|
|
October 28, 2012, 10:03:26 PM Last edit: October 29, 2012, 12:22:22 AM by vapourminer |
|
Already underway This is new in the display of the next version: 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 (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 02:05:34 AM |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 02:12:30 AM Last edit: October 29, 2012, 06:00:04 AM by ckolivas |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 29, 2012, 03:26:58 AM Last edit: October 29, 2012, 04:39:02 AM by kano |
|
cut/paste ... 2.8.6An 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
Newbie
Offline
Activity: 58
Merit: 0
|
|
October 29, 2012, 04:32:05 AM |
|
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 (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 04:36:30 AM |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 05:00:58 AM |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 05:41:30 AM |
|
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...
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
dietwice
Newbie
Offline
Activity: 58
Merit: 0
|
|
October 29, 2012, 05:58:45 AM |
|
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 (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 06:00:47 AM |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 29, 2012, 06:17:25 AM |
|
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
Newbie
Offline
Activity: 58
Merit: 0
|
|
October 29, 2012, 06:38:37 AM |
|
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 (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
October 29, 2012, 11:34:45 AM |
|
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, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 29, 2012, 12:29:30 PM Last edit: October 29, 2012, 02:51:56 PM by 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
Legendary
Offline
Activity: 1428
Merit: 1001
Okey Dokey Lokey
|
|
October 29, 2012, 01:51:52 PM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
October 29, 2012, 03:04:02 PM |
|
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
|
|
October 29, 2012, 05:31:53 PM |
|
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
|
|
October 29, 2012, 07:51:08 PM |
|
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.
|
|
|
|
|