The CPU will NOT be the limiting factor if he's on linux. If on Windows, yeah, sucks to have that single-core semprom.
Why not on linux if you're saturating the bus(HT) of the CPU?
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 835. (Read 5805677 times)
July 20, 2011, 04:01:54 AM
Why not on linux if you're saturating the bus(HT) of the CPU?
July 20, 2011, 03:40:39 AM
Just a heads up for a few people.
Cgminer does not appear to support target rewrites. I have checked the code and the target is derived from midstate and "data" from the getwork. Thus when the pools send you diff 1 work, cgminer ignores that and mines with full difficulty and since the gpu miner code does not check if the hash meets the difficulty, it sends a result anyway. This is why some people have reported they get less shares with cgminer.
For proof, go into findnonce.c and in the precalc function add somewhere, compile and run, it will print the nbits of the current target.
I'd categorize this as a serious flaw. Miners still submitted work, but far less than usual. In the long run, people earned waay less than they should have.
P.S
Conman is aware of this, however is reluctant to fix it. The excuse was "It sends shares, doesn't it?"
Cgminer does not appear to support target rewrites. I have checked the code and the target is derived from midstate and "data" from the getwork. Thus when the pools send you diff 1 work, cgminer ignores that and mines with full difficulty and since the gpu miner code does not check if the hash meets the difficulty, it sends a result anyway. This is why some people have reported they get less shares with cgminer.
For proof, go into findnonce.c and in the precalc function add
Code:
printf("nbits %d", blk->nbits); I'd categorize this as a serious flaw. Miners still submitted work, but far less than usual. In the long run, people earned waay less than they should have.
P.S
Conman is aware of this, however is reluctant to fix it. The excuse was "It sends shares, doesn't it?"
July 20, 2011, 03:40:21 AM
I have never been able to get this miner working, added the -D flag to show results before windows error saying it has stopped working....
Any Suggestions?
Code:
C:\Users\xxxxx\Desktop\cgm>cgminer -o http://mineco.in:3000 -u xxxxx -p
xxxxxx -I 8 -D
[2011-07-20 16:35:47] X-Roll-Ntime found
[2[2011-07-20 16:35:47] Successfully retreived and deciphered work from pool 0 h
ttp://mineco.in:3000
[2011-07-20 16:35:47] Pool 0 http://mineco.in:3000 active 011-07
-20 16:35:4
[2011-07-20 16:35:47] Init GPU thread 0 7]
[2011-07-20 16:35:47] List of devices:
[2011-07-20 16:35:47] 0 Cayman Long-po
[2011-07-20 16:3l5:47] 1 Cayman
[2011-07-20 16:35:47] 2 Cayman
[20lin11-07-20 16:35:47] 3 Cayman
[2011g activated for ht-07-20 16:35:47] 4 Cayman
[2011-07-20 16:35:47] 5 Cayman
[2011-07-20 16:3tp://mineco.in:305:47] Selected 0: Cayman
[2011-07-20 16:35:47] Preferred 0vector width reported 4
[2011-07-20 16:35:47] Max work gr0oup size reported /LP
256
[2011-07-20 16:35:47] No binary found, generating from source
[2011-07-20 16:35:47] Patched source to suit 2 vectors
[2011-07-20 16:35:47] cl_amd_media_ops found, patched source with BITALIGN
[2011-07-20 16:35:47] cl_amd_media_ops found, patched source with BFI_INT
[2011-07-20 16:35:48] binary size 0 : 0
C:\Users\xxxxx\Desktop\cgm>
Any Suggestions?
July 20, 2011, 03:20:56 AM
I donated .5 btc to one of the developers who hangs out in ozcoin... great app
thanks
thanks
July 20, 2011, 03:17:56 AM
The CPU will NOT be the limiting factor if he's on linux. If on Windows, yeah, sucks to have that single-core semprom.
July 20, 2011, 02:17:12 AM
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]
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]
Your CPU might be the limiting factor. Take out the card that is performing as it should and see if the second card performs normally or not. If not, try installing that GPU where the one that was performing normally was. If it performs as it should, then that card is being installed into a lower bandwidth PCI-E slot (not all full length slots are 16x wired, check your motherboard manual). If it still does not perform as it should then you may have a defective card.
Edit: Power supply could also be an issue, what brand/model and how many watts?
Hope this helps.
July 20, 2011, 02:12:09 AM
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
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
July 20, 2011, 01:57:46 AM
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.
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.
July 20, 2011, 12:52:17 AM
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:
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.
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.
July 19, 2011, 11:22:17 PM
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 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.
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
--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.
July 19, 2011, 10:23:05 PM
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:
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
July 19, 2011, 10:09:16 PM
[note: url must come before username/password now]
Just downloaded the 1.30 tarball, and now I can't solo mine:
Where's the confusion?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
DOH! That'll teach me to not read the README.
July 19, 2011, 09:57:04 PM
[note: url must come before username/password now]
Just downloaded the 1.30 tarball, and now I can't solo mine:
Where's the confusion? 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
July 19, 2011, 09:51:10 PM
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
July 19, 2011, 07:25:11 PM
thanks.. ill script it.
July 19, 2011, 07:19:23 PM
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.
July 19, 2011, 07:06:00 PM
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.
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.
July 19, 2011, 06:53:37 PM
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.).
July 19, 2011, 03:59:22 PM
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.
July 19, 2011, 03:49:12 PM
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]
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]
Jump to: