Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 278. (Read 5805537 times)

hero member
Activity: 651
Merit: 501
My PGP Key: 92C7689C
"--usb bfl:1" is for the old FPGA Singles. For Jalapenos, you want "--usb baj:1".

I run two instances of CGMiner on one computer, where --usb bfl:1 points my FPGA to one pool, and another instnace with --usb bas:1 points my Single at another pool.

Actually, all BFL SC devices (jalanpenos, singles, etc) are "--usb bas:#".  It's based on the driver (bas for the new sc driver, bfl for the old fpga driver).

I found that this worked, with the device index starting at 1.  Also, --usb x:y works, with x and y being the bus and device numbers for the miner as reported by lsusb.

Now I can have my mining split between pools...just need for P2Pool to switch over to v13 now.
legendary
Activity: 896
Merit: 1000
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig Smiley
(Seems everything works fine on Fedora18 and Xubu 11.04 ...)

You should also try Arch on your RPi, I have been running it for months (along with hundreds of MinePeon users) without issues.

Neil
full member
Activity: 250
Merit: 100
RockStable Token Inc
Cool! So can one instance of cgminer use a particular hashing unit (or several hashing units) in an Avalon system? What would be the command line for doing this?
hero member
Activity: 737
Merit: 500
"--usb bfl:1" is for the old FPGA Singles. For Jalapenos, you want "--usb baj:1".

I run two instances of CGMiner on one computer, where --usb bfl:1 points my FPGA to one pool, and another instnace with --usb bas:1 points my Single at another pool.

Actually, all BFL SC devices (jalanpenos, singles, etc) are "--usb bas:#".  It's based on the driver (bas for the new sc driver, bfl for the old fpga driver).
legendary
Activity: 952
Merit: 1000
How difficult would it be to allow several instances of cgminer in the same system?
Easy, I run 3 to 5 instances with 3.3.1
I'm trying to run one instance on each of my Jalapeños so I can have one mine on BTCGuild and the other on P2Pool.  I'm trying to use something like this to launch two instances of cgminer:
It says both are in use, even though only one is actually in use.
Just use --usb bfl:1 for each instance
"--usb bfl:1" is for the old FPGA Singles. For Jalapenos, you want "--usb baj:1".

I run two instances of CGMiner on one computer, where --usb bfl:1 points my FPGA to one pool, and another instnace with --usb bas:1 points my Single at another pool.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
--device is a very coarse tool designed for GPU rigs predominantly. Use --usb for pretty much everything else.
legendary
Activity: 3583
Merit: 1094
Think for yourself
How difficult would it be to allow several instances of cgminer in the same system?

Easy, I run 3 to 5 instances with 3.3.1

I'm trying to run one instance on each of my Jalapeños so I can have one mine on BTCGuild and the other on P2Pool.  I'm trying to use something like this to launch two instances of cgminer:

Code:
screen -dmS miner_0  cgminer --api-listen --api-allow W:127.0.0.1 --api-port 4028 --device 0 --remove-disabled --url stratum+tcp://stratum.btcguild.com:3333 --user ____ --pass ____
screen -dmS miner_1  cgminer --api-listen --api-allow W:127.0.0.1 --api-port 4029 --device 1 --remove-disabled --url stratum+tcp://salfter.gotdns.org:9332 --user ____ --pass ____

The first one starts properly and runs on just one Jalapeño, but the other doesn't. Removing the screen invocation and adding --text-only produces this:

Code:
 [2013-07-09 10:02:34] Started cgminer 3.3.1
 [2013-07-09 10:02:34] Loaded configuration file /home/salfter/.cgminer/cgminer.conf
 [2013-07-09 10:02:34] SEM: BitForceSC USB failed to get (1409024) '/tmp/cgminer-usb-1-6' - device in use
 [2013-07-09 10:02:34] SEM: BitForceSC USB failed to get (1441793) '/tmp/cgminer-usb-1-5' - device in use
 [2013-07-09 10:02:34] Command line options set a device that doesn't exist   

It says both are in use, even though only one is actually in use.

Just use --usb bfl:1 for each instance
hero member
Activity: 651
Merit: 501
My PGP Key: 92C7689C
How difficult would it be to allow several instances of cgminer in the same system?

Easy, I run 3 to 5 instances with 3.3.1

I'm trying to run one instance on each of my Jalapeños so I can have one mine on BTCGuild and the other on P2Pool.  I'm trying to use something like this to launch two instances of cgminer:

Code:
screen -dmS miner_0  cgminer --api-listen --api-allow W:127.0.0.1 --api-port 4028 --device 0 --remove-disabled --url stratum+tcp://stratum.btcguild.com:3333 --user ____ --pass ____
screen -dmS miner_1  cgminer --api-listen --api-allow W:127.0.0.1 --api-port 4029 --device 1 --remove-disabled --url stratum+tcp://salfter.gotdns.org:9332 --user ____ --pass ____

The first one starts properly and runs on just one Jalapeño, but the other doesn't. Removing the screen invocation and adding --text-only produces this:

Code:
 [2013-07-09 10:02:34] Started cgminer 3.3.1
 [2013-07-09 10:02:34] Loaded configuration file /home/salfter/.cgminer/cgminer.conf
 [2013-07-09 10:02:34] SEM: BitForceSC USB failed to get (1409024) '/tmp/cgminer-usb-1-6' - device in use
 [2013-07-09 10:02:34] SEM: BitForceSC USB failed to get (1441793) '/tmp/cgminer-usb-1-5' - device in use
 [2013-07-09 10:02:34] Command line options set a device that doesn't exist   

It says both are in use, even though only one is actually in use.
legendary
Activity: 3583
Merit: 1094
Think for yourself
How difficult would it be to allow several instances of cgminer in the same system?

Easy, I run 3 to 5 instances with 3.3.1
hero member
Activity: 737
Merit: 500
How difficult would it be to allow several instances of cgminer in the same system?

Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of cgminer on the same box where other users are running their own instance of cgminer. Each cgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow cgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively.

Each cgminer instance should be separately addressable in the RPC protocol/API.

I believe this requires substantial code changes (may be changes to both cgminer itself and the Avalon drivers), so I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source.

Edit: Please PM me if you would be interested in implementing this project.

THis shouldn't require any code change at all.  I routinely run multiple instances of cgminer on my mining rigs.  One for GPUs, one for BFL FPGA devices, one for BFL SC devices, etc.  Each has an independent API endpoint.  You just have to start each version with command line parameters to make sure that it selects the correct devices (see the --usb parameter and the discussion of it in the READMEs) so that no two cgminer instances try to mine against the same devices.  You also want to specify a different API port for each instance. 
full member
Activity: 250
Merit: 100
RockStable Token Inc
How difficult would it be to allow several instances of cgminer in the same system?

Why would I want to do that? I am building a "Condo" system where miners are hosted in a remote location. I want to give each user full control of his mining unit, which may be only part of a boxed system. For example, an Avalon box can have as many as 4 hardware modules, and each module can have 8 hashing units. A user in the condo system can own as small as a single hashing unit, and I want her to be able to launch her own instance of cgminer on the same box where other users are running their own instance of cgminer. Each cgminer instance is associated with a user ID, and that user ID is in turn associated with particular hashing unit(s). The association of a user ID to hashing unit(s) is done by another subsystem, so all that really needs to happen is to allow cgminer to accept a command-line parameter that indicates which hashing unit(s) it will use exclusively.

Each cgminer instance should be separately addressable in the RPC protocol/API.

I believe this requires substantial code changes (may be changes to both cgminer itself and the Avalon drivers), so I will give a hashing unit in the condo I am building to whoever can get this done, and yes, it's OK for it to be open source.

Edit: Please PM me if you would be interested in implementing this project.
sr. member
Activity: 322
Merit: 250
Supersonic
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig Smiley
(Seems everything works fine on Fedora18 and Xubu 11.04 ...)
http://198.245.60.111/Pix/20130709Rig.png

Edit: 3.26% CPU (1200MHz down clocked i3 540)

I had issues getting rpi detect ztex thru my particular hubs (Belkin F4u022v). Worked after i added the following to /boot/cmdline.txt
Code:
dwc_otg.speed=1

I don't remember the exact errors i was seeing, but i recall it seeing some error code in dmesg when plugging in the ztex.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Quote
How can I do 75%/45 minutes pool 0 , 25%/15 minutes pool 1 , is that round robin.
You cannot.

That degree of control no one has been able to prove to me there are any circumstances that it serves any useful purpose, so I never bothered to implement such tight scheduling over pool share submission. Optimising your share submission to not lose work and/or sharing to minimise variance are all you need.

This would be the only real reason, I guess:

https://bitcointalksearch.org/topic/mine-in-multiple-pools-to-reduce-variance-78031

In other words, if you are mining at two pools and one is large and one is small, you actually might be increasing you variance (vs just mining at the large pool alone) if you mine at them 50/50.

But to be super useful, you'd want something like "BALANCE" combined with some API options to change the ratios on the fly so that some outside script could periodically use pool APIs to determine total hashrate and then use cgminer API to tweak the ratios appropriately.
Rough control could be done with:
... have 4 workers - 3 of them the same pool - 1 the other pool - and balance them Tongue
Close enough.
full member
Activity: 126
Merit: 100
i want to say thank you so much for this thread! :-) its very easy to understand!Q
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig Smiley
(Seems everything works fine on Fedora18 and Xubu 11.04 ...)


Edit: 3.26% CPU (1200MHz down clocked i3 540)
legendary
Activity: 1820
Merit: 1001
Hello ckolivas, I would like to know if and when you do another version to the Avalon firmware and cgminer would you able to update and have some remote control via connecting via other computers not on network like remote control assistance. Also the ability to control fan speed individually with maybe a auto option built in and a slider option to move up and down and speed goes up or down on the fly.

.m.
sr. member
Activity: 280
Merit: 260

compiling on fedora - if somebody is interested ...

yum -y install git gcc libcurl-devel  libusbx-devel # libusb-devel # wrapper only ?

git clone https://github.com/ckolivas/cgminer

export CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
make clean
make

-----
strange thing - it is usually much slower than java diabloMiner, I understand that GPU mining is over anyway - but if somebody has an idea ...

legendary
Activity: 1540
Merit: 1001
Those USB miners are really fast!!
...
M
Yes with 3.1.1 you need to tell it what they are.

If they are AMU then
 --icarus-timing 2.9761=100 --icarus-options 115200:1:1

If they are something else ... ?

They are USB block erupters.  Everything looks good for a while, and then suddenly a few of them start showing really high hash rates.

M
Yeah I saw that happen back with 3.1.1 but in my case it was disabling them and re-enabling them in the API that caused it.
I guess with 3.1.1 it can happen there also if the device gets SICK and then recovers.
Not sure how else it can happen.

Would you mind trying current git?
I can get current git to work on both USB2 and USB3 on my desktop without any problems,
Just on my RPi it still stalls on the AMU and ICA (but not BLT or BAJ - even in USB3 those 2 work on my RPi)

I'm a windows user.  Compiling isn't a small task for me.  Sorry, can't try git. Sad

M
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Those USB miners are really fast!!
...
M
Yes with 3.1.1 you need to tell it what they are.

If they are AMU then
 --icarus-timing 2.9761=100 --icarus-options 115200:1:1

If they are something else ... ?

They are USB block erupters.  Everything looks good for a while, and then suddenly a few of them start showing really high hash rates.

M
Yeah I saw that happen back with 3.1.1 but in my case it was disabling them and re-enabling them in the API that caused it.
I guess with 3.1.1 it can happen there also if the device gets SICK and then recovers.
Not sure how else it can happen.

Would you mind trying current git?
I can get current git to work on both USB2 and USB3 on my desktop without any problems,
Just on my RPi it still stalls on the AMU and ICA (but not BLT or BAJ - even in USB3 those 2 work on my RPi)
hero member
Activity: 574
Merit: 501
Those USB miners are really fast!!

Code:
cgminer version 3.1.1 - Started: [2013-07-07 10:50:53]
------------------------------------------------------------------------------
(5s):4.217G (avg):7.948Ph/s | A:11487  R:1355  HW:160  U:49.5/m  WU:56.1/m


M

Yes - an average of 7.948 Petahash/second.  You should be solo mining something like a block a second....
Jump to: