GekkoScience has a new stickminer that does 300+GH

[BiticaMan]

Can you help me?

How do I use the screw to adjust the compacF current?

If I turn right, does the stick current increase or decrease?

Does this adjustment decrease or increase the stick's mining ability?

Thanks.

[jack1cryptotalk007]

turn right or clock turning,  increse current => increase frequence, then, increse hashing. But, increase hot?

There is another indicator (7:20) on display screen in cgminer, which rules out the performance of compacF stick miner.
It often change and has more impact on hash rate on this stick miner.
(7 : 20) got more hashrate, faster.
(16: 20) got less hashrate, slower.

[BiticaMan]

turn right or clock turning,  increse current => increase frequence, then, increse hashing. But, increase hot?

There is another indicator (7:20) on display screen in cgminer, which rules out the performance of compacF stick miner.
It often change and has more impact on hash rate on this stick miner.
(7 : 20) got more hashrate, faster.
(16: 20) got less hashrate, slower.

Mine is showing 28:14 for the 450mhz sticks and 38:19 for the 330mhz one

Are these numbers ok? Is there anything to configure to improve this?

Another question, can you tell cgminer the mhz for 1 specific stick? I have a usb hub that does not support the sticks at 450mhz and I would like to leave these with a smaller mhz, but cgminer tries to keep increasing the frequency to the programmed 450mhz.

[n0nce]

Another question, can you tell cgminer the mhz for 1 specific stick? I have a usb hub that does not support the sticks at 450mhz and I would like to leave these with a smaller mhz, but cgminer tries to keep increasing the frequency to the programmed 450mhz.

Can't check it myself right now, but there are some options to make cgminer not connect to all sticks, but only certain ones. Then run a different instance of cgminer for each set of sticks (or one for each hub / however you 'cluster' your sticks), specifying the frequency and other settings you want to apply to this selection of sticks. You could even optimize every stick on its own and run one instance per chip to get best results.

[...]
--usb <arg>         USB device selection
[...]
--gekko-serial      Detect GekkoScience Device by Serial Number

[jack1cryptotalk007]

Mine is showing 28:14 for the 450mhz sticks and 38:19 for the 330mhz one

Are these numbers ok? Is there anything to configure to improve this?

(28:14) indicate it take longer time to complete a hashing task (hashing a block header data), which is running slower.
Now, it needs a fast computer to speed up processing, like 8 cores, 16 cores, R7 5800, 6800, R9 5950, threadripper, etc.

(task_ms : scan_ms)  
task_ms:  complete a task, time in mill seconds, a average speed measure
scan_ms:  usb stick or compacF  given specific time gap to complete a task.  hashrate higher, this gap time is smaller.

(7:14) or (14:14) indicate the computer can complete a task cycle within usb stick specified time gap, which mean
computer's speed matches usb stick's speed. More sticks need more CPU power.

[NotFuzzyWarm]

^^ Please learn how to use quotes correctly... You've been here long enough to know how to not make the entire post look like a quote.
As for the CPU stuff... unless you are running dozens of sticks from 1 computer a RasPi does just fine.

[BiticaMan]

Mine is showing 28:14 for the 450mhz sticks and 38:19 for the 330mhz one

Are these numbers ok? Is there anything to configure to improve this?

(28:14) indicate it take longer time to complete a hashing task (hashing a block header data), which is running slower.
Now, it needs a fast computer to speed up processing, like 8 cores, 16 cores, R7 5800, 6800, R9 5950, threadripper, etc.

(task_ms : scan_ms)  
task_ms:  complete a task, time in mill seconds, a average speed measure
scan_ms:  usb stick or compacF  given specific time gap to complete a task.  hashrate higher, this gap time is smaller.

(7:14) or (14:14) indicate the computer can complete a task cycle within usb stick specified time gap, which mean
computer's speed matches usb stick's speed. More sticks need more CPU power.

Thank you for the informations.
I'm adjusting my sticks now, I managed to make them work on the usbs that were disabled before, it was a problem with the current, adjusting with the screw behind the stick was possible to solve the problem.

About the parameter (28:14) I realized that it is related to the mhz, because the higher the frequency, the lower this value is, is this correct?

[BiticaMan]

^^ Please learn how to use quotes correctly... You've been here long enough to know how to not make the entire post look like a quote.
As for the CPU stuff... unless you are running dozens of sticks from 1 computer a RasPi does just fine.

I'm using a PI4b with 8gb of memory, I also have 11 compacF and will have 15 in total soon.
Is it coherent to use like this? From my research on the forum, I would be right.

[kurutoga]

For reference, I'm running three sticks on a pi with the following metrics:

• Stick 1: 335 MHz (38:19)
• Stick 2: 400 MHz (32:16)
• Stick 3: 400 MHz (32:16)

My first time hearing about this setting, so I am also curious if it's a problem that the computer can't process a task within the USB's task time? Or if I am understanding that correctly. What is a use case for the numbers?

[cygan]

✂
CGMiner Frequency setting
✂
To run it at a higher frequency, add on to the commands above e.g.

 --gekko-compacf-freq 400

✂

if i run this command do i change the power on all compac f miners connected to one usb hub or just one?

[jack1cryptotalk007]

For reference, I'm running three sticks on a pi with the following metrics:

• Stick 1: 335 MHz (38:19)
• Stick 2: 400 MHz (32:16)
• Stick 3: 400 MHz (32:16)

My first time hearing about this setting, so I am also curious if it's a problem that the computer can't process a task within the USB's task time? Or if I am understanding that correctly. What is a use case for the numbers?

It just indicates the performance issue, which process (hashing out) less block header data within the expectation of usb stick's capability. Then, chance to hit a BTC is reduced. (32:16) indicate, it took 32 milliseconds average time to process a header data. (8:16) indicate, it took 8 milliseconds average time for hashing process (sub tasks: check status of usb stick and process, obtain header data, format data, write data to usb stick, etc). Sometime, checking usb status cost time when usb stick does not work well.
 
cgminer is an multiple threads program. More usb sticks are used, more process threads will be created and running there, which compete limited system resources. You can test if a PI 4 computer can handle how many of compacf sticks without impact the performance of whole system to achieve (8:16).

 

[BiticaMan]

For reference, I'm running three sticks on a pi with the following metrics:

• Stick 1: 335 MHz (38:19)
• Stick 2: 400 MHz (32:16)
• Stick 3: 400 MHz (32:16)

My first time hearing about this setting, so I am also curious if it's a problem that the computer can't process a task within the USB's task time? Or if I am understanding that correctly. What is a use case for the numbers?

It just indicates the performance issue, which process (hashing out) less block header data within the expectation of usb stick's capability. Then, chance to hit a BTC is reduced. (32:16) indicate, it took 32 milliseconds average time to process a header data. (8:16) indicate, it took 8 milliseconds average time for hashing process (sub tasks: check status of usb stick and process, obtain header data, format data, write data to usb stick, etc). Sometime, checking usb status cost time when usb stick does not work well.
 
cgminer is an multiple threads program. More usb sticks are used, more process threads will be created and running there, which compete limited system resources. You can test if a PI 4 computer can handle how many of compacf sticks without impact the performance of whole system to achieve (8:16).

 

Can you get to 8:16 with 400mhz?

I see that when I increase the mhz this value 28:14 is decreased, however the lower the mhz this value gets higher.
If so, it's not the system alone that leaves this value lower, but how much mhz you can leave in your compacF?

[jack1cryptotalk007]

For reference, I'm running three sticks on a pi with the following metrics:

• Stick 1: 335 MHz (38:19)
• Stick 2: 400 MHz (32:16)
• Stick 3: 400 MHz (32:16)

My first time hearing about this setting, so I am also curious if it's a problem that the computer can't process a task within the USB's task time? Or if I am understanding that correctly. What is a use case for the numbers?

It just indicates the performance issue, which process (hashing out) less block header data within the expectation of usb stick's capability. Then, chance to hit a BTC is reduced. (32:16) indicate, it took 32 milliseconds average time to process a header data. (8:16) indicate, it took 8 milliseconds average time for hashing process (sub tasks: check status of usb stick and process, obtain header data, format data, write data to usb stick, etc). Sometime, checking usb status cost time when usb stick does not work well.
 
cgminer is an multiple threads program. More usb sticks are used, more process threads will be created and running there, which compete limited system resources. You can test if a PI 4 computer can handle how many of compacf sticks without impact the performance of whole system to achieve (8:16).

 

Can you get to 8:16 with 400mhz?

I see that when I increase the mhz this value 28:14 is decreased, however the lower the mhz this value gets higher.
If so, it's not the system alone that leaves this value lower, but how much mhz you can leave in your compacF?

Yes.  my one is (5:21) for a compac f stick at 300 Mhz for 321 GH/s  hashrate.  I post a  screenshot here on this link   https://postimg.cc/HjNM70bK

[Powell]

I'm saying this in the nicest way possible and I verified with the man, the myth, the legend Kano the information you are asking about aka the numbers after T/P which in your case are (32:16), etc. is not something to be worried about.  Jack is new to Mining and does not know that for years (I'm talking back to 2014) the Raspberry Pi has been the control board for many miners.  Hell the older Avalons products used a modified OpenWRT firmware on TINY TP-Link hardware.  Bitmain used a custom board that ran the same OpenWRT firmware as well.  KNC used the Beagle Bone Black on the Saturn, Jupiter, Neptune and they swapped to the Pi on their Ltc miner.  The only OS regardless of hardware that will give you issue (and I can verify because I've tested myself on both a 3950X and 5950X) is Windows and it's poor I/O performance in the case of handling USB miners.  

Please refer back to my posts if you want to see screenshots but at 575MHz (on both T/P) which shows (22:11) pulling less than 3A per stick to keep the USB ports happy.  The first and only person to hit a block with a CompacF also shows the same.  I know people do not like reading 50+ pages of posts but if you are new to mining or never used something that didn't come with a preinstalled OS that you just plop your pool info in.  You really need to spend time reading that.  Every single question that's been asked has been covered already in this post and most are just information pulled from the other Gekkoscience product threads.

I have 12 sticks running across 4 Gekko hubs, Apache running to view miner.php, etc. my CPU usage on my Pi 4 with 8gigs is 80% but it has NO issue handling data.  Memory usage is 0.  If you have ever used any other miner and could run "top" to see CPU usage you would be surprised that all run about the same.

[cygan]

finally, my new solo mining farm is rollin'
on the left you can see a tritron case from cryptocloaks in which 2 rpi4 (8gb ram) are installed. on one of them the umbrel node is running and on the other raspberry the solo mining is running

Code:

cgminer version 4.12.0 - Started: [2022-08-01 14:43:37.792]
--------------------------------------------------------------------------------
 (5s):822.2G (1m):857.2G (5m):700.9G (15m):381.3G (avg):678.8Gh/s
 A:96356  R:0  HW:80  WU:9495.3/m
 Connected to de.kano.is diff 442 with stratum as user xxx
 Block: 3adf72bb...  Diff:27.7T  Started: [14:49:29.331]  Best share: 40.2K
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: GSF 10051796: BM1397:01+ 500.00MHz T:500 P:497 (25:13)  |  100% WU:^94% | 285.6G / 246.6Gh/s WU:3446.7/m
 2: GSF 10051619: BM1397:01+ 500.00MHz T:500 P:500 (25:13)  |  100% WU:100% | 372.8G / 299.2Gh/s WU:4181.4/m
 3: GSF 10051622: BM1397:01+ 430.00MHz T:500 P:426 (29:15)  |  100% WU:^69% | 248.3G / 155.6Gh/s WU:2173.6/m

[kurutoga]

Nice setup cygan. How did you get the Noctua fans to cool the chips at high frequency? I installed one of each on my sticks, but the fan wasn't powerful enough to keep it cool. Is there software/hardware that can be used to manipulate the fan speed?

[cygan]

@kurutoga
so for now i have no further problems with the cooling ... only somehow the one compac f miner always goes back down to its 200mhz. what could it be?

Code:

3: GSF 10051622: BM1397:01+ 200.00MHz T:170 P:43  (64:32)  | 21.2% WU:^44% | 28.20G / 46.01Gh/s WU: 642.8/m

the other two miners remain steady at 500mhz
and i have one more question... is it possible to change the performance of the miner during mining (without interrupting it)?

edit: now this miner has now even gone down to 170mhz...

Code:

[2022-08-01 18:13:48.508] 3: GSF 3 - 31.93GH/s low [134.40/107.52/140] reset limit 200.00MHz -> 190.00MHz
[2022-08-01 18:13:48.564] 3: GSF 3 - new frequency 200.00MHz -> 170.00MHz

[Powell]

@kurutoga
so for now i have no further problems with the cooling ... only somehow the one compac f miner always goes back down to its 200mhz. what could it be?

Code:

3: GSF 10051622: BM1397:01+ 200.00MHz T:170 P:43  (64:32)  | 21.2% WU:^44% | 28.20G / 46.01Gh/s WU: 642.8/m

the other two miners remain steady at 500mhz
and i have one more question... is it possible to change the performance of the miner during mining (without interrupting it)?

edit: now this miner has now even gone down to 170mhz...

Code:

[2022-08-01 18:13:48.508] 3: GSF 3 - 31.93GH/s low [134.40/107.52/140] reset limit 200.00MHz -> 190.00MHz
[2022-08-01 18:13:48.564] 3: GSF 3 - new frequency 200.00MHz -> 170.00MHz

Very nice setup btw!  If you have one stepping down it is because it is having trouble keeping up with that frequency and its a flag setup in the drivers so it can try to keep the stick mining by stepping down the Frequencies, this is fairly simple to fix thankfully if you have a USB voltage reader.  The sticks from the factory are tested at only 400MHz anything after if it doesn't work right off the bat you have to adjust the voltage regulator on the stick.  I personally do it with every stick so that I can keep each USB port under 3A at the frequency I am running it.  There is a few post on here with how to adjust and remember follow like it says, a small change on the POT can be a pretty big swing on power to the stick.  

You can make the adjustment and start CGminer again and you are trying to keep % and WU: % pretty much as close to 100% on both, but when T: 500 and P: 500 you want both to be at 100% WU: 100%.  During the start of the sticks it ramps up the power which is why those numbers will fluctuate and there is some information by Kano and Sidehack in here about it.  It'll drop here and there as P rises toward T (target) which in your case is 500MHz.  But if it does downclock itself the only way I know to reset the process is just to restart CGminer.  

I have used the Noctua's like Cygan has and some of mine still have them on with the 3d printed adapter.  Mine were just powered via 3pin fan connectors as they come from the factory.  They worked very well at 500Mhz-525MHz and I had 6 of them running across 2 Gekko Hubs.  As I got more sticks I decided to just use 120MM fans up top to cool them down because I saw the same performance and it was much cheaper than buying 6 more Noctua's when I have a TON of 120mm fans laying around from other builds.

[cygan]

✂
You can make the adjustment and start CGminer again and you are trying to keep % and WU: % pretty much as close to 100% on both, but when T: 500 and P: 500 you want both to be at 100% WU: 100%.  During the start of the sticks it ramps up the power which is why those numbers will fluctuate and there is some information by Kano and Sidehack in here about it.  It'll drop here and there as P rises toward T (target) which in your case is 500MHz.  But if it does downclock itself the only way I know to reset the process is just to restart CGminer.  
✂

restarting cgminer helped - i took the opportunity and set my 3 sticks to 525mhz

Code:

0: GSF 10051796: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 277.8G / 304.0Gh/s WU:4246.5/m
1: GSF 10051619: BM1397:01+ 525.00MHz T:525 P:525 (24:12) |  100% WU:100% | 312.6G / 330.4Gh/s WU:4615.9/m
2: GSF 10051622: BM1397:01+ 525.00MHz T:525 P:524 (24:12) |  100% WU:100% | 347.0G / 298.6Gh/s WU:4171.9/m

✂
and i have one more question... is it possible to change the performance of the miner during mining (without interrupting it)?
✂

 

[kano]

✂
and i have one more question... is it possible to change the performance of the miner during mining (without interrupting it)?
✂

No.

Mining is a purely random event, restarting it has no effect other than a few seconds down time.