kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 09, 2013, 01:47:15 PM Last edit: July 09, 2013, 02:33:02 PM by kano |
|
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig (Seems everything works fine on Fedora18 and Xubu 11.04 ...) Edit: 3.26% CPU (1200MHz down clocked i3 540)
|
|
|
|
bitbryan
|
|
July 09, 2013, 01:54:24 PM |
|
i want to say thank you so much for this thread! :-) its very easy to understand!Q
|
"Life is a waterfall, we drink from the river then turn around and put up our walls"
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 09, 2013, 02:08:33 PM |
|
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://bitcointalk.org/index.php?topic=78031.0In 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 Close enough.
|
|
|
|
turtle83
|
|
July 09, 2013, 03:08:04 PM |
|
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig (Seems everything works fine on Fedora18 and Xubu 11.04 ...) http://198.245.60.111/Pix/20130709Rig.pngEdit: 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 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.
|
|
|
|
flyonwall
Full Member
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
|
July 09, 2013, 03:29:40 PM Last edit: July 09, 2013, 03:42:56 PM by flyonwall |
|
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.
|
|
|
|
twmz
|
|
July 09, 2013, 03:53:39 PM |
|
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.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
os2sam
Legendary
Offline
Activity: 3586
Merit: 1098
Think for yourself
|
|
July 09, 2013, 04:06:33 PM |
|
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
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
salfter
|
|
July 09, 2013, 05:10:45 PM |
|
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: 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: [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.
|
|
|
|
os2sam
Legendary
Offline
Activity: 3586
Merit: 1098
Think for yourself
|
|
July 09, 2013, 05:27:20 PM |
|
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: 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: [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
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4298
Merit: 1645
Ruu \o/
|
|
July 09, 2013, 05:42:38 PM |
|
--device is a very coarse tool designed for GPU rigs predominantly. Use --usb for pretty much everything else.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
July 09, 2013, 05:45:34 PM |
|
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.
|
|
|
|
twmz
|
|
July 09, 2013, 06:22:14 PM |
|
"--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).
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
flyonwall
Full Member
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
|
July 09, 2013, 07:32:25 PM |
|
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?
|
|
|
|
MineForeman.com
Legendary
Offline
Activity: 896
Merit: 1000
|
|
July 09, 2013, 07:37:19 PM |
|
While trying to sort out the RPi USB1.1 problems I decided to (finally) try everything on my Xubu 11.04 rig (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
|
|
|
|
salfter
|
|
July 09, 2013, 08:12:50 PM |
|
"--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.
|
|
|
|
os2sam
Legendary
Offline
Activity: 3586
Merit: 1098
Think for yourself
|
|
July 09, 2013, 08:25:34 PM |
|
"--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. I was using the Bus:Device at first too. But on reboot those assignments can change so switched my methodology to --usb ICA:3 for each instance. That way it doesn't matter which device it actually uses just grabs the first 3 available. Also you would use --usb BAS:1 in case you missed the posts correcting my mistake. Any way you want to do it, it does work great. Also the options are explained in the readme.txt under advanced usb options. Sam
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
twmz
|
|
July 09, 2013, 09:08:54 PM |
|
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?
Please read the README Search it for '--usb'
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
GrapeApe
|
|
July 09, 2013, 09:32:51 PM Last edit: July 09, 2013, 10:36:04 PM by GrapeApe |
|
I just got my second 7770 and I can't get cgminer to recognize it. I'll be honest I have no idea what I'm doing here. I am new to linux Ubuntu 12.04. It was dumb luck getting everything to work to begin with because of fgrlx driver corruption issues when installing thru the system settings on Ubuntu and being forced to update the driver thru the terminal.Do I need to put a dummy plug in the card? I'm sure I need to tell linux I put in a second card but I have no idea where to start.
Edit: I got cgminer to recognize the card but now the 2 cards are hashing at the speed of 1 card (half speed). Everything on my display monitor is doubled up as well 2 clocks 2 everything. Does this mean I need a dummy plug?
|
|
|
|
flyonwall
Full Member
Offline
Activity: 250
Merit: 100
RockStable Token Inc
|
|
July 10, 2013, 01:28:41 AM |
|
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. Thanks! I will give that a try.
|
|
|
|
GrapeApe
|
|
July 10, 2013, 01:35:35 AM Last edit: July 10, 2013, 10:21:45 PM by GrapeApe |
|
Alright so I have solved the double gnome panels I mentioned above. Cgminer sees my second gpu but the 2 together hash at the same rate as one. When I disable the 2nd card the 1st card immediately speeds up to normal speed. Also I'm not able to adjust anything on second card. Engine clock speed and memory are stuck at 300. I could adjust the intensity on it. I've removed the card for now and I am just hashing on the original. Some help here would be appreciated.
edit: when I enter this command I get the double gnome panels. Which I can fix mow.
sudo aticonfig --adapter=all --initial
I then reboot and check to see if both cards are there.
sudo aticonfig --adapter=all --odgt Ubuntu can see both of them and the temps.
I then check to see if cgminer detects both cards ./cgminer -n and it does with no errors. I run cgminer and it splits the normal hash rate of 1 card between the 2. 110 MH/s on each card. When I disable the 2nd card the hash rate on the first goes up to normal 220MH/s... I've seen this talked about in other threads but no solution.
|
|
|
|
|