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

[narousberg]

Have you tried to plug the 5th board on the computer by itself and start cgminer to see if it works?

yes, all boards work perfekt. I have tested with diferent boards
I have tried with 3 and less boards and used --hotplug 5 option, but hotpluging function dont work absolutly.
only max 4 boards in a time accept cgminer.(((

[jesse11]

You should buy a BeagleBone Black A5 DevKit here http://www.amazon.com/gp/product/B00CUP7VWI/ref=pd_lpo_k2_dp_sr_1/175-6597021-3541669?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=lpo-top-stripe-1&pf_rd_r=1GYTEC46C84NSC2J0S4H&pf_rd_t=201&pf_rd_p=1535523722&pf_rd_i=B00CHYOLHK and set it up for extra miners. The BeagleBone Black is like a mini computer and will run Linux 

[EvgenijM86]

Hello, I wanted to ask cgminer community about "efficiency" parameter. For example: if I have efficiency = 8%, then does this mean that I can potentially find 92%/8% = 11.5 more shares in the same time-frame with proper pool and miner settings? Personally I think this parameter is rather useless, because even if I change share because of new blocks, then probability of finding this new share would either:
1) not change much (if cgminer remembers what hashes he previously computed for previous share).
2) not change at all (if cgminer computation is totally random).

But my friend thinks that we should reduce share difficulty of our pool, so that computations of shares almost never interrupted.


Note: Efficiency parameter is located in pool management [p] -> Information .

[dermo]

maybe that can help I'm not sur what your are talking about
I'm using 1 AMD 7950 @ 1150/1500
Diff is set to "256" by the pool

Pool: http://ltcmine.ru:3333
Does not have own long-poll support
 Queued work requests: 942
 Share submissions: 1558
 Accepted shares: 1524
 Rejected shares: 34
 Accepted difficulty shares: 397358
 Rejected difficulty shares: 8867
 Reject ratio: 2.2%
 Efficiency (accepted / queued): 162%
 Discarded work due to new blocks: 1740
 Stale submissions discarded due to new blocks: 0
 Unable to get work from server occasions: 12
 Submitting work remotely delay occasions: 0

cgminer config file

"intensity" : "20",
"vectors" : "1",
"worksize" : "256",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "24000",
"shaders" : "1792",
"gpu-engine" : "0",
"gpu-fan" : "0-0",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"scrypt" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"

[-ck]

Hello, I wanted to ask cgminer community about "efficiency" parameter. For example: if I have efficiency = 8%, then does this mean that I can potentially find 92%/8% = 11.5 more shares in the same time-frame with proper pool and miner settings? Personally I think this parameter is rather useless, because even if I change share because of new blocks, then probability of finding this new share would either:
1) not change much (if cgminer remembers what hashes he previously computed for previous share).
2) not change at all (if cgminer computation is totally random).

But my friend thinks that we should reduce share difficulty of our pool, so that computations of shares almost never interrupted.


Note: Efficiency parameter is located in pool management [p] -> Information .

Efficiency means nothing any more. It was a metric from the days when getwork was used for providing work and means nothing in the stratum world. I will make sure to get rid of it from the pool information.

[BittBurger]

I've been mining for 12 hours and this is all i see on my CGMiner display for P2Pool ...


GPU: 0   10.75M/11.17Mh/s

Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 detected new block
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart
Stratum from pool 0 detected new block
Stratum from pool 0 requested work restart
Stratum from pool 0 requested work restart

I have no new litecoins in my wallet yet.  Is this thing working correctly?  Am I Mining?

Thanks

[Trongersoll]

I just installed cgminer on a little eeePC netbook because I got a new Erupter and my USB hub for my regular miner hasn't come yet. I must say that once i read the right READMEs the install went pretty quick. i had to get 7zip and that zadig program, but it all worked well. Normally, i only use this machine to browse and read books. now it is hashing too(temporarily).


Thanks guys for a great mining program.

[salfter]

I've been mining for 12 hours and this is all i see on my CGMiner display for P2Pool ...

GPU: 0   10.75M/11.17Mh/s

Stratum from pool 0 requested work restart
[snipped]

I have no new litecoins in my wallet yet.  Is this thing working correctly?  Am I Mining?

That seems awfully high for scrypt mining on a single GPU. For comparison, my 6870 does about 310 kH/s; the rate you're quoting is nearly two orders of magnitude faster. Are you sure you're actually using scrypt, or are you attempting to use sha256d on Litecoin P2Pool?

