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

jamesg

vip

Activity: 1358

Merit: 1000

AKA: gigavps

Quote from: DeathAndTaxes on May 04, 2012, 01:04:12 PM

A request for a minor feature:

ability to enable/disable a pool and change pool priorities in config file

Example:

Code:

	{
		"url" : "url",
		"user" : "user",
		"pass" : "pass",
                "priority" : "1",     <-default is as currently implemented (order of pools in config file)
                "enabled" : "false"    <- default is true
	},

This is a nice request although I have done this with a bash script and the API.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

A request for a minor feature:

ability to enable/disable a pool and change pool priorities in config file

Example:

Code:

	{
		"url" : "url",
		"user" : "user",
		"pass" : "pass",
                "priority" : "1",     <-default is as currently implemented (order of pools in config file)
                "enabled" : "false"    <- default is true
	},

roomservice

full member

Activity: 199

Merit: 100

Thanks a lot @nelisky

Just learned the hard way, how to git clone a branch Cry

It works really well!

ancow

full member

Activity: 373

Merit: 100

Quote from: eroxors on May 04, 2012, 10:54:41 AM

Is there a way to set one GPU thread to mine at one pool at a certain intensity and another GPU thread to mine at a different pool at a different intensity?

Yes: run two instances of cgminer, each with only one thread and point them at different pools with different intensities.

eroxors

legendary

Activity: 924

Merit: 1000

Think. Positive. Thoughts.

Is there a way to set one GPU thread to mine at one pool at a certain intensity and another GPU thread to mine at a different pool at a different intensity?

nelisky

legendary

Activity: 1540

Merit: 1001

Quote

when i try to
ztex-120417 branch doesn't ./configure --enable-ztex

i got
WARNING: unrecognized options: --enable-ztex

Do you have the right branch checked out? Try 'git branch'.

Quote

I have compiled cgminer with ztex support and created the 'bitstreams' folder in the cgminer directory.

Do I have to specify the USB ports somehow? I get this:

BTCMiner uses libusb-0.1, cgminer uses libusb-1.0

I've written about it before, although I now see I did that in the BFGMiner thread:

Quote

Ok, so visit http://libusb.org/wiki/windows_backend and grab yourself the zadig utility (just fing zadig on that page).
Using Zadig, find the ztex device (it's either 221A:0100 or "ZTEX Module") on the drop down (You may need to use the "List All Devices" menu option) and install the WinUSB driver. That should be enough to make it work.

If you need to later upgrade firmware or use BTCMiner again you'll need to, using Zadig again, install the libusb-win32 driver on your device and you should be set.

If the device appears as 221A:0100 you must edit the name to "ZTEX Module".

Let me know how that goes.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: zefir on May 04, 2012, 03:55:04 AM

Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ?

Code:

udevadm settle

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: zefir on May 04, 2012, 03:55:04 AM

...
Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ?

That actually sounds like a good idea Tongue

Save the time, keep checking dmesg, then delay a few seconds and run cgminer
If it takes longer that some limit then you know it's failed and can do some manual interference

BR0KK

hero member

Activity: 784

Merit: 500

I had that error too and i think it has sonething to do with the Driver u use for BTC miner.

Nelski installed a program called zdiaq (dont have the right name for that programm in my mind)
That changes the lib usb- to the win usb driver.

He can propably explaon better Wink

roomservice

full member

Activity: 199

Merit: 100

Quote from: nelisky on May 04, 2012, 04:12:50 AM

I have a test branch with cgminer support for ZTEX 1.15y quad boards. Anyone willing to give it a try please grab the source at https://github.com/nelisky/cgminer/tree/ztex-120417

If you are unable to compile it yourself I might be able to provide binaries on some platforms.

when i try to
ztex-120417 branch doesn't ./configure --enable-ztex

i got
WARNING: unrecognized options: --enable-ztex

Sad

antirack

hero member

Activity: 489

Merit: 500

Immersionist

Quote from: nelisky on May 04, 2012, 04:12:50 AM

I have a test branch with cgminer support for ZTEX 1.15y quad boards. Anyone willing to give it a try please grab the source at https://github.com/nelisky/cgminer/tree/ztex-120417

If you are unable to compile it yourself I might be able to provide binaries on some platforms.

I have compiled cgminer with ztex support and created the 'bitstreams' folder in the cgminer directory.

Do I have to specify the USB ports somehow? I get this:

Code:

[2012-05-04 20:04:25] Started cgminer 2.4.0
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Found 0 ztex board(s)

zefir

donator

Activity: 919

Merit: 1000

Quote from: -ck on May 04, 2012, 07:19:42 AM

Well, we already ask for work from backup pools when the primary pool can't keep up. But there's a difference between asking for extra work cause you can't keep your queue full, and running out entirely. As I said, the distinction needs to be made or you can't flag the primary pool as "officially fucked".

I see. But in the log I posted above there was obviously no attempt to get work from the secondary pool for 40s, even it was evident that main pool is inactive.

Anyhow, as you said, it's a pool issue and not up to cgminer to handle it. Thanks.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: leveer on May 04, 2012, 07:42:57 AM

Can the "--no-pool-disable" option be set via the .conf file?

"no-pool-disable" : true,

leveer

newbie

Activity: 42

Merit: 0

Can the "--no-pool-disable" option be set via the .conf file?

nelisky

legendary

Activity: 1540

Merit: 1001

Quote from: -ck on May 04, 2012, 07:31:29 AM

Quote from: BR0KK on May 04, 2012, 07:24:42 AM

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

I take it this means his quad code is working? Nelisky, do you mind pushing a git pull for your updated code

?

Working? yes. Thoroughly tested? well...

Let me go through the code to check for any obvious blooper and I'll do the PR afterwards.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BR0KK on May 04, 2012, 07:24:42 AM

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

I take it this means his quad code is working? Nelisky, do you mind pushing a git pull for your updated code

?

BR0KK

hero member

Activity: 784

Merit: 500

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zefir on May 04, 2012, 07:02:05 AM

Would it be too aggressive towards pools to request more work than you actually work on? My layman approach would be: I know I have e.g. 4GH power and will need new work once a second. As soon as work is given to a device, immediately ask primary pool for more (instead of waiting for a device to do so) and if that one does not respond within 600ms, ask backup pool(s). The cost for such an pro-active approach would be that you ask for more work than you can handle, but you would not have to wait that long to see some pool is dead.

As for my cgminer version: you're just too fast/active Wink

, it is from 24h ago and includes the pool scheduling improvements you added for 2.4.0. Can't catch up pulling with the speed of improvements you add.

Well, we already ask for work from backup pools when the primary pool can't keep up. But there's a difference between asking for extra work cause you can't keep your queue full, and running out entirely. As I said, the distinction needs to be made or you can't flag the primary pool as "officially fucked".

zefir

donator

Activity: 919

Merit: 1000

Quote from: -ck on May 04, 2012, 06:19:09 AM

Quote from: zefir on May 04, 2012, 06:16:40 AM

I see that connection got lost to bonuspool initially at 06:41:35, but the switch to the backup poo happens almost 40s later with GPUs and BFLs idling in between. This happens continuously and causes total hash-rate to be 20% worse with bonuspool than e.g. ABCpool. I was assuming that the pool scheduling assures that there is always some work available, i.e. it is pre-fetched and ready when a device needs fresh work.

Is this a bug or a feature? If it's a bug, would a more verbose log help you to isolate the problem? (cgminer is latest GIT source, BTW).

No, you are correct. It needs to see that a pool has been unresponsive for a full minute before switching pools. The problem with resorting to backup work is that it can't tell that it has completely utterly run out of work until nothing is coming in at all for a demonstrable amount of time. If it keeps getting work from the backup pools, it can't really tell that the primary pool has failed. There is some crossover, but it has to detect that things have truly gone idle with nothing to do before saying "fuck this pool, it's dead".

edit: if a pool is that unreliable, you really have to consider whether it's worth mining there or not.

Would it be too aggressive towards pools to request more work than you actually work on? My layman approach would be: I know I have e.g. 4GH power and will need new work once a second. As soon as work is given to a device, immediately ask primary pool for more (instead of waiting for a device to do so) and if that one does not respond within 600ms, ask backup pool(s). The cost for such an pro-active approach would be that you ask for more work than you can handle, but you would not have to wait that long to see some pool is dead.

As for my cgminer version: you're just too fast/active Wink

, it is from 24h ago and includes the pool scheduling improvements you added for 2.4.0. Can't catch up pulling with the speed of improvements you add.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

By the way, your longpoll error message is pre 2.4.0
"longpoll failed for XXX, retrying every 30s"
is the current 2.4.0 message and should only appear once until it starts working again, so I'm not convinced you're running the latest git.

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