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

[kripz]

I better check that then, aticonfig i assume.

Had a good idea last night, will attempt to write a quick bashscript to tell cgminer to mine 1000 shares and then get the script to log the final output to a file and repeat with different settings.

pseudocode:

Code:

Array speedstoTest = 0,100,150,200,250,300,350

for i = 0; i < speedstoTest.length; i++
{
if(speedstoTest[i] == 0)
       // run normal cgminer no downclocks
else
       cgminer -m `speedstoTest[i]` --shares 1000 > log
}

[-ck]

I better check that then, aticonfig i assume.

This is why cgminer reports back the actual speeds to you after you set them on the fly in the menu, as the driver can lie, saying it set the speed fine but the card just refuses it.

[mmortal03]

I'd compare the differences in wattage at those different memory clock speeds. It might still net you more bitcoins to run the memory clock as low as possible, after accounting for electricity costs.

Not sure if you're interpreting the graph correctly. The point of my post is that according to the graph, if you have the mem clocks at 300 (which most miners do), it's best to run VECTORS2 with worksize of 128 or 256 (depending on the bus width of your graphics card).

Right, what I'm saying is supplemental to that -- a third factor if you will. What I'm saying is that even though you might get slightly higher hash rates at, say 300 with that worksize as a sweet spot, that depending on your electricity costs, you might benefit more from setting the memory clock as low as it will go, say to 150, even though your hash rate will drop slightly.

[kripz]

Well cgminer is reporting 128mhz

Updated above post with 12hour report, seems 128mhz has no effect on utility or hash rates. I'll have to do a proper test on my single card machine as the one below puts out too much heat and is constantly throttled.

Code:

cgminer version 2.0.3 - Started: [2011-09-19 23:58:37]
--------------------------------------------------------------------------------
 (5s):1287.1 (avg):1278.0 Mh/s | Q:6109  A:11210  R:29  HW:0  E:183%  U:17.54/m
 TQ: 8  ST: 9  SS: 0  DW: 424  NB: 58  LW: 29525  GF: 0  RF: 0  I: 8
 Connected to http://us.eclipsemc.com:8337 with LP as user kripz_miner
 Block: 000008663d81f4c02b0623cc45a8a72b...  Started: [10:07:52]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management ettings [D]isplay options [Q]uit
 GPU 0: 65.0C 2969RPM | 338.6/339.0Mh/s | A:2981 R:6 HW:0 U:4.66/m
 GPU 1: 87.0C 3083RPM | 299.2/296.0Mh/s | A:2546 R:12 HW:0 U:3.98/m
 GPU 2: 72.0C 2999RPM | 340.4/340.3Mh/s | A:3067 R:9 HW:0 U:4.80/m
 GPU 3: 87.0C 3164RPM | 305.7/302.8Mh/s | A:2617 R:2 HW:0 U:4.09/m
--------------------------------------------------------------------------------

Right, what I'm saying is supplemental to that -- a third factor if you will. What I'm saying is that even though you might get slightly higher hash rates at, say 300 with that worksize as a sweet spot, that depending on your electricity costs, you might benefit more from setting the memory clock as low as it will go, say to 150, even though your hash rate will drop slightly.

I see, but it's probably more beneficial to play with volts and the core for that. I dont think memory clocks use a big amount of power.

[kripz]

But going 300 to 150 is arguably negligible. I saved 2w according to my meter. Until i get my script written when i get home i wouldn't bother with it, not worth the time imo.

[kano]

Also note that testing how long it will take using a Share count is not consistent.
On the same setup, 1000 Shares can take varying amounts of time.
A share is random, just like a block (it is a difficulty "1" block)
Utility will vary also.
Only the actual average hash rate should be somewhat consistent.

[kripz]

Something like this then?

Code:

#!/bin/bash
cd ~/cgminer
DISPLAY=:0 ./cgminer -c p1.json -c p2.json & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 300 & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 250 & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 200 & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 150 & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 100 & 2>> log
sleep 1h
killall cgminer

DISPLAY=:0 ./cgminer -c p1.json -c p2.json --gpu-memclock 50 & 2>> log
sleep 1h
killall cgminer

Though not sure what 2> will actually log. I would prefer to only capture the final summarized output.

[Sekioh]

Don't know the *nix equivalent for a bash loop would be, but seems really inefficient to copy-paste the setup over and over, and even then after what 6-8hrs it'd never restart again? I'd think something like

Code:

:myloop

DISPLAY=:0 ./cgminer -c p1.json -c p2.json & 2>> log
sleep 1h
killall cgminer

goto myloop

would be wayyyy better and shorter code :]

[kripz]

I realised you dont need anything fancy just to test 5 different memory speeds, cut and paste is sufficient.

Short/long neat/messy efficient or not doesnt matter for this test, it's a once off thing.

[BadPenny]

Stupid Question:
I have an HD6850 running by itself.  If I add a second card, say an HD6750, and fire CGMiner back up, will it detect both cards, or do I need to add something to the .bat file?  I am using Catalyst 11.8 drivers.

[os2sam]

Stupid Question:
I have an HD6850 running by itself.  If I add a second card, say an HD6750, and fire CGMiner back up, will it detect both cards, or do I need to add something to the .bat file?  I am using Catalyst 11.8 drivers.

When I added my second card, a 5770, the Catalyst drivers picked it up automatically.

I had to use a dummy plug to simulate a monitor and extend the screen to use it since I was using Win7 and older Catalyst drivers.

But yes the miner saw it and started using it automatically.
Sam

[cablepair]

I thought for the heck of it I would have my bitcoin wallet accept connections and then set it up as solo mining and only use it as my failover. the idea is cgminer would slip it a few shares every now and then and maybe some day I would get lucky and hit the jackpot (im a gambling man)

I managed to get cgminer to connect to my bitcoin wallet but it says REJECTED for every single share in cgminer

any ideas folks?

thanks

[DBordello]

When solo mining, all shares are rejected, except when you solve a block.  This is normal.

[cablepair]

ahh I did not know that. Thank you! Now I feel like an idiot!
nhehehe thanks again.

[runeks]

I can't get cgminer to work from within Linuxcoin. I get the following message when I try to run it:

Code:

user@linuxcoin:~/Desktop/cgminer-2.0.3$ cgminer --ndevs
[2011-09-21 01:20:58] Error: Getting Device IDs (num)                    
[2011-09-21 01:20:58] clDevicesNum returned error, none usable                    
0 GPU devices detected

Phoenix miner detects my GPU and can mine without problems:

Code:

[21/09/2011 01:15:20] Phoenix r116 starting...
[21/09/2011 01:15:20] Connected to server
[21/09/2011 01:15:44] Result: 12c54cbf accepted         
[21/09/2011 01:15:49] Result: bb7dccd0 accepted         
[21/09/2011 01:16:52] Result: 1f03481a accepted         
[21/09/2011 01:16:53] Result: a388f657 accepted         
[21/09/2011 01:16:53] Result: 1c510d1c accepted                 
[217.05 Mhash/sec] [20 Accepted] [0 Rejected] [RPC (+LP)]

This is what aticonfig has to say:

Code:

user@linuxcoin:~/Desktop/cgminer-2.0.3$ DISPLAY=:0 sudo aticonfig --list-adapters
* 0. 01:00.0 ATI Radeon HD 5700 Series

* - Default adapter

Any ideas on what could be wrong?

[kripz]

DISPLAY=:0 cgminer --ndevs

[indolering]

I am trying to use the config file, but ran into 3 config switches which refuse to work.

All of the following auto-fan/gpu permutations fail:

Code:

"auto-fan" : "true",

Code:

"auto-fan" : "1",

Code:

"auto-fan" : "",

Trying to select for a single device is troublesome:

Code:

"device" : "1",

Results in GPU 0 and 2 being disabled.

Code:

"device" : "2",

Results in GPU 0 and 1 being disabled.

Code:

"device" : "2",
"device" : "1",

Results in GPU 0 and 1 being disabled.

Can you clarify the syntax for these commands?

Also, can you query for what the automatically detected values for vectors and worksize?

[kripz]

You cannot query it inside cgminer AFAIK, ls *.bin and the bin file well indicate what it's running.

[runeks]

DISPLAY=:0 cgminer --ndevs

Thanks! That did the trick.

[kano]

Just a little aside information that some may not realise ...

The value shown after Accept/Reject in the cgminer log is the hex nonce.

If you get a block (pool or solo), then the nonce in the block will match that value exactly.
(this is firstly based on reading the code and working out where the value comes from, and secondly looking at my one and only pool block I have and seeing that it does match as expected)

This means that anyone wondering if they can tell if they got a particular block, they can with reasonable certainty by comparing the block nonce with the log nonce (and of course there should be a LONGPOLL for the block almost straight after it in the log)
Of course it isn't 100% guaranteed since the nonce value is not unique per share, but if it is roughly at the same time as the block and a LONGPOLL shows just after it - it's extremely likely to be the block.

... and another side
My latest pull request makes it show 3/8 of the actual hash rather than the nonce and also says " BLOCK!" after it if it is a valid block difficulty share
(which also may cause some distress if anyone ever actually gets a Rejected block in the log ...)
If you want that branch change before it gets into the main code it's available in my kano branch here:
https://github.com/kanoi/cgminer/tree/kano (main.c, util.c and miner.h)
N.B. that difficulty test code is my original in case anyone wonders where it came from