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

[zefir]

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.

[1714101398]

1714101398

[1714101398]

1714101398

[1714101398]

1714101398

[antirack]

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)

[roomservice]

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

[BR0KK]

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

[kano]

...
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
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

[Luke-Jr]

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

[nelisky]

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'.

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:

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.

[eroxors]

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?

[ancow]

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.

[roomservice]

Thanks a lot @nelisky

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

It works really well!

[DeathAndTaxes]

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
	},

[jamesg]

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]

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

Yeah I got a workaround but it is clunky.  As I use the API more and more I am finding I want the ability to never need to remote into the rig.  Monitor from the API and have the config file control everything.

[Aseras]

What I'd love is to have a command to have cgminer reload the config file without restarting.

That way you could change or edit the files and just trigger a restart in the api.

[Kuma]

Hi,
I tried Nelisky's code and it works perfectly for my Ztex quad.
Two notices. I think there should be mentioned udev setting regarding access rights (from http://wiki.ztex.de/doku.php?id=en:software:usb_ids) in the README file. I also noticed, I must flash device to the cluster mode using BTCMiner for the first time to be able to use cgminer for Ztex after reboot.

[Inaba]

CGminer keeps exiting with this error:
 [2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync

I have to restart it manually at this point.

[zefir]

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

Thanks. But after this didn't help I looked deeper and it was something completely different. In short, do:

Code:

sudo apt-get purge modemmanager

to get rid of that component that kicks in after boot and interferes with cgminer.

[nelisky]

Hi,
I tried Nelisky's code and it works perfectly for my Ztex quad.
Two notices. I think there should be mentioned udev setting regarding access rights (from http://wiki.ztex.de/doku.php?id=en:software:usb_ids) in the README file. I also noticed, I must flash device to the cluster mode using BTCMiner for the first time to be able to use cgminer for Ztex after reboot.

It's funny, I never had to deal with access rights. But I guess that's a byproduct of the distributions I've been using.

As for flashing to the cluster mode, you do have to upload the firmware first using BTCMiner, but there's no 'cluster mode' per se, that's just a mode of operation for the mining software. The firmware is the same in either standalone or cluster mode. I do plan to add the ability to flash the firmware eventually, but since that's a one off operation (well, sort of, once per version upgrade from ztex) it is not something I plan to tackle just yet.

My implementation is seriously lacking in documentation, that much is certainly true, but with my limited environment testing I hope someone that has to deal with the installation from scratch will step up and do that (hint, hint).

[Kuma]

I understood from Ztex documentation, than the firmware is flashed to the eeprom (indeed firmware is the same).

If I remember correctly I used

java -cp ZtexBTCMiner-120417.jar BTCMiner -m p -f ztex_ufm1_15y1.ihx

And after that I was able to use cgminer even after Quad and computer reboot. Before this step I had to run btcminer first, to be able to use quad under cgminer.
I hope I'm not mistaken as I tested this only briefly .

BTW the problem with the user rights was under Fedora, I had to run cgminer or btcminer as a root to be able to use quad for mining.

[fred0]

I recently made a change to cgminer's logging.c to eliminate the accepted/rejected share logging. Basically, I changed the LOG_NOTICE to LOG_WARNING on line 54 of logging.c.  It really cuts down on the noise level of the cgminer window.

What I think would be a useful change would be to specify the verbosity of the messages through the command line, rather than the --quiet which eliminates virtually all messages.

Example output follows:

Code:

 [2012-05-04 12:37:45] Pool 0 not providing work fast enough
 [2012-05-04 12:40:22] Pool 0 communication failure, caching submissions
 [2012-05-04 12:40:23] Pool 0 communication resumed, submitting work
 [2012-05-04 13:50:30] Pool 0 not providing work fast enough
 [2012-05-04 14:25:35] Pool 0 not providing work fast enough
 [2012-05-04 16:38:04] Pool 0 not providing work fast enough