Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 391. (Read 5806015 times)
March 19, 2013, 06:08:24 PM
I'm guessing you're talking about windows. Windows does random things with the logging output it seems. Gotta love its (arse)soul.
March 19, 2013, 05:57:04 PM
I am the author of Bitcoin Miners in Tray, a Windows universal front-end for coin miners:
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
I run cgminer inside a GUIMiner derivative, and I haven't noticed any problems such as the one you're describing.
Try adding -l 1 (lower-case-L one) to your startup parameters.
Thanks for the tip. Specifying -l 1 starts producing a consistent output. Interestingly, giving any other value than 1 will lock output on stdout until cgminer is stopped, at which time a lot of the output is dumped to the pipe. Something is definitely wrong. Only CGMiner (and pooler's cpuminer, but in that case on stderr) display this problem. poclbm, rpcminer and phoenix seem to work fine.
Here is output with -l 2 (output from my front-end is green, stderr is red, stdout is blue):
19.03.2013 23:49 [Litecoin with CGMiner (NVidia)]: Launching 'cgminer.exe --scrypt -o http://coinotron.com:8322 -u user -p pass -I d -T -l 2'
19.03.2013 23:49 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:49:59] Started cgminer 2.11.3
19.03.2013 23:49 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:49:59] Probing for an alive pool
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:02] Long-polling activated for http://coinotron.com:8322/LP
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: Stopping miner...
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Thread 0 being disabled
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09]
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: Summary of runtime statistics:
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Started at [2013-03-19 23:50:02]
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Pool: http://coinotron.com:8322
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Runtime: 0 hrs : 0 mins : 6 secs
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Average hashrate: 1.9 Kilohash/s
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Solved blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Best share difficulty: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Queued work requests: 1
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Share submissions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Accepted shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Rejected shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Accepted difficulty shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Rejected difficulty shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Hardware errors: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Efficiency (accepted / queued): 0%
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Utility (accepted shares / min): 0.00/min
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Work Utility (diff1 shares solved / min): 0.00/min
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Discarded work due to new blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Stale submissions discarded due to new blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Unable to get work from server occasions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Work items generated locally: 4
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Submitting work remotely delay occasions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] New blocks detected on network: 1
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Summary of per device statistics:
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] GPU0 (2s):0.000 (avg):1.886Kh/s | A:0 R:0 HW:0 U:0.0/m I: 8
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:49:59] Started cgminer 2.11.3
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:49:59] Probing for an alive pool
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:02] Long-polling activated for http://coinotron.com:8322/LP
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Thread 0 being disabled
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09]
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: Summary of runtime statistics:
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Started at [2013-03-19 23:50:02]
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Pool: http://coinotron.com:8322
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Runtime: 0 hrs : 0 mins : 6 secs
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Average hashrate: 1.9 Kilohash/s
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Solved blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Best share difficulty: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Queued work requests: 1
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Share submissions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Accepted shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Rejected shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Accepted difficulty shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Rejected difficulty shares: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Hardware errors: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Efficiency (accepted / queued): 0%
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Utility (accepted shares / min): 0.00/min
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Work Utility (diff1 shares solved / min): 0.00/min
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Discarded work due to new blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Stale submissions discarded due to new blocks: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Unable to get work from server occasions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Work items generated locally: 4
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Submitting work remotely delay occasions: 0
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] New blocks detected on network: 1
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] Summary of per device statistics:
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:50:09] GPU0 (2s):0.000 (avg):1.886Kh/s | A:0 R:0 HW:0 U:0.0/m I: 8
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: Shutdown signal received.
19.03.2013 23:50 [Litecoin with CGMiner (NVidia)]: Miner stopped.
And here is output with -l 1:
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Launching 'cgminer.exe --scrypt -o http://coinotron.com:8322 -u user -p pass -I d -T -l 1'
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:16] Started cgminer 2.11.3
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:16] Probing for an alive pool
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:17] Long-polling activated for http://coinotron.com:8322/LP
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:16] Started cgminer 2.11.3
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:16] Probing for an alive pool
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:17] Long-polling activated for http://coinotron.com:8322/LP
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):955.0 (avg):1.510Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):1.646K (avg):1.776Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):2.516K (avg):2.193Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):2.436K (avg):2.219Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):2.108K (avg):2.068Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):1.901K (avg):1.962Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Stopping miner...
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:25] Thread 0 being disabled
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: (1s):1.766K (avg):1.897Kh/s | Q:1 A:0 R:0 HW:0 E:0% U:0.0/m
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26]
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Summary of runtime statistics:
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Started at [2013-03-19 23:52:17]
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Pool: http://coinotron.com:8322
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Runtime: 0 hrs : 0 mins : 8 secs
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Average hashrate: 1.9 Kilohash/s
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Solved blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Best share difficulty: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Queued work requests: 1
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Share submissions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Accepted shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Rejected shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Accepted difficulty shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Rejected difficulty shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Hardware errors: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Efficiency (accepted / queued): 0%
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Utility (accepted shares / min): 0.00/min
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Work Utility (diff1 shares solved / min): 0.00/min
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Discarded work due to new blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Stale submissions discarded due to new blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Unable to get work from server occasions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Work items generated locally: 4
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Submitting work remotely delay occasions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] New blocks detected on network: 1
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Summary of per device statistics:
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] GPU0 (1s):0.000 (avg):1.897Kh/s | A:0 R:0 HW:0 U:0.0/m I: 8
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:25] Thread 0 being disabled
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26]
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Summary of runtime statistics:
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Started at [2013-03-19 23:52:17]
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Pool: http://coinotron.com:8322
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Runtime: 0 hrs : 0 mins : 8 secs
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Average hashrate: 1.9 Kilohash/s
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Solved blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Best share difficulty: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Queued work requests: 1
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Share submissions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Accepted shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Rejected shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Accepted difficulty shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Rejected difficulty shares: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Hardware errors: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Efficiency (accepted / queued): 0%
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Utility (accepted shares / min): 0.00/min
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Work Utility (diff1 shares solved / min): 0.00/min
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Discarded work due to new blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Stale submissions discarded due to new blocks: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Unable to get work from server occasions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Work items generated locally: 4
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Submitting work remotely delay occasions: 0
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] New blocks detected on network: 1
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] Summary of per device statistics:
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: [2013-03-19 23:52:26] GPU0 (1s):0.000 (avg):1.897Kh/s | A:0 R:0 HW:0 U:0.0/m I: 8
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Shutdown signal received.
19.03.2013 23:52 [Litecoin with CGMiner (NVidia)]: Miner stopped.
March 19, 2013, 04:28:01 PM
Guy's
I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
It's the same counter used to display when you get the exit summary as is used to display it in the API.I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
Of course, if you zero the stats - that gets zeroed also.
Kano,
I have not zeroed the stats. I will check it out on exit when i do upgrade cgminer. I am sure that there is something wrong. Anyway, I will let you know what info i get on exit
Best
The variable that stores the block counter is the same one both pieces of code use.
I did notice yesterday that ... 9 months ago
... ckolivas added a pool block counter that also keeps track of blocks per pool - that I've never added to the API - it's now in my ... todo list 
March 19, 2013, 04:22:30 PM
...
I tried a cpu litecoin mining software, and the speed from the mining software does pretty much match with the pool speed.
Does anyone have this strange effect too, or knows what the reason could be?
CPU mining is not supported ... I tried a cpu litecoin mining software, and the speed from the mining software does pretty much match with the pool speed.
Does anyone have this strange effect too, or knows what the reason could be?
March 19, 2013, 04:17:15 PM
I am the author of Bitcoin Miners in Tray, a Windows universal front-end for coin miners:
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
I run cgminer inside a GUIMiner derivative, and I haven't noticed any problems such as the one you're describing.
Try adding -l 1 (lower-case-L one) to your startup parameters.
March 19, 2013, 03:48:21 PM
Got to say I have tried loads of other software for mining and this has got to be my favourite 
Keep up the awesome work
Thanks Keep up the awesome work it's a labour of love (and anger and hatred and frustration and trolling and headache and heartache and pain at times).Without all your work think about how many people would not be mining.
Never give up
March 19, 2013, 03:44:03 PM
I am the author of Bitcoin Miners in Tray, a Windows universal front-end for coin miners:
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
https://bitcointalksearch.org/topic/m.1642010
http://stanislavs.org/bitcoin-miners-in-tray-miner-gui-manager/
When testing it with CGMiner, I discovered a bug in how CGMiner outputs lines on stdout. First of all CGMiner needs to be started with -T to disable ncurses, which is fine.
The output on stderr is also written correctly, so that the front-end gets an event after each line that is sent to stderr stream from CGMiner.
stdout, on the other hand is not flushed after each line, so that the front-end gets all text on stdout redirection in one huge chunk at the moment when CGMiner stops and closes its streams.
The only workaround is to use --verbose and read what should have been on stdout from stderr, living with that huge text dump when CGMiner stops.
Could those, who are maintaining CGMiner fix this issue, applying the same writing strategy to stdout as is done to stderr?
March 19, 2013, 10:01:04 AM
Guy's
I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
It's the same counter used to display when you get the exit summary as is used to display it in the API.I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
Of course, if you zero the stats - that gets zeroed also.
Kano,
I have not zeroed the stats. I will check it out on exit when i do upgrade cgminer. I am sure that there is something wrong. Anyway, I will let you know what info i get on exit
Best
March 19, 2013, 09:52:15 AM
i use 24 computer to mine, until today no problem at all but this morning the shit hit me hard. when i open cgminer.exe what surprise i have there....... virus: UnclassifiedMalware@1 just say to me that shit dont come with cgminer 
If you search this thread you will probably come up with hundreds of replies about false virus scanner hits. Email a complaint about the false hit to your antivirus vendor.
March 19, 2013, 08:54:22 AM
Large difference between cgminer mining speed and mining speed on pool.
First my test configuration:
ubuntu 12.10 x64
AMD HD-5750
gpu-driver catalyst-13.2-beta7-linux-x86
cgminer 2.11.3 (self-compiled)
Pool: litecoinpool
Everything seems to work normal, even if I still didn't optimized the setup.
cgminer starts mining at a relatively constant rate of about 130Kh/s.
The cgminer output look good to me:
[2013-03-19 14:50:13] Started cgminer 2.11.3
[2013-03-19 14:50:13] Probing for an alive pool
[2013-03-19 14:50:13] Long-polling activated for http://litecoinpool.org:9332/LP
[2013-03-19 14:50:16] Accepted 3f12469b Diff 4/1 GPU 0
[2013-03-19 14:50:20] Accepted 28f14178 Diff 6/1 GPU 0
[2013-03-19 14:50:32] Accepted 40203bbe Diff 3/1 GPU 0
[2013-03-19 14:50:32] Accepted 698335d9 Diff 2/1 GPU 0
....
But the mining speed I can see at the pool is only about 13Kh/s, so 1/10 of the expected rate.
It's not only a speed calculation issue, because I traced over a longer period the number of shares the pool received and they are also only about 1/10 of the expected number.
I tried a cpu litecoin mining software, and the speed from the mining software does pretty much match with the pool speed.
Does anyone have this strange effect too, or knows what the reason could be?
First my test configuration:
ubuntu 12.10 x64
AMD HD-5750
gpu-driver catalyst-13.2-beta7-linux-x86
cgminer 2.11.3 (self-compiled)
Pool: litecoinpool
Everything seems to work normal, even if I still didn't optimized the setup.
cgminer starts mining at a relatively constant rate of about 130Kh/s.
The cgminer output look good to me:
[2013-03-19 14:50:13] Started cgminer 2.11.3
[2013-03-19 14:50:13] Probing for an alive pool
[2013-03-19 14:50:13] Long-polling activated for http://litecoinpool.org:9332/LP
[2013-03-19 14:50:16] Accepted 3f12469b Diff 4/1 GPU 0
[2013-03-19 14:50:20] Accepted 28f14178 Diff 6/1 GPU 0
[2013-03-19 14:50:32] Accepted 40203bbe Diff 3/1 GPU 0
[2013-03-19 14:50:32] Accepted 698335d9 Diff 2/1 GPU 0
....
But the mining speed I can see at the pool is only about 13Kh/s, so 1/10 of the expected rate.
It's not only a speed calculation issue, because I traced over a longer period the number of shares the pool received and they are also only about 1/10 of the expected number.
I tried a cpu litecoin mining software, and the speed from the mining software does pretty much match with the pool speed.
Does anyone have this strange effect too, or knows what the reason could be?
March 19, 2013, 08:30:53 AM
i use 24 computer to mine, until today no problem at all but this morning the shit hit me hard. when i open cgminer.exe what surprise i have there....... virus: UnclassifiedMalware@1 just say to me that shit dont come with cgminer
From the README.txt, FAQ Section:
Q: Is this a virus?
A: Cgminer is being packaged with other trojan scripts and some antivirus
software is falsely accusing cgminer.exe as being the actual virus, rather
than whatever it is being packaged with. If you installed cgminer yourself,
then you do not have a virus on your computer. Complain to your antivirus
software company. They seem to be flagging even source code now from cgminer
as viruses, even though text source files can't do anything by themself.
March 19, 2013, 08:23:11 AM
i use 24 computer to mine, until today no problem at all but this morning the shit hit me hard. when i open cgminer.exe what surprise i have there....... virus: UnclassifiedMalware@1 just say to me that shit dont come with cgminer
"that shit dont come with cgminer"
March 19, 2013, 08:00:59 AM
i use 24 computer to mine, until today no problem at all but this morning the shit hit me hard. when i open cgminer.exe what surprise i have there....... virus: UnclassifiedMalware@1 just say to me that shit dont come with cgminer
March 19, 2013, 06:10:20 AM
Guy's
I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
It's the same counter used to display when you get the exit summary as is used to display it in the API.I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
Of course, if you zero the stats - that gets zeroed also.
March 19, 2013, 05:59:08 AM
Guy's
I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
I have posted this before and i am posting it again.
Today i found a block and and cgminer api stats Found Blocks equals to 0. It happened two or three times since my last post about it.
something happened from 2.10.5 onwards
PS:
To all of you who use cgminer - Do you see Found Blocks >0 when you know you have found a block with versions 2.10.5 onward
Thanks!
March 19, 2013, 05:25:25 AM
Hi guys,
Quick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
cgminer -c conf.fooQuick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
That will ignore any other conf file (e.g. the default one)
Ah! That sounds like exactly what I need Kano, thanks man. Do I need to worry about the saved .bin file at all - or will it also ignore that with this command?
Peace.
March 18, 2013, 10:46:17 PM
Hi guys,
Quick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
cgminer -c conf.fooQuick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
That will ignore any other conf file (e.g. the default one)
March 18, 2013, 10:20:48 PM
Hi guys,
Quick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
Quick question for you, If I want to use cgminer on a pool that requires a completely different configuration from my normal .conf file, which I want to keep, can I load a separate .conf file at startup from the same/a different folder? If so, what is the command needed to load the required .conf from a specified location? Or, is it a case of saving the original .conf file somewhere for use later and making a new .conf file for the pool that needs a different card setup I want to use cgminer on at that time? Ideally I'd like to just add the new pool to my original .conf file and have it load the different configuration required for that particular pool, but after scanning the readme I can't see how it can be done - or have I missed something?
Cheers.
March 18, 2013, 10:02:28 PM
Got to say I have tried loads of other software for mining and this has got to be my favourite
Keep up the awesome work
Thanks Keep up the awesome work it's a labour of love (and anger and hatred and frustration and trolling and headache and heartache and pain at times). 
March 18, 2013, 10:02:06 PM
I've been playing a bit with cgminer (2.11.2 and 2.11.3) and scrypt during the last few hours.
So far the best performance I could achieve on my GV-R797OC-3GD on windows 7 x64 with catalyst 13.2b7 was around 720kH/s with the following settings:
a more conservative 620kH/s with
and an even more conservative 550kH/s with
Increasing thread concurrency above 8192 with --lookup-gap 2 always returns an error like
Lowering thread concurrency below 8192 always produces hardware errors.
With -g > 1 using any intensity higher or lower than 13 will result in lower hashrates.
With -g 1 higher than 13 intensities will more or less match -g 2 -I 13 hashrate at the expenses of system responsiveness.
Increasing lookup gap allows for higher thread concurrencies, but it won't improve performance.
Setting the correct core/memory ratio for your card is the most important tweak, even a small 10MHz difference can make you lose/gain 100-200kH/s.
So far the best performance I could achieve on my GV-R797OC-3GD on windows 7 x64 with catalyst 13.2b7 was around 720kH/s with the following settings:
Code:
cgminer.exe --scrypt -o http://xxx -u x -p x --intensity 13 -g 2 --thread-concurrency 8192 --lookup-gap 2 --gpu-engine 1044 --gpu-memclock 1500
a more conservative 620kH/s with
Code:
cgminer.exe --scrypt -o http://xxx -u x -p x --intensity 13 -g 2 --thread-concurrency 8192 --lookup-gap 2 --gpu-engine 900 --gpu-memclock 1155
and an even more conservative 550kH/s with
Code:
cgminer.exe --scrypt -o http://xxx -u x -p x --intensity 13 -g 2 --thread-concurrency 8192 --lookup-gap 2 --gpu-engine 800 --gpu-memclock 870
Increasing thread concurrency above 8192 with --lookup-gap 2 always returns an error like
Code:
Maximum buffer memory device 0 supports says 536870912
Your scrypt settings come to 1467482112
Error -61: clCreateBuffer (padbuffer8), decrease CT or increase LG
Lowering thread concurrency below 8192 always produces hardware errors.
With -g > 1 using any intensity higher or lower than 13 will result in lower hashrates.
With -g 1 higher than 13 intensities will more or less match -g 2 -I 13 hashrate at the expenses of system responsiveness.
Increasing lookup gap allows for higher thread concurrencies, but it won't improve performance.
Setting the correct core/memory ratio for your card is the most important tweak, even a small 10MHz difference can make you lose/gain 100-200kH/s.
can anyone get 720kH/s with 1044/1500 and cgminer.exe --scrypt -o http://xxx -u x -p x --intensity 13 -g 2 --thread-concurrency 8192 --lookup-gap 2i can't
i have to set it to 1015/1760 to get 705
Jump to: