OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 277.

Krak

hero member

Activity: 591

Merit: 500

Quote from: GrapeApe on July 10, 2013, 05:35:54 PM

I find very telling that the only responses I got here were after I said I fixed it and to just talk shit, basically because I'm upset. Very helpful. How about pointing out some of those posts. No you just wait for a troll moment then pounce. THANK YOU
TROLLS
VERY HELPFUL

It's obnoxious having to help people who won't help themselves over and over.

GrapeApe

sr. member

Activity: 476

Merit: 250

I find very telling that the only responses I got here were after I said I fixed it and to just talk shit, basically because I'm upset. Very helpful. How about pointing out some of those posts. No you just wait for a troll moment then pounce. THANK YOU
~~TROLLS~~ I am shocked at how far this has gone. The community here has spoken and evidently I am the troll here so I stand corrected, you are all very helpful considerate people and I would like to thank all you for pointing out the readme to me.WOW I never thought of that. It was a power supply issue so this was no help whatsoever but I thank you again.
VERY HELPFUL

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

Quote from: GrapeApe on July 10, 2013, 03:17:12 PM

I just wanted to say that I have solved my issue of 2 cards hashing at same speed as one. I have no desire to share the solution on this thread. I love the miner and I thank the devs for all of their hard work but I got no help on this thread. If anyone is having issues with hash speed being cut in half after adding a second card they can pm me and I will be happy help. Thx CYA
GrapeApe

Damn those pesky readme files, ruining everyone's fun...... Wink

Krak

hero member

Activity: 591

Merit: 500

Quote from: GrapeApe on July 10, 2013, 03:17:12 PM

I just wanted to say that I have solved my issue of 2 cards hashing at same speed as one. I have no desire to share the solution on this thread. I love the miner and I thank the devs for all of their hard work but I got no help on this thread. If anyone is having issues with hash speed being cut in half after adding a second card they can pm me and I will be happy help. Thx CYA
GrapeApe

It's alright, that problem has been fixed many times in this thread already (I can recall at least 3 off the top of my head).

GrapeApe

sr. member

Activity: 476

Merit: 250

I just wanted to say that I have solved my issue of 2 cards hashing at same speed as one. I have no desire to share the solution on this thread. I love the miner and I thank the devs for all of their hard work but I got no help on this thread. If anyone is having issues with hash speed being cut in half after adding a second card they can pm me and I will be happy help. Thx CYA
GrapeApe

micalith

hero member

Activity: 894

Merit: 501

Quote from: crazyates on July 10, 2013, 12:27:00 PM

Quote from: micalith on July 10, 2013, 12:18:14 PM

very noobish question:

I'm load-balanced across three pools. I'm thinking of going for the one with the highest average yield, and hoping that the load-balanced setting is basically helping to show up which pools are better. Is using load-balance a reliable way of comparing pool efficiencies?

Not really. Balance or load-balance don't distribute the hashrate perfectly evenly over multiple pools. If it favors one pool over another, and sends more shares that way, you're going to think you're earning more with that pool, when the pools may end up being the same.

Whenever I've tried it, it's always given Ozcoin the short straw, submitting less shares to Ozcoin and giving more to the other pools. Idk why it happens like this, but it can make Ozcoin look less profitable, when it's really not.

Quote from: -ck on July 10, 2013, 12:25:50 PM

Efficiency means nothing in the stratum protocol era. Compare disconnects, GF and RF.

OK, so I'll set it to 'balance' for unbiased results.

GF and RF are 0 for about 36 hours of run time. I'll check those periodically

thanks

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: micalith on July 10, 2013, 12:18:14 PM

very noobish question:

I'm load-balanced across three pools. I'm thinking of going for the one with the highest average yield, and hoping that the load-balanced setting is basically helping to show up which pools are better. Is using load-balance a reliable way of comparing pool efficiencies?

Not really. Balance or load-balance don't distribute the hashrate perfectly evenly over multiple pools. If it favors one pool over another, and sends more shares that way, you're going to think you're earning more with that pool, when the pools may end up being the same.

Whenever I've tried it, it's always given Ozcoin the short straw, submitting less shares to Ozcoin and giving more to the other pools. Idk why it happens like this, but it can make Ozcoin look less profitable, when it's really not.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: micalith on July 10, 2013, 12:18:14 PM

very noobish question:

I'm load-balanced across three pools. I'm thinking of going for the one with the highest average yield, and hoping that the load-balanced setting is basically helping to show up which pools are better. Is using load-balance a reliable way of comparing pool efficiencies?

Efficiency means nothing in the stratum protocol era. Compare disconnects, GF and RF.

micalith

hero member

Activity: 894

Merit: 501

very noobish question:

I'm load-balanced across three pools. I'm thinking of going for the one with the highest average yield, and hoping that the load-balanced setting is basically helping to show up which pools are better. Is using load-balance a reliable way of comparing pool efficiencies?

SkyNet

member

Activity: 80

Merit: 10

Quote from: paladin281978 on July 10, 2013, 01:33:24 AM

Why decreased speed?
cgminer 3.2.1 - 645 kh
cgminer 3.3.1 - 605-610 kh

most likely you changed your settings there is no decrease in speed...

tom_o

sr. member

Activity: 308

Merit: 250

Just an idea which could be very useful over the summer, could temperature control by dynamic intensity be possible? I've had to reduce intensity from 20 to 16 to keep my 7970s under 86°C this last week due to the how hot it's been in the UK but they can run at 19 overnight fine cause it's quite a bit cooler.

paladin281978

hero member

Activity: 742

Merit: 500

Why decreased speed?
cgminer 3.2.1 - 645 kh
cgminer 3.3.1 - 605-610 kh

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: crazyearner on July 09, 2013, 11:37:02 PM

Problems mining on a pool is this cgminer problem within unit or is this problem on their side on the pool

The shares you sent have been looking like this:
020000005e4757cdbd7b756ceac436c46fe3ba6d9f532adaca8541c3beba010000000000246cf2c 7800231d5d50c5a7c9241e7465fb2085346478a4b95c70a34d43fec20daa1dc518db6011b70523f dc80000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000280

I think your miner messed up formatting the shares from mining to results.

it seems that it puts the result at the beginning

correct form should be:
result of the hash:
020000005e4757cdbd7b756ceac436c46fe3ba6d9f532adaca8541c3beba01
data sent to pool
0000000000246cf2c7800231d5d50c5a7c9241e7465fb2085346478a4b95c70a34d43fec20daa1d c518db6011b70523fdc800000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000280

Is this a bug to be fixed? or something to do with cgminer or something to do on their side on the pool ?

There's a standard way to submit shares in terms of byte swapping and endian order. cgminer secures more than half the bitcoin network having sent gazillions of shares since its inception. Look at the pool instead.

GenTarkin

legendary

Activity: 2450

Merit: 1002

think I MAY have found a bug in most recent avy firmware ..

It seems w/ avalon-auto & avalon-freq & an initial clock frequency > min of avalon-freq...
once avy clocks down the the min specified per avalon-freq, it seems to no go back up from that floor no matter what temps / hw error rate is =(
Example:

My initial clock is 350mhz, freq 315-400, during hot day avy will slowly clock down to 315, but even when it cools down and HW error rate is below 2% & temps are below their specified max...
It wont start climbing from 315 =(

crazyearner

legendary

Activity: 1820

Merit: 1001

Problems mining on a pool is this cgminer problem within unit or is this problem on their side on the pool

The shares you sent have been looking like this:
020000005e4757cdbd7b756ceac436c46fe3ba6d9f532adaca8541c3beba010000000000246cf2c 7800231d5d50c5a7c9241e7465fb2085346478a4b95c70a34d43fec20daa1dc518db6011b70523f dc80000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000280

I think your miner messed up formatting the shares from mining to results.

it seems that it puts the result at the beginning

correct form should be:
result of the hash:
020000005e4757cdbd7b756ceac436c46fe3ba6d9f532adaca8541c3beba01
data sent to pool
0000000000246cf2c7800231d5d50c5a7c9241e7465fb2085346478a4b95c70a34d43fec20daa1d c518db6011b70523fdc800000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000280

Is this a bug to be fixed? or something to do with cgminer or something to do on their side on the pool ?

GrapeApe

sr. member

Activity: 476

Merit: 250

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.

flyonwall

full member

Activity: 250

Merit: 100

RockStable Token Inc

Quote from: twmz on July 09, 2013, 11:53:39 AM

Quote from: flyonwall on July 09, 2013, 11:29:40 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

sr. member

Activity: 476

Merit: 250

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?

twmz

hero member

Activity: 737

Merit: 500

Quote from: flyonwall on July 09, 2013, 03: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?

Please read the README

Search it for '--usb'

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: salfter on July 09, 2013, 04:12:50 PM

Quote from: twmz on July 09, 2013, 02:22:14 PM

Quote from: crazyates on July 09, 2013, 01:45: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

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