Bitcoin Forum
July 23, 2018, 03:16:45 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 [739] 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5757012 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.
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
March 24, 2014, 06:52:10 AM
 #14761

Hello Con,

I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!

Here are my findings:

First Issue
From the following code



static inline void _cg_wlock(cglock_t *lock, const char *file, const char *func, const int line)
{
   _mutex_lock(&lock->mutex, file, func, line);
   _wr_lock(&lock->rwlock, file, func, line);
}

static inline void _cg_rlock(cglock_t *lock, const char *file, const char *func, const int line)
{
   _mutex_lock(&lock->mutex, file, func, line);
   _rd_lock(&lock->rwlock, file, func, line);
   _mutex_unlock_noyield(&lock->mutex, file, func, line);
}

It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)

Please take a look at the flowing peace of code

stale_work(struct work *work, bool share)   
.....
   cg_rlock(&pool->data_lock);
      if (strcmp(work->job_id, pool->swork.job_id))
         same_job = false;
      cg_runlock(&pool->data_lock)

It may turn that while we are performing strcmp
static bool parse_notify(struct pool *pool, json_t *val)
.......

   cg_wlock(&pool->data_lock);
   free(pool->swork.job_id);
   pool->swork.job_id = job_id;

frees pool->swork.job_id

Resulting in flowing line in BLOCKED gets (9) id=248038834 by cgminer.c stale_work()....
I have changed stale_work
      cg_rlock(&pool->data_lock);
      if (strcmp(work->job_id, pool->swork.job_id))
         same_job = false;
      cg_runlock(&pool->data_lock);
to
    cg_wlock(&pool->data_lock);
   
      if (strcmp(work->job_id, pool->swork.job_id))
         same_job = false;
      cg_wunlock(&pool->data_lock);
I have moved

gen_stratum_work.....

work->job_id = strdup(pool->swork.job_id); under
cg_wlock(&pool->data_lock);
Second:

   cg_wlock(&control_lock);
   local_work++;
   work->id = total_work++;
   cg_wunlock(&control_lock);

I do think that everywhere total_work++; and local_work++ shod be changed under &control_lock. This is not happening currently. I am digging to find all places to do it









Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
"With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 07:10:08 AM
 #14762

Hello Con,

I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!

Here are my findings:

First Issue
From the following code


[snip]

It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks.

Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See:
http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.html

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
March 24, 2014, 07:23:01 AM
 #14763

Hello Con,

I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!

Here are my findings:

First Issue
From the following code


[snip]

It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks.

Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See:
http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.html

So what will happen when  if (strcmp(work->job_id, pool->swork.job_id)) and free(pool->swork.job_id); are executed simultaneously?

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 07:25:36 AM
 #14764

Hello Con,

I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!

Here are my findings:

First Issue
From the following code


[snip]

It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks.

Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See:
http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.html

So what will happen when  if (strcmp(work->job_id, pool->swork.job_id)) and free(pool->swork.job_id); are executed simultaneously?
That can't happen.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
March 24, 2014, 07:28:17 AM
 #14765

Hello Con,

I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!

Here are my findings:

First Issue
From the following code


[snip]

It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks.

Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See:
http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.html

So what will happen when  if (strcmp(work->job_id, pool->swork.job_id)) and free(pool->swork.job_id); are executed simultaneously?
That can't happen.
Oki You are the boss..
Thank you for your comments.

Best

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 08:38:54 AM
 #14766

That can't happen.
Oki You are the boss..
Thank you for your comments.
Heh no problem Wink Appreciate extra eyes on the code, always.

BTW if it wasn't obvious: The cg write lock variant would have grabbed the mutex successfully but be unable to grab the write lock while the other thread holds the read lock.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


Linux since 1997 RedHat 4


View Profile
March 24, 2014, 01:04:53 PM
 #14767

...
I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!
...
You're welcome Smiley

Yes Con designed all of the cglock code and wrote almost all of it.
I've had a few deadlocks I've coded in the past, so I wrote the lock tracking to be able to find them easily when I cause them.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
loshia
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


View Profile
March 24, 2014, 04:04:07 PM
 #14768

...
I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!
...
You're welcome Smiley

Yes Con designed all of the cglock code and wrote almost all of it.
I've had a few deadlocks I've coded in the past, so I wrote the lock tracking to be able to find them easily when I cause them.
Nice hack for lockstats to make them usable or at least for me api.c

#if LOCK_TRACKING

FILE * pFile;

#define LOCK_FMT_FFL " - called from %s %s():%d"

#define LOCKMSG(fmt, ...)   fprintf(pFile, "APILOCK: " fmt "\n", ##__VA_ARGS__)
#define LOCKMSGMORE(fmt, ...)   fprintf(pFile, "          " fmt "\n", ##__VA_ARGS__)
#define LOCKMSGFFL(fmt, ...) fprintf(pFile, "APILOCK: " fmt LOCK_FMT_FFL "\n", ##__VA_ARGS__, file, func, linenum)
#define LOCKMSGFLUSH() fflush(pFile)

then

void show_locks()
{
   pFile = fopen ("/tmp/cglocks","w");
..........


   fclose (pFile);

}

So no need to stare over console and catch the lines moving Wink

PS:

Guy's
What about
   cg_wlock(&control_lock);
   .....local_work++;
   .....total_work++;
   cg_wunlock(&control_lock);
I think there is a need to lock them everywhere or ?

Thanks

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
storm2k5
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
March 24, 2014, 04:09:02 PM
 #14769

Hashfast per die clock rate setting:

I have noticed that in driver-hashfast.c, there seems to be adaptive clock rate setting per die:

Code:
applog(LOG_INFO, "%s %d: Die temp below range %.1f, increasing die %d clock to %d",
hashfast->drv->name, hashfast->device_id, info->die_data[die].temp, die, hdd->hash_clock);
hfa_send_frame(hashfast, HF_USB_CMD(OP_WORK_RESTART), hdata, (uint8_t *)&diebit, 4);

Is there a way to set per die clock from command line or conf file? Reason I'm asking is one of my dies seems to work fine up to 150MHz then it completely stops working and I would like to clock dies 0-2 with normal clock and underclock die 3.

Edit: By the looks of your comments and the code it seems that per die clock setting will be possible for FW 0.5 and up. Do you already got FW 0.5 from hashfast by any chance?

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 08:33:40 PM
 #14770

PS:

Guy's
What about
   cg_wlock(&control_lock);
   .....local_work++;
   .....total_work++;
   cg_wunlock(&control_lock);
I think there is a need to lock them everywhere or ?

Thanks
Mostly harmless, but probably wouldn't hurt to protect them with the write lock for when mining at multiple different types of pools at once (eg GBT + stratum), yes, thanks.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 08:38:38 PM
 #14771

Hashfast per die clock rate setting:

I have noticed that in driver-hashfast.c, there seems to be adaptive clock rate setting per die:

Code:
applog(LOG_INFO, "%s %d: Die temp below range %.1f, increasing die %d clock to %d",
hashfast->drv->name, hashfast->device_id, info->die_data[die].temp, die, hdd->hash_clock);
hfa_send_frame(hashfast, HF_USB_CMD(OP_WORK_RESTART), hdata, (uint8_t *)&diebit, 4);

Is there a way to set per die clock from command line or conf file? Reason I'm asking is one of my dies seems to work fine up to 150MHz then it completely stops working and I would like to clock dies 0-2 with normal clock and underclock die 3.

Edit: By the looks of your comments and the code it seems that per die clock setting will be possible for FW 0.5 and up. Do you already got FW 0.5 from hashfast by any chance?
Older firmware 0.3+ can do per die clockspeeds as well but when there is a large difference in the clocks it causes huge dips and peaks in the metering out of work which can present temperature and other issues. It is not possible to set clock speed per die on the command line yet but it is possible to add that feature.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Sinturvy
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
March 24, 2014, 09:50:36 PM
 #14772

After patching the cgminer 4.0.0 patch (HEX16 by Technobit) I tried to "make" my cgminer-4.0.0 with MinGW/MSYS-Shell for the HEX16B. But it failed!

Code:
Sinturvy@SINNETWORK ~/cgminer-3.8.5
$ make
make  all-recursive
make[1]: Entering directory `/home/Sinturvy/cgminer-3.8.5'
Making all in lib
make[2]: Entering directory `/home/Sinturvy/cgminer-3.8.5/lib'
  GEN    arg-nonnull.h
  GEN    c++defs.h
  GEN    warn-on-use.h
  GEN    signal.h
  GEN    string.h
make  all-recursive
make[3]: Entering directory `/home/Sinturvy/cgminer-3.8.5/lib'
make[4]: Entering directory `/home/Sinturvy/cgminer-3.8.5/lib'
  CC     dummy.o
  CC     memmem.o
  CC     sigaction.o
  CC     sigprocmask.o
  AR     libgnu.a
make[4]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/lib'
make[3]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/lib'
make[2]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/lib'
Making all in compat
make[2]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5/src
'
  CC     dump.lo
  CC     error.lo
  CC     hashtable.lo
  CC     load.lo
  CC     memory.lo
  CC     pack_unpack.lo
  CC     strbuffer.lo
  CC     strconv.lo
  CC     utf.lo
  CC     value.lo
  CCLD   libjansson.la
Creating library file: .libs/libjansson.dll.a
make[5]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5/src'

make[5]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
make[5]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
make[4]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
make[3]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0/libu
sb'
  CC     libusb_1_0_la-core.lo
  CC     libusb_1_0_la-descriptor.lo
  CC     libusb_1_0_la-io.lo
  CC     libusb_1_0_la-sync.lo
  CC     os/libusb_1_0_la-poll_windows.lo
  CC     os/libusb_1_0_la-windows_usb.lo
  GEN    libusb-1.0.lo
  CC     libusb_1_0_la-hotplug.lo
  CC     os/libusb_1_0_la-threads_windows.lo
  CCLD   libusb-1.0.la
Creating library file: .libs/libusb-1.0.dll.a
make[5]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0/libus
b'
make[5]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
make[5]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
make[4]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
make[3]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat/libusb-1.0'
make[3]: Entering directory `/home/Sinturvy/cgminer-3.8.5/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat'
make[2]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/compat'
Making all in ccan
make[2]: Entering directory `/home/Sinturvy/cgminer-3.8.5/ccan'
  CC     opt/libccan_a-helpers.o
  CC     opt/libccan_a-opt.o
  CC     opt/libccan_a-parse.o
  CC     opt/libccan_a-usage.o
  AR     libccan.a
make[2]: Leaving directory `/home/Sinturvy/cgminer-3.8.5/ccan'
make[2]: Entering directory `/home/Sinturvy/cgminer-3.8.5'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
  CC     cgminer-sha2.o
  CC     cgminer-api.o
  CC     cgminer-logging.o
  CC     cgminer-usbutils.o
usbutils.c: In Funktion »_usb_init«:
usbutils.c:1760:5: Warnung: Unverträgliche implizite Deklaration der eingebauten
 Funktion »bzero« [standardmäßig aktiviert]
  CC     cgminer-driver-hexminera.o
driver-hexminera.c: In Funktion »hexminera_get_results«:
driver-hexminera.c:278:5: Warnung: Unverträgliche implizite Deklaration der eing
ebauten Funktion »bzero« [standardmäßig aktiviert]
  CC     cgminer-driver-hexminerb.o
driver-hexminerb.c: In Funktion »hexminerb_get_results«:
driver-hexminerb.c:290:3: Warnung: Unverträgliche implizite Deklaration der eing
ebauten Funktion »bzero« [standardmäßig aktiviert]
  CC     cgminer-driver-hexminerc.o
driver-hexminerc.c: In Funktion »hexminerc_get_results«:
driver-hexminerc.c:276:5: Warnung: Unverträgliche implizite Deklaration der eing
ebauten Funktion »bzero« [standardmäßig aktiviert]
  CCLD   cgminer.exe
make[2]: Leaving directory `/home/Sinturvy/cgminer-3.8.5'
make[1]: Leaving directory `/home/Sinturvy/cgminer-3.8.5'

Sinturvy@SINNETWORK ~/cgminer-3.8.5
$

CGminer.exe is compiled but I'm getting the following error:

Code:
USB init, open device failed, err -12, you need to install a WinUSB driver for - HEXb device 3:2
See README.txt file included for help
hexminerb detect (3:2) failed to initialise (incorrect device?)
No devices detected!
Waiting for USB hotplug devices or press q to quit

Would be awesome if anyone could help me! Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 09:53:10 PM
 #14773

After patching the cgminer 4.0.0 patch (HEX16 by Technobit) I tried to "make" my cgminer-4.0.0 with MinGW/MSYS-Shell for the HEX16B. But it failed!

Would be awesome if anyone could help me! Smiley
We do not support external patches on the cgminer code. Seek help from whoever provided those patches. Though it looks like you just need to do what it says: install a winusb driver.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Sinturvy
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
March 24, 2014, 09:59:56 PM
 #14774

Yeah, would be a mess if you would do so.
I already installed the WinUSB Driver which is provided by Technobit. I'll ask their support.
Thanks ckolivas Smiley

Edit: Do you think the Compile-Error has something to do about the detection-error? I also can't find a *.cl File in my directory.

Edit II: Your WinUSB Devicepicker (http[Suspicious link removed]) worked. Thanks!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 24, 2014, 11:24:00 PM
 #14775

For those of you on windows who have devices that don't show up on USB3 slots, you can try the following binary (it is otherwise identical to the 4.2.1 release):

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

If it turns out to fix the problems, I might just re-package 4.2.1 for windows.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
winit
Jr. Member
*
Offline Offline

Activity: 45
Merit: 0


View Profile
March 25, 2014, 02:26:36 AM
 #14776

Hi Con,

Firstly thanks for all the updates aimed at Hashfast devices, 4.2 has helped a lot.

As all Sierra's are not born equal I need to run them at different clock speeds. I successfully used the '--hfa-name Slug --usb 4:42' to rename one device to later allow me to use '--hfa-options "rabbit:650,turtle:550"'
If I add more renaming to the string it simply doesn't find any device. Can you tell me what I have wrong with the below?

--hfa-name NS1 --usb 1:7 --hfa-name NS2 --usb 2:7 --hfa-name NS3 --usb 2:4

Thanks
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 25, 2014, 02:28:41 AM
 #14777

Hi Con,

Firstly thanks for all the updates aimed at Hashfast devices, 4.2 has helped a lot.

As all Sierra's are not born equal I need to run them at different clock speeds. I successfully used the '--hfa-name Slug --usb 4:42' to rename one device to later allow me to use '--hfa-options "rabbit:650,turtle:550"'
If I add more renaming to the string it simply doesn't find any device. Can you tell me what I have wrong with the below?

--hfa-name NS1 --usb 1:7 --hfa-name NS2 --usb 2:7 --hfa-name NS3 --usb 2:4

Thanks

--hfa-name <arg>    Set a unique name for a single hashfast device specified with --usb or the first device found

Name one at a time. You only need to name them once; the names should keep for ever more even with firmware updates.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
winit
Jr. Member
*
Offline Offline

Activity: 45
Merit: 0


View Profile
March 25, 2014, 02:30:19 AM
 #14778

Thanks man... sorry for being the reading retard!

Cheers
winit
Jr. Member
*
Offline Offline

Activity: 45
Merit: 0


View Profile
March 25, 2014, 02:55:49 AM
 #14779

I think I have named them all individually but no matter what string I use for --hfa-options I can't get it to load. Can you write me an example?

Thanks
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2590
Merit: 1113


Ruu \o/


View Profile WWW
March 25, 2014, 03:40:04 AM
 #14780

I think I have named them all individually but no matter what string I use for --hfa-options I can't get it to load. Can you write me an example?

Thanks

Shall I quote the docs again?

Quote
--hfa-options <arg> Set hashfast options name:clock (comma separated)

This command allows you to set options for each discrete hashfast device by
its name (if the firmware has naming support, i.e. version 0.3+). Currently
this takes only one option, the clock speed, although future options may be
added.
e.g.:
--hfa-options "rabbit:650,turtle:550"

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 [739] 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 ... 847 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!