Bitcoin Forum
June 16, 2024, 08:40:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 [562] 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805299 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
-ck (OP)
Legendary
*
Offline Offline

Activity: 4144
Merit: 1637


Ruu \o/


View Profile WWW
June 30, 2013, 07:27:44 AM
 #11221

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

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.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Anime4000
Newbie
*
Offline Offline

Activity: 30
Merit: 0



View Profile WWW
June 30, 2013, 11:30:03 AM
 #11222

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
Newbie
*
Offline Offline

Activity: 30
Merit: 0



View Profile WWW
June 30, 2013, 12:21:03 PM
 #11223

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
Legendary
*
Offline Offline

Activity: 2912
Merit: 1060



View Profile WWW
June 30, 2013, 02:34:12 PM
 #11224

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

tew
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
June 30, 2013, 08:50:42 PM
 #11225

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 (OP)
Legendary
*
Offline Offline

Activity: 4144
Merit: 1637


Ruu \o/


View Profile WWW
June 30, 2013, 10:05:09 PM
 #11226

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
carlosmi
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
July 01, 2013, 09:12:22 AM
 #11227

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 (OP)
Legendary
*
Offline Offline

Activity: 4144
Merit: 1637


Ruu \o/


View Profile WWW
July 01, 2013, 12:27:44 PM
 #11228

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
July 01, 2013, 02:30:18 PM
 #11229

That and I'm leaving to go overseas shortly for 6 weeks...
Ooh business or pleasure?  Grin Grin

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
kano
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
July 01, 2013, 03:00:44 PM
 #11230

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

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Paladin69
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 01, 2013, 05:36:16 PM
 #11231

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

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
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
July 01, 2013, 05:52:22 PM
 #11232

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.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
os2sam
Legendary
*
Offline Offline

Activity: 3578
Merit: 1091


Think for yourself


View Profile
July 01, 2013, 07:08:26 PM
 #11233

 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

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?
Paladin69
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 01, 2013, 09:20:24 PM
 #11234

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
Hero Member
*****
Offline Offline

Activity: 591
Merit: 500



View Profile WWW
July 01, 2013, 09:40:22 PM
 #11235

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)

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
Paladin69
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 01, 2013, 11:05:01 PM
 #11236

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
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
July 01, 2013, 11:17:26 PM
 #11237

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

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 Tongue

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

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
MinorMiner
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
July 01, 2013, 11:49:47 PM
 #11238

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 Smiley

All contributions gratefully received 1G6Wia22Jnpz2DUisA5EoAC6KJ7MHm6QyP
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
July 02, 2013, 12:01:09 AM
 #11239

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 Smiley


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.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
MineForeman.com
Legendary
*
Offline Offline

Activity: 896
Merit: 1000



View Profile WWW
July 02, 2013, 12:13:58 AM
 #11240

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

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

Bitcoin News http://mineforeman.com/ || MinePeon - Bitcoin mining on the Raspberry PI http://mineforeman.com/minepeon/ || MinePeon Wiki http://minepeon.com/ || MinePeon Forums http://minepeon.com/forums/
Pages: « 1 ... 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 [562] 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!