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

[-ck]

I have  2 7970 GPU in my system and they are required a different GPU threads: -g 1 for the first card and -g2 for the second card.

How I can set it correctly in cgminer bat file? Settings like -g 1,2 does not work

The only way you can do that is to set the GPU that requires 1 thread to dynamic intensity (-I d).

Hashing speed is lowered 10 times.

I can simply do custom GPU threads for each cards in GUIminer and it is based on cgminer, so it should be solution somewhere around..

I have  2 7970 GPU in my system and they are required a different GPU threads: -g 1 for the first card and -g2 for the second card.

How I can set it correctly in cgminer bat file? Settings like -g 1,2 does not work

You cannot set separate thread counts without running 2 instances.

However you can set an intensity for dynamic as well, with gpu-dyninterval.

[1679671427]

1679671427

[1679671427]

1679671427

[Anime4000]

both GPU, run OpenCL benchmark, no problem.

this one on Catalyst 13.4, OpenCL 1.2

Try catalyst 13.1
Uninstall any drivers you have cleanly with driversweep, including the opencl installed and start again with what 13.1 installs. Then start with a freshly extracted cgminer or delete any .bin files you have in your cgminer directory.

I did uninstall driver, what AMD Installer did, they also uninstall motherboard driver, and restart, blue screen.
I go safe mode, sweep left over driver, reboot, blue screen, go safe mode again, remove driver manually on Device Manager,

now, install back everything, and OpenCL have problem,

https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash3/q71/10346_10201359330448163_818314584_n.jpg

cgminer still crash on start.

[Anime4000]

Update~
Remove and Reinstall for 2nd time, now it works on version 13.1

https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-ash4/q71/s720x720/1004584_10201359511492689_135703871_n.jpg

weird... some card can work on 13.4... hmmm...

[bitpop]

Just wanted to say, 331 doesn't display all devices especially when detected right after startup.

[tew]

I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).

I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices.  I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.

Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?

Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.

Thanks,
 -Tom

[-ck]

Just wanted to say, 331 doesn't display all devices especially when detected right after startup.

That's because on windows, the window resize often crashed on some of the windows OSs (?xp) and it was easier to just disable the window resize that shows new devices since we have so far been unable to fix that issue without just telling people to move to linux >_>

[carlosmi]

I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).

I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices.  I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.

Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?

Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.

Thanks,
 -Tom

+1 Trying to do the same with an Arduino Leonardo acting as controller of several devices.

[-ck]

I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).

I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices.  I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.

Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?

Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.

Thanks,
 -Tom

+1 Trying to do the same with an Arduino Leonardo acting as controller of several devices.

Unfortunately we're not a committee nor a huge team with emphasis on infrastructure and frameworks. Kano and I do this in our spare time and the model keeps changing dynamically as we progress and each new device comes along with its own new set of issues. We work on what gets things done and we have hardware to play with or care about or get sponsored to work on. This is nothing more than a hobby/pastime/passion gone mad for us.

That and I'm leaving to go overseas shortly for 6 weeks...

[crazyates]

That and I'm leaving to go overseas shortly for 6 weeks...

Ooh business or pleasure? 

[kano]

I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).

I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices.  I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.

Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?

Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.

Thanks,
 -Tom

Pointless.
As soon as someone comes out with the next design of hardware, suddenly the whole thing would be thrown out the window and have to start again.

At the moment we advance the drivers as we see they need them and incorporate changes and improvements where we see needed.
If something is going to 'break' the 'interface', we simply change the 'interface'.
If an improvement is found inside that interface we can simply change that.

It's the same everywhere in cgminer.
When a new pool protocol comes up, we then add support if we consider it viable or it is sponsored well enough and popular enough.
If the protocol used for the old GetWork (and the same for the crappy GBT) was defined as 'The must use Interface' some of the gains of Stratum would not exist.
Stratum is a completely different connection to Getwork

In fact it has quite clearly already happened with ASIC.
Earlier last year I had reservations about using serial-USB and the restrictions and loss of information from the underlying USB.
So at the end of last year I wrote a new interface using USB direct (libusb) and we've both improved on that since then.

It wasn't even a year ago I was having arguments with people about USB even being able to support ASIC speed devices.
Although there is still room to grow, it hasn't been a simple case of knowing there's a mile of headroom so it doesn't matter, it has indeed been a case of tuning the way everything works to make the ASIC miners work at maximum speed.

Locking things down to old ideas, or adding extra layers in the mining process to simplify it, is exactly what are are not trying to do.
Performance is what matters, but of course that's not absolute, it's simply getting the device to perform optimally (and not being restricted by some interface that someone decided is how it should be)

Things change in bitcoin pretty quickly actually ...

[Paladin69]

Yay zadig utility fucked up my ability to connect to my FPGA BFL MiniRig.  

Is there a tutorial out there somewhere?  Maybe this can't be done on an older XP laptop?  Was working before just fine prior to this winusb garbage.  It appeared to install correctly but no com ports are recognized now.

Easy to undo.
Go under system, device manager, USB serial bus controllers. The device will be there. Tell Windows to upgrade the driver. It will install the old serial one. Open Zadig, show all devices, and administrator. use WinUSB and the version of Zadig in the FPGA-README to try again. It will work.

I went to Linux and found far less errors. Raspberry Pi's are cheap, capable and low power. Personally it was the best <$60 I spent case included. Good luck!

Sorry for the late reply.  Just wanted to say thank you regarding undoing the zadig.  I'm back up and running with the machine in question again.  I didn't try reinstalling zadig because the XP version doesn't seem to have the libusb 1.0 version that is recommended in the readme.  I am using bfgminer for now since zadig isn't required, even for ASIC's according to pirate1.

Will cgminer come out with a version so zadig isn't required in the future?  I don't like changing it out so COM ports don't exist anymore.  I can't run EasyMiner admin tools without com ports if I ever need to identify which FPGA is giving me problems.

I don't understand how bfgminer got this working without zadig but cgminer needs it?

[crazyates]

I don't understand how bfgminer got this working without zadig but cgminer needs it?

BFG and CGMiner both used to use the FTDI drivers for USB devices. CGMiner switched to libusb, but requires you to reinstall new drivers. Once you do it one, it should be all set.

[os2sam]

 I didn't try reinstalling zadig because the XP version doesn't seem to have the libusb 1.0 version that is recommended in the readme.

Worked fine on my XP SP3

[Paladin69]

I don't understand how bfgminer got this working without zadig but cgminer needs it?

BFG and CGMiner both used to use the FTDI drivers for USB devices. CGMiner switched to libusb, but requires you to reinstall new drivers. Once you do it one, it should be all set.

I understand that part, but why make people do the extra step?  bfgminer doesn't need it when ASIC's are run there.

[Krak]

I don't understand how bfgminer got this working without zadig but cgminer needs it?

BFG and CGMiner both used to use the FTDI drivers for USB devices. CGMiner switched to libusb, but requires you to reinstall new drivers. Once you do it one, it should be all set.

I understand that part, but why make people do the extra step?  bfgminer doesn't need it when ASIC's are run there.

Because direct USB is better, plain and simple.

(inb4 Luke-jr's trolling)

[Paladin69]

I don't understand how bfgminer got this working without zadig but cgminer needs it?

BFG and CGMiner both used to use the FTDI drivers for USB devices. CGMiner switched to libusb, but requires you to reinstall new drivers. Once you do it one, it should be all set.

I understand that part, but why make people do the extra step?  bfgminer doesn't need it when ASIC's are run there.

Because direct USB is better, plain and simple.

(inb4 Luke-jr's trolling)

Define better.  Hashes more?

[kano]

Yay zadig utility fucked up my ability to connect to my FPGA BFL MiniRig.  

Is there a tutorial out there somewhere?  Maybe this can't be done on an older XP laptop?  Was working before just fine prior to this winusb garbage.  It appeared to install correctly but no com ports are recognized now.

Easy to undo.
Go under system, device manager, USB serial bus controllers. The device will be there. Tell Windows to upgrade the driver. It will install the old serial one. Open Zadig, show all devices, and administrator. use WinUSB and the version of Zadig in the FPGA-README to try again. It will work.

I went to Linux and found far less errors. Raspberry Pi's are cheap, capable and low power. Personally it was the best <$60 I spent case included. Good luck!

Sorry for the late reply.  Just wanted to say thank you regarding undoing the zadig.  I'm back up and running with the machine in question again.  I didn't try reinstalling zadig because the XP version doesn't seem to have the libusb 1.0 version that is recommended in the readme.
...

The binary release has the dll's you need (including libusb) ... so you messed up

... as I said last time ...
https://bitcointalk.org/index.php?topic=28402.msg2591941#msg2591941

[MinorMiner]

FEATURE REQUEST

Be able to run a script if a USB unit has issues. Could pass USB ID as an argument to this script, then the script could take action to power cycle the device in question.

I have found web controlled power switches that would allow a computer to power cycle peripherals from a script. It would be really helpful if cgminer detects a problem with a device (or devices) to be able to run a script to be able to power cycle them.

At the simplest level, a script to power cycle the whole lot would be a good start. Being able to pass the USB ID of the device in question would allow just that device to be power cycled, for example.

I'm thinking about this under Linux, which is where I run my miners. So simply being able to run a shell script with parameters is what I'm after. Not sure how it would be handled under Windows ... .vbs? .wsh?

Maybe the script could email the admin too? Either way, if there is a 'trouble script' handle, it would be AWESOME

[twmz]

FEATURE REQUEST

Be able to run a script if a USB unit has issues. Could pass USB ID as an argument to this script, then the script could take action to power cycle the device in question.

I have found web controlled power switches that would allow a computer to power cycle peripherals from a script. It would be really helpful if cgminer detects a problem with a device (or devices) to be able to run a script to be able to power cycle them.

At the simplest level, a script to power cycle the whole lot would be a good start. Being able to pass the USB ID of the device in question would allow just that device to be power cycled, for example.

I'm thinking about this under Linux, which is where I run my miners. So simply being able to run a shell script with parameters is what I'm after. Not sure how it would be handled under Windows ... .vbs? .wsh?

Maybe the script could email the admin too? Either way, if there is a 'trouble script' handle, it would be AWESOME

Prior to this enhancement being added (if it does get added), you could accomplish something similar by writing a script that polls the API every 30 seconds (or whatever) looking for unhealthy devices.  I have something similar that looks for a variety of issues on my devices (status other than "Alive", abnormally high HW errors or rejected shares, abnormally low hashrate, abnormal temp, etc.  It doesn't power cycle them (interesting idea), but rather just sends me an alert to do manual investigation and intervention.

[MineForeman.com]

FEATURE REQUEST

I may be overstepping my boundaries (sorry ckolivas & kano) but what you're asking is not really within the scope of what cgminer does.

On top of that, one of the things that cgminer actually does do (the api) is already in place to allow you to do what you're asking, you just need to implement it .

Just to point you in the right direction though, have a look at API-README and miner.php.  You will find everything you need in there.

Neil