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

[ancow]

I don't like the one-string "http://bar:baz@foo.example.org:8332" style.
(a) it's ugly and human-unfriendly
(b) you'll almost certainly get parsing that thing wrong (passwords with spaces in them, anyone?)
(c) this way you can use additional options, like different timeouts or "ignore this host's longpoll offer, it's broken" options, per connection.

(d) there are pools like deepbit that have an @ in the username...

Which reminds me, long polling still isn't working with deepbit.

[1714138112]

1714138112

[1714138112]

1714138112

[1714138112]

1714138112

[xcooling]

lol..
u prase the string from right to left..
then spaces in passwords and @ in usernames is not an issue ;-P

Json encoded is prefered
connections: [
   {url: "http://foo.example.org:8332", username: "bar", password: "baz"},
   {url: "http://bar.example.org:8332", username: "baz", password: "quux"}
],
…

[smurfix]

likely using a urlX counter in the parameters will be the solution

Please don't; JSON has nice shiny arrays for that sort of thing.

then spaces in passwords and @ in usernames is not an issue ;-P

OK, I'll bite: Passwords with colons in them, anyone?  :-P

The best string to parse is one which you don't need to parse at all.

[OCedHrt]

how does one specify phatk110714.cl or poclbm110717.cl ?

One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards.

Phoenix with phatk worked on my 4850, and that was faster than poclbm.

[kr105]

Yesterday i had the same problem, the miner crashing after ~10seconds. The problem was wrong login/url details, i fixed them and problem solved

[OCedHrt]

Sample output on exiting now:

Code:

Summary of runtime statistics:

Started at [2011-07-19 14:40:09]
Runtime: 2 hrs : 31 mins : 18 secs
Average hashrate: 1680.1 Megahash/s
Queued work requests: 3317
Share submissions: 3489
Accepted shares: 3489
Rejected shares: 0
Reject ratio: 0.0
Hardware errors: 0
Efficiency (accepted / queued): 105%
Utility (accepted shares / min): 23.06/min

Discarded work due to new blocks: 0
Stale submissions discarded due to new blocks: 9
Unable to get work from server occasions: 16
Work items generated locally: 330
Submitting work remotely delay occasions: 33
New blocks detected on network: 10

Pool: http://ozco.in:8332
 Queued work requests: 3253
 Share submissions: 3426
 Accepted shares: 3426
 Rejected shares: 0
 Reject ratio: 0.0
 Efficiency (accepted / queued): 105%
 Discarded work due to new blocks: 0
 Stale submissions discarded due to new blocks: 9
 Unable to get work from server occasions: 15
 Submitting work remotely delay occasions: 33

Pool: http://bitcoinpool.com:8334
 Queued work requests: 64
 Share submissions: 63
 Accepted shares: 63
 Rejected shares: 0
 Reject ratio: 0.0
 Efficiency (accepted / queued): 98%
 Discarded work due to new blocks: 0
 Stale submissions discarded due to new blocks: 0
 Unable to get work from server occasions: 1
 Submitting work remotely delay occasions: 0

Summary of per device statistics:

 GPU 0: [419.9 Mh/s] [Q:913  A:901  R:0  HW:0  E:99%  U:5.96/m]
 GPU 1: [420.1 Mh/s] [Q:912  A:865  R:0  HW:0  E:95%  U:5.72/m]
 GPU 2: [420.5 Mh/s] [Q:908  A:865  R:0  HW:0  E:95%  U:5.72/m]
 GPU 3: [419.6 Mh/s] [Q:910  A:858  R:0  HW:0  E:94%  U:5.68/m]

Btw, forgot to mention this doesn't seem to be working on Windows. And should the run time output include hash rate per thread? I only see per device.

[eck]

I'm running 2 6990s (both with the OC switch on the overclocked position, but no further OCing) on a single-core Sempron 140. With cgminer, one card gets the expected performance, but the other one is incredibly low (40-50Mhash per GPU). I'm using an intensity of 9 as suggested in the original post for 6990s.

This is the exit output:

 GPU 0: [395.7 Mh/s] [Q:91  A:85  R:3  HW:0  E:93%  U:5.55/m]
 GPU 1: [395.6 Mh/s] [Q:92  A:96  R:1  HW:0  E:104%  U:6.20/m]
 GPU 2: [39.4 Mh/s] [Q:12  A:5  R:0  HW:0  E:42%  U:3.13/m]
 GPU 3: [46.4 Mh/s] [Q:13  A:10  R:0  HW:0  E:83%  U:5.95/m]

[Zenitur]

Code:

zenitur@athlon64x2 ~/cgminer-1.3.0 $ cgminer -o http://pool.itzod.ru:8344 -u Zenitur_0 -p apetytype -I 10

Summary of per device statistics:

 GPU 0: [33.1 Mh/s] [Q:2  A:2  R:0  HW:0  E:100%  U:1.17/m]

zenitur@athlon64x2 ~/cgminer-1.3.0 $ cgminer -o http://pool.itzod.ru:8344 -u Zenitur_0 -p apetytype -I 10 -T --cpu-threads 1

Summary of per device statistics:

 GPU 0: [33.9 Mh/s] [Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 0: [0.0 Mh/s] [Q:1  A:0  R:0  HW:0  E:0%  U:0.00/m]

zenitur@athlon64x2 ~/cgminer-1.3.0 $ cgminer -o http://pool.itzod.ru:8344 -u Zenitur_0 -p apetytype -I 10 -T --cpu-threads 0

Summary of per device statistics:

 GPU 0: [32.5 Mh/s] [Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m]

zenitur@athlon64x2 ~/cgminer-1.3.0 $ cgminer -o http://pool.itzod.ru:8344 -u Zitur_0 -p apetytype -I 10 -T --cpu-threads 1 --algo sse2_64

Summary of per device statistics:

 GPU 0: [32.2 Mh/s] [Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 0: [0.0 Mh/s] [Q:1  A:0  R:0  HW:0  E:0%  U:0.00/m]

zenitur@athlon64x2 ~/cgminer-1.3.0 $ cgminer -o http://pool.itzod.ru:8344 -u Zenitur_0 -p apetytype -I 10 -T --cpu-threads 1 --algo cryptopp

Summary of per device statistics:

 GPU 0: [32.6 Mh/s] [Q:2  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 0: [0.0 Mh/s] [Q:1  A:0  R:0  HW:0  E:0%  U:0.00/m]

0.0 Mh/s with CPU. Why? Linux.
P.S. I'm using 1 thread because of nvidia driver loads 1 CPU core on 100% when working.

[-ck]

Updated tree: Re-enabled the watchdog thread code (which was disabled in 1.3.0), reworked to be smarter and only restart threads not waiting on work and have gone idle for some other reason (gpu overheated, gpu code stuck etc.).

[xcooling]

quick question re: mingw.

Once I have run ./configure and make.. how do i package the cgminer.exe and the dependant dlls.

Been making some pretty cpu specific compiles.. just not sure what the cmd is to package them after compile.

[-ck]

There isn't a binary distribution packaging command, only a source one (make distdir). Ycros has been packaging the 3 necessary dlls, the 2 .cl files, the executable and READMEs himself into zips. He may have automated it for himself, I'm not sure.

[xcooling]

thanks.. ill script it.

[error]

Just downloaded the 1.30 tarball, and now I can't solo mine:

Code:

$ ./cgminer -g 1 -u user -p password -o http://127.0.0.1:8332/
[2011-07-19 22:50:00] ./cgminer: -u: No URL set for user

[ancow]

[note: url must come before username/password now]

Just downloaded the 1.30 tarball, and now I can't solo mine:

Code:

$ ./cgminer -g 1 -u user -p password -o http://127.0.0.1:8332/
[2011-07-19 22:50:00] ./cgminer: -u: No URL set for user

Where's the confusion?

[error]

[note: url must come before username/password now]

Just downloaded the 1.30 tarball, and now I can't solo mine:

Code:

$ ./cgminer -g 1 -u user -p password -o http://127.0.0.1:8332/
[2011-07-19 22:50:00] ./cgminer: -u: No URL set for user

Where's the confusion?

DOH! That'll teach me to not read the README.

[error]

OK, hopefully this isn't a brain fart too.

I am seeing blank lines between the log entries at the bottom of the screen, whereas in previous versions there were no blank lines between each log entry:

Code:

 cgminer version 1.3.0 - Started: [2011-07-19 23:12:54]
--------------------------------------------------------------------------------
 [(5s):54.8  (avg):48.9 Mh/s] [Q:104  A:0  R:12  HW:0  E:0%  U:0.00/m]
 TQ: 1  ST: 1  LS: 0  SS: 0  DW: 7  NB: 2  LW: 0  LO: 0  RF: 0  I: 3
 Connected to http://127.0.0.1:8332/ as user error
 Block 00015dde0574cea123d8f8da7d2aea5f  started: [2011-07-19 23:20:35]
--------------------------------------------------------------------------------
 GPU 0: [35.0 Mh/s] [Q:8  A:0  R:11  HW:0  E:0%  U:0.00/m]
 CPU 0: [1.5 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 1: [1.8 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 2: [1.8 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 3: [1.8 Mh/s] [Q:11  A:0  R:1  HW:0  E:0%  U:0.00/m]
 CPU 4: [1.7 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 5: [1.9 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
 CPU 6: [1.5 Mh/s] [Q:11  A:0  R:1  HW:0  E:0%  U:0.00/m]
 CPU 7: [1.9 Mh/s] [Q:11  A:0  R:0  HW:0  E:0%  U:0.00/m]
--------------------------------------------------------------------------------


[2011-07-19 23:21:54] Share e0d430be rejected from GPU 0 thread 0

[2011-07-19 23:22:16] Share f87f7bf4 rejected from GPU 0 thread 0

[-ck]

New release: 1.3.1
Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.3.1.tar.bz2

Windows binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.3.1-win32.zip

Executive summary:
Multiple failover strategies available by user choice. More lax with inputting values for multiple pools. Faster switch on pool change. Watchdog thread for dead GPU threads reinstated.


- Feature upgrade; Multiple strategies for failover. Choose from default which
now falls back to a priority order from 1st to last, round robin which only
changes pools when one is idle, rotate which changes pools at user-defined
intervals, and load-balance which spreads the work evenly amongst all pools.
- Implement pool rotation strategy.
- Implement load balancing algorithm by rotating requests to each pool.
- Timeout on failed discarding of staged requests.
- Implement proper flagging of idle pools, test them with the watchdog thread,
and failover correctly.
- Move pool active test to own function.
- Allow multiple strategies to be set for multipool management.
- Track pool number.
- Don't waste the work items queued on testing the pools at startup.
- Reinstate the mining thread watchdog restart.
- Add a getpoll bool into the thread information and don't restart threads stuck
waiting on work.
- Rename the idlenet bool for the pool for later use.
- Allow the user/pass userpass urls to be input in any order.
- When json rpc errors occur they occur in spits and starts, so trying to limit
them with the comms error bool doesn't stop a flood of them appearing.
- Reset the queued count to allow more work to be queued for the new pool on
pool switch.


New options:
--load-balance      Change multipool strategy from failover to even load balance
--rotate <arg>      Change multipool strategy from failover to regularly rotate at N minutes (default: 0)
--round-robin       Change multipool strategy from failover to round robin on failure


From the README:

FAILOVER STRATEGIES WITH MULTIPOOL:
A number of different strategies for dealing with multipool setups are
available. Each has their advantages and disadvantages so multiple strategies
are available by user choice, as per the following list:

FAILOVER:
The default strategy is failover. This means that if you input a number of
pools, it will try to use them as a priority list, moving away from the 1st
to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will
move back to the higher priority ones.

ROUND ROBIN:
This strategy only moves from one pool to the next when the current one falls
idle and makes no attempt to move otherwise.

ROTATE:
This strategy moves at user-defined intervals from one active pool to the next,
skipping pools that are idle.

LOAD BALANCE:
This strategy sends work in equal amounts to all the pools specified. If any
pool falls idle, the rest will take up the slack keeping the miner busy.

[loglow]

Great software. Thank you. Some possible bugs though.

1) Running the program (with proper server and credentials specified) from locations besides /usr/local/bin/ or /opt/cgminer-1.3.1/ results in the following crash:

Code:

[2011-07-20 01:49:45] Unable to open phatk110714.cl for reading

Segmentation fault

2) Running the program from /usr/local/bin/ results in non-ncurses output (without flag) and the program segfaults on exit (ctrl-c) without displaying statistics.

So it seems I can only run the program properly with my current directory set to /opt/cgminer-1.3.1/ for the time being. I'm running Ubuntu 11.04 x64 with Catalyst 11.6 and AMD APP SDK 2.4. Please let me know if you need any additional information.

Take care.

[zaytsev]

It is my impression that now I know exactly how it segfaults. I run cgminer in a screen instance and I am sometimes switching between computers with widely different screen resolution. At the same time, I always have my terminal windows fully maximized. So when I switch to a computer with a different screen size and switch to the screen window where cgminer is open it crashes.

I think there might be a problem with how it processes SIGWINCH w.r.t. ncurses... ck, does it help? Is there a way I can gather more information for you?

P.S. New RPMs are ready.

[Ryu.Hayabusa]

Thanks for this great program!  I'll be sure to donate as soon as I start generating some decent bitcoin.

I had an issue with the (now) older version 1.2.8 where it would crash on startup when a system had more than 4 NVIDIA GPUs available (Windows 7 64-bit).  I'll test it again with the new version.


One issue I see with the new 1.3.1 version is with the --load-balance option with 2 pools, it continually repeats that new block detected before longpoll.  One pool is bitcoin while the other is namecoin if that makes a difference.  Running 2 instances separately this message does not occur.


cgminer version 1.3.1 - Started: [2011-07-20 00:36:51]
-------------------------------------------------------------------------------
[(5s):347.7  (avg):341.7 Mh/s] [Q:176  A:4  R:0  HW:0  E:2%  U:2.89/m]
TQ: 1  ST: 0  LS: 0  SS: 0  DW: 0  NB: 146  LW: 0  LO: 0  RF: 0  I: 5
Connected to multiple pools
Block xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  started: [2011-07-20 00:38:18]
-------------------------------------------------------------------------------
GPU 0: [354.9 Mh/s] [Q:186  A:5  R:0  HW:0  E:3%  U:3.62/m]
-------------------------------------------------------------------------------

2011-07-20 00:38:16] New block detected on network before longpoll, waiting on
resh work
2011-07-20 00:38:17] Accepted xxxxxxxx GPU 0 thread 1 pool 1

2011-07-20 00:38:17] New block detected on network before longpoll, waiting on
resh work
2011-07-20 00:38:17] New block detected on network before longpoll, waiting on
resh work
2011-07-20 00:38:17] New block detected on network before longpoll, waiting on
resh work
2011-07-20 00:38:18] New block detected on network before longpoll, waiting on
resh work
2011-07-20 00:38:18] New block detected on network before longpoll, waiting on
resh work