[Roy Badami]

I just installed cgminer on a little eeePC netbook

Hey, I run cgminer on an original EEEPC 701 running Ubuntu.  Works just fine...

roy

[Trongersoll]

I just installed cgminer on a little eeePC netbook

Hey, I run cgminer on an original EEEPC 701 running Ubuntu.  Works just fine...

roy

I'm running XP. seems to be working well.

[ChipGeek]

I'm cannot get my new BFL ASIC running on my RPi using cgminer 3.1.1.  It has been hashing fine with my BFL FPGA up to now (and it still works if I plug back it in). 

I tried these commands from the ASIC-README.  The second command was not required (it said the group already existed).

Code:

 sudo usermod -G plugdev -a `whoami`

 sudo groupadd plugdev

 sudo cp /usr/src/cgminer/01-cgminer.rules /etc/udev/rules.d/

Code:

 [2013-06-13 16:52:30] Started cgminer 3.1.1
 [2013-06-13 16:52:30] No devices detected!
 [2013-06-13 16:52:30] Waiting for USB hotplug devices or press q to quit
 [2013-06-13 16:52:30] Probing for an alive pool

I'm running in the default "pi" account.  Can someone please give me some guidance where to look or what to do next?  Thanks. 

[turtle83]

I'm cannot get my new BFL ASIC running on my RPi using cgminer 3.1.1.  It has been hashing fine with my BFL FPGA up to now (and it still works if I plug back it in).  

I tried these commands from the ASIC-README.  The second command was not required (it said the group already existed).

Code:

 sudo usermod -G plugdev -a `whoami`

 sudo groupadd plugdev

 sudo cp /usr/src/cgminer/01-cgminer.rules /etc/udev/rules.d/

Code:

 [2013-06-13 16:52:30] Started cgminer 3.1.1
 [2013-06-13 16:52:30] No devices detected!
 [2013-06-13 16:52:30] Waiting for USB hotplug devices or press q to quit
 [2013-06-13 16:52:30] Probing for an alive pool

I'm running in the default "pi" account.  Can someone please give me some guidance where to look or what to do next?  Thanks.  

you need to restart udev after u added the rules for it to see it. hell just restart the pi for good measure.

does lsusb see the asic?
anything funky in dmesg|tail ?

first see if cgminer sees the new device with sudo . if sudo also doesnt work, then its not permission issue, something different.

[ChipGeek]

you need to restart udev after u added the rules for it to see it. hell just restart the pi for good measure.

does lsusb see the asic?
anything funky in dmesg|tail ?

first see if cgminer sees the new device with sudo . if sudo also doesnt work, then its not permission issue, something different.

Sorry - linux noob here.  Thanks for your help.  I did restart the pi - twice.   My cgminer command line starts with:

Code:

sudo /usr/src/cgminer/cgminer -o http://...

Code:

pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 005: ID 0d3d:0001 Tangtop Technology Co., Ltd HID Keyboard
pi@raspberrypi ~ $ dmesg | tail
[   11.224838] bcm2835 ALSA chip created!
[   11.242032] bcm2835 ALSA chip created!
[   11.258035] bcm2835 ALSA chip created!
[   11.272962] bcm2835 ALSA chip created!
[   11.288352] bcm2835 ALSA chip created!
[   11.304921] bcm2835 ALSA chip created!
[   15.854575] mmc0: missed completion of cmd 18 DMA (512/512 [1]/[1]) - ignoring it
[   15.869959] mmc0: DMA IRQ 6 ignored - results were reset
[   19.843212] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   24.073821] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SS
pi@raspberrypi ~ $ 

[turtle83]

you need to restart udev after u added the rules for it to see it. hell just restart the pi for good measure.

does lsusb see the asic?
anything funky in dmesg|tail ?

first see if cgminer sees the new device with sudo . if sudo also doesnt work, then its not permission issue, something different.

Sorry - linux noob here.  Thanks for your help.  I did restart the pi - twice.   My cgminer command line starts with:

Code:

sudo /usr/src/cgminer/cgminer -o http://...

Code:

pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 005: ID 0d3d:0001 Tangtop Technology Co., Ltd HID Keyboard
pi@raspberrypi ~ $ dmesg | tail
[   11.224838] bcm2835 ALSA chip created!
[   11.242032] bcm2835 ALSA chip created!
[   11.258035] bcm2835 ALSA chip created!
[   11.272962] bcm2835 ALSA chip created!
[   11.288352] bcm2835 ALSA chip created!
[   11.304921] bcm2835 ALSA chip created!
[   15.854575] mmc0: missed completion of cmd 18 DMA (512/512 [1]/[1]) - ignoring it
[   15.869959] mmc0: DMA IRQ 6 ignored - results were reset
[   19.843212] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[   24.073821] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SS
pi@raspberrypi ~ $ 

Well since you tried with sudo, means its not the udev things. sudo has access to everything.
0403:6014 is the BFL ... so it is being seen by the system all right. Probably something with cgminer... I dont have a BFL so cant help beyond this...

[ChipGeek]

Well since you tried with sudo, means its not the udev things. sudo has access to everything.
0403:6014 is the BFL ... so it is being seen by the system all right. Probably something with cgminer... I dont have a BFL so cant help beyond this...

Thank you.  I'm going to try on Windows next - just to make sure the hardware is working.  Of course I've now hit the USB thing that I need zadig for.  Off to read more ASIC-README and do what it says...

[ChipGeek]

Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver.  When I start cgminer, I get this:

Code:

 cgminer version 3.1.1 - Started: [2013-06-13 18:19:39]
--------------------------------------------------------------------------------
 (5s):55.66M (avg):58.84Mh/s | A:0  R:0  HW:0  U:0.0/m  WU:0.0/m
 ST: 2  SS: 0  NB: 1  LW: 7  GF: 0  RF: 0
 Connected to us1.eclipsemc.com diff 1 with stratum as user [username]
 Block: 00f6d64abcfaeb79...  Diff:15.6M  Started: [18:19:39]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:                | 58.54M/61.84Mh/s | A:0 R:0 HW:0 U:0.00/m I: 3
--------------------------------------------------------------------------------

 [2013-06-13 18:19:38] Started cgminer 3.1.1
 [2013-06-13 18:19:38] BitForceSC detect (1:10) get details returned nothing (0:0)
 [2013-06-13 18:19:38] Probing for an alive pool
 [2013-06-13 18:19:39] Disabling extra threads due to dynamic mode.
 [2013-06-13 18:19:39] Tune dynamic intensity with --gpu-dyninterval
 [2013-06-13 18:19:39] Network diff set to 15.6M
 [2013-06-13 18:19:40] Thread 1 being disabled
 [2013-06-13 18:19:45] BitForceSC detect (1:10) get details return invalid/timed out (0:-7)
 [2013-06-13 18:19:51] BitForceSC detect (1:10) get details return invalid/timed out (0:-7)
 [2013-06-13 18:19:56] BitForceSC detect (1:10) get details return invalid/timed out (0:-7)

[-ck]

Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver.  When I start cgminer, I get this:
snip

Yes it's a known about problem with slower USB/timeouts on some of the devices. There is a fix for this in the master git development tree, but no official release with it yet unfortunately. Hopefully soon...

[dentldir]

And if you are NOT having problems with 3.2.1 on RPi, could you tell me your kernel version?

I'm running cgminer 3.2.1 on an RPi with 4 Erupters and a Jalapeno with no problems.

Linux minepeon 3.6.11-11-ARCH+ #1 PREEMPT Tue May 14 16:12:58 UTC 2013 armv6l GNU/Linux

The only change I made was taking the 200ms timeout up to 999ms as a temporary workaround to get the Jalapeno to talk.  The erupters worked right out of the box.  Hot plug and all.

Cheers and thanks for all the work.

[ChipGeek]

Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver.  When I start cgminer, I get this:
snip

Yes it's a known about problem with slower USB/timeouts on some of the devices. There is a fix for this in the master git development tree, but no official release with it yet unfortunately. Hopefully soon...

So is it the same issue in linux on my RPi or is the above a Windows only thing? 
If Windows only could you please look back a few replies?
In the short term, I guess I'll try BFL's Easyminer.

[-ck]

Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver.  When I start cgminer, I get this:
snip

Yes it's a known about problem with slower USB/timeouts on some of the devices. There is a fix for this in the master git development tree, but no official release with it yet unfortunately. Hopefully soon...

So is it the same issue in linux on my RPi or is the above a Windows only thing? 
If Windows only could you please look back a few replies?
In the short term, I guess I'll try BFL's Easyminer.

Some BFL devices have a slow-initialisation problem which will happen on any OS. The RPi seems to be bitten by something else as well. We're still investigation though we think we've instrumented the problem at least.