GekkoScience has a new stickminer that does 300+GH

[sidehack]

The little screw/knob in the bottom corner, turn it clockwise just a little. Factory spec is 1.48V but the full range is about 1.40 to 1.60 volts so there's plenty of headroom. A little goes a long way - we saw a measurable increase in burn-in test performance from changing the default setpoint of 1.44 to 1.48

Rule of thumb with cooling is literally a rule of thumb. If it hurts to put your thumb on the heatsink, you need more cooling.

The controller is whatever USB host computer thing you're running on. That shouldn't be a problem with only three sticks; a basic Pi can handle more than that load.

[n0nce]

Rule of thumb with cooling is literally a rule of thumb. If it hurts to put your thumb on the heatsink, you need more cooling.

For indeterminate amount of time? Or just quick touch?

The controller is whatever USB host computer thing you're running on. That shouldn't be a problem with only three sticks; a basic Pi can handle more than that load.

It's worth mentioning / repeating that Windows hosts tend to cause more trouble with USB miners than Linux hosts.

[sidehack]

If it hurts, more cooling.

And yes, Windows generally sucks at USB IO and realtime tasks. The factory tests exclusively on linux machines. Kano's code is written for linux and ported to Windows to make people happy, but it's not ideal.

[cygan]

The little screw/knob in the bottom corner, turn it clockwise just a little. Factory spec is 1.48V but the full range is about 1.40 to 1.60 volts so there's plenty of headroom. A little goes a long way - we saw a measurable increase in burn-in test performance from changing the default setpoint of 1.44 to 1.48
✂

okay, thanks for the tip.
how far can i turn the small screw - can it fall out at some point?

[os2sam]

The little screw/knob in the bottom corner, turn it clockwise just a little. Factory spec is 1.48V but the full range is about 1.40 to 1.60 volts so there's plenty of headroom. A little goes a long way - we saw a measurable increase in burn-in test performance from changing the default setpoint of 1.44 to 1.48
✂

okay, thanks for the tip.
how far can i turn the small screw - can it fall out at some point?

A little goes a long way

If a stick's running slowly, adjust the voltage up a little bit by turning the pot screw in the bottom corner clockwise just a little bit.

[sidehack]

No it can't fall out, it's a fixed rotating knob. If you spin it too far, it just starts back over at the beginning. It's basically a tiny volume knob but without stop-blocks at each end.

[cygan]

No it can't fall out, it's a fixed rotating knob. If you spin it too far, it just starts back over at the beginning. It's basically a tiny volume knob but without stop-blocks at each end.

kk
will continue to try my luck until i have also bring my last ferarri to 570mhz

[jack1cryptotalk007]

No it can't fall out, it's a fixed rotating knob. If you spin it too far, it just starts back over at the beginning. It's basically a tiny volume knob but without stop-blocks at each end.

kk
will continue to try my luck until i have also bring my last ferarri to 570mhz

It won't help you too much by only inrease compacF's freq. The maximum freq in cgminer for compacF can be 800 MHz. But, there are drawback in doing so:
1. the numbers of hashed local block header data won't be increased significantly by incresed freq. We want more block header data to be hashed in per seconds. There is some bottleneck to limit effect of freq increase.
2. heat will be increased significantly, which may cause burning of chip.
3. (5:14) or (14:14) or (28:14) indicator as I post before, will more significantly affect the number of hashed block header data than freq does. So, keeping (5:14)  status is better than increasing freq.  
4. Increasing freq won't increase output of found nonces, and won't increase quality nonces (which has higher diff), this is the key to success in mining. We want the nonce which can reach the target or higher diff.  Now, too many nonces with below 10k difficulty.
5. Higher freq will produce more failed nonces which can not pass 1st test under asic boost mode. ASIC boost mode in BM1397 chip may limit the quality of nonces.  I turn off asic boost, and got more quality nonce or more higher diff nonces. I set freq at 350MHZ and got 320 GH/s. No nned higher freq.

6. There are more aspects which will affect the quality of mining BTC.

[cygan]

the problem i have is that i can't get all 3 comapc miners to run at the same number of mhz at the same time
once only 2 miners get to the 570mhz and when i restart cgminer only the third one gets to the 570mhz and the others are somehow at 300-400mhz and then restart at some point to 200mhz
so from this point of view, all 3 miners are set correctly, because otherwise they wouldn't reach the 570mhz - but what is the problem, that not all 3 miners reach 570mhz or 550mhz at the same time?

[jack1cryptotalk007]

the problem i have is that i can't get all 3 comapc miners to run at the same number of mhz at the same time
once only 2 miners get to the 570mhz and when i restart cgminer only the third one gets to the 570mhz and the others are somehow at 300-400mhz and then restart at some point to 200mhz
so from this point of view, all 3 miners are set correctly, because otherwise they wouldn't reach the 570mhz - but what is the problem, that not all 3 miners reach 570mhz or 550mhz at the same time?

you can try to insert  --gekko-compacf-freq 580 --gekko-start-freq 580   into cmd.

set start-freq also at 580.

if one stick always fail to get computed freq to close 575 mhz after running 1 hour, then, that stick got problem for sure.
when freq is higher, the stick is more steady.  

Another way, edit code, stop reducing freq for stick.  There is a logic problem in code, it often reduce set freq or reduce requested freq.  Then, freq is going down and never coming up.

[cygan]

okay, i have now started my 3 gekko compac f miner with the following command:

Code:

./cgminer -o stratum+tcp://de.kano.is:3333 -u cryptocygan.worker -p x --suggest-diff 442 --gekko-mine2 --gekko-tune2 60 --gekko-compacf-freq 555 --gekko-start-freq 555

i am now curious how long all 3 miners will run at this mhz

Code:

0: GSF 10051796: BM1397:01+ 555.00MHz T:555 P:547 (5:12) |  100% WU:100% | 316.0G / 335.4Gh/s WU:4684.9/m
1: GSF 10051622: BM1397:01+ 555.00MHz T:555 P:528 (5:12) | 71.8% WU: 67% | 181.4G / 195.0Gh/s WU:2724.8/m
2: GSF 10051619: BM1397:01+ 555.00MHz T:555 P:0   (5:12) |  100% WU:100% | 395.6G / 400.5Gh/s WU:5602.4/m

edit: did not take long and the first miner was disabled

Code:

[2022-08-29 17:22:24.488] GSF 1 failure, disabling!
[2022-08-29 17:22:24.492] 1: GSF 1 - usb failure (-9)
[2022-08-29 17:22:31.153] 3: GSF 3 - CompacF Bitcoin Miner (10051622)
[2022-08-29 17:22:31.153] Hotplug: GekkoScience added GSF 3

[jack1cryptotalk007]

okay, i have now started my 3 gekko compac f miner with the following command:

Code:

./cgminer -o stratum+tcp://de.kano.is:3333 -u cryptocygan.worker -p x --suggest-diff 442 --gekko-mine2 --gekko-tune2 60 --gekko-compacf-freq 555 --gekko-start-freq 555

i am now curious how long all 3 miners will run at this mhz

Code:

0: GSF 10051796: BM1397:01+ 555.00MHz T:555 P:547 (5:12) |  100% WU:100% | 316.0G / 335.4Gh/s WU:4684.9/m
1: GSF 10051622: BM1397:01+ 555.00MHz T:555 P:528 (5:12) | 71.8% WU: 67% | 181.4G / 195.0Gh/s WU:2724.8/m
2: GSF 10051619: BM1397:01+ 555.00MHz T:555 P:0   (5:12) |  100% WU:100% | 395.6G / 400.5Gh/s WU:5602.4/m

edit: did not take long and the first miner was disabled

Code:

[2022-08-29 17:22:24.488] GSF 1 failure, disabling!
[2022-08-29 17:22:24.492] 1: GSF 1 - usb failure (-9)
[2022-08-29 17:22:31.153] 3: GSF 3 - CompacF Bitcoin Miner (10051622)
[2022-08-29 17:22:31.153] Hotplug: GekkoScience added GSF 3

for simple run,  try don't want --gekko-mine2  --gekko-tune2 60,  to see how it is going? 
or try to use 525 or 500.

if 1622 stick alway got lower Gh/s,  try to adjust that screw. If still fail, which mean that stick is not good. Quality problem.

Another way, edit code, increse waiting time in read usb command,  use 100 ms instead of 10 ms. This is often cause usb read not work correctly.

[cygan]

okay, i have now started my 3 gekko compac f miner with the following command:

Code:

./cgminer -o stratum+tcp://de.kano.is:3333 -u cryptocygan.worker -p x --suggest-diff 442 --gekko-mine2 --gekko-tune2 60 --gekko-compacf-freq 555 --gekko-start-freq 555

i am now curious how long all 3 miners will run at this mhz

Code:

0: GSF 10051796: BM1397:01+ 555.00MHz T:555 P:547 (5:12) |  100% WU:100% | 316.0G / 335.4Gh/s WU:4684.9/m
1: GSF 10051622: BM1397:01+ 555.00MHz T:555 P:528 (5:12) | 71.8% WU: 67% | 181.4G / 195.0Gh/s WU:2724.8/m
2: GSF 10051619: BM1397:01+ 555.00MHz T:555 P:0   (5:12) |  100% WU:100% | 395.6G / 400.5Gh/s WU:5602.4/m

edit: did not take long and the first miner was disabled

Code:

[2022-08-29 17:22:24.488] GSF 1 failure, disabling!
[2022-08-29 17:22:24.492] 1: GSF 1 - usb failure (-9)
[2022-08-29 17:22:31.153] 3: GSF 3 - CompacF Bitcoin Miner (10051622)
[2022-08-29 17:22:31.153] Hotplug: GekkoScience added GSF 3

for simple run,  try don't want --gekko-mine2  --gekko-tune2 60,  to see how it is going? 
or try to use 525 or 500.

if 1622 stick alway got lower Gh/s,  try to adjust that screw. If still fail, which mean that stick is not good. Quality problem.

Another way, edit code, increse waiting time in read usb command,  use 100 ms instead of 10 ms. This is often cause usb read not work correctly.

so only the 1622 makes me some problems...
have him first switched off and will then try to adjust correctly by turning the screw
how and where can i change the read code in an extreme case and as a last option?

[jack1cryptotalk007]

so only the 1622 makes me some problems...
have him first switched off and will then try to adjust correctly by turning the screw
how and where can i change the read code in an extreme case and as a last option?

1.  To adjust that screw,  you need to get two Keweisi USB testers, google it.
Then, you can watch two sticks what voltage and current are with both sticks when they are running.  When you adjust one stick, you can see current change and frequeency change on the stick.
 
2. Modify code. enter ubuntu, git clone kano's cgminer. Then, use Microsoft code. Find code: driver-gekko.c.  in compac_listen() and compac_lisyten2() functions.
(1). Search ' usb_read_timeout( ' , modify waiting constant inside this sentence.
(2). Search ' tmo = ',  modify tmo = 100; or tmo = 200.

re-compile cgminer. then, etc .......

[cygan]

@jack1cryptotalk007
to adjust the screw the stick must be pulled out or can the whole thing be done during mining?

[jack1cryptotalk007]

@jack1cryptotalk007
to adjust the screw the stick must be pulled out or can the whole thing be done during mining?

when stick is mining, do adjust screw. Watching usb tester display voltage and current, turning screw, tuning frequeucy dynamically, watching computer screen (see effect).

[kano]

...
4. Increasing freq won't increase output of found nonces, and won't increase quality nonces (which has higher diff), this is the key to success in mining. We want the nonce which can reach the target or higher diff.  Now, too many nonces with below 10k difficulty.
5. Higher freq will produce more failed nonces which can not pass 1st test under asic boost mode. ASIC boost mode in BM1397 chip may limit the quality of nonces.  I turn off asic boost, and got more quality nonce or more higher diff nonces. I set freq at 350MHZ and got 320 GH/s. No nned higher freq.
...

Ah sorry, this isn't correct.

There's no such thing as making changes to get better 'quality' nonces.

If it mines twice as fast it will get twice as many nonces.
Due to Proof of Work, you expect that twice as many nonces will have, on average, twice as many of those nonces above any given difficulty.

This result can be achieved by either 1) mining twice as fast or 2) mining with twice as many miners at the same speed.

The ticket mask decides which nonces the chip returns and I set that to 16.
If you set it to 32, you'd get half as many nonces in the same time, with the same average expected difficulty.
Setting it higher just reduces the amount of data that travels back from the chip to cgminer by intercepting it.
It has no effect on the 'quality' of the data, it just affects the average difficulty of the data by removing the lower difficulty nonces from the returned data, the chip still generates this data, it's just removed from the returned data, i.e. less data returned.

Read here, coz it would appear you may not understand the meaning of difficulty: https://kano.is/index.php?k=workdiff

All mining is simply based on the fact that if you hash some data, 1 in 2^32 hashes will, on average, start with 32 zero bits.
1 in 2^16 hashes will, on average, start with 16 zero bits.
1 in 2^96 hashes will, on average, start with 96 zero bits.
Asic-boost uses the idea that some of the hash processes can be reused for another hash, meaning the hash process is shorter in this case i.e. sometimes you can do the whole hash process a bit faster.
It has zero effect on the value of the hash.

[jack1cryptotalk007]

The ticket mask decides which nonces the chip returns and I set that to 16.
If you set it to 32, you'd get half as many nonces in the same time, with the same average expected difficulty.
Setting it higher just reduces the amount of data that travels back from the chip to cgminer by intercepting it.
It has no effect on the 'quality' of the data, it just affects the average difficulty of the data by removing the lower difficulty nonces from the returned data, the chip still generates this data, it's just removed from the returned data, i.e. less data returned.

Read here, coz it would appear you may not understand the meaning of difficulty: https://kano.is/index.php?k=workdiff

All mining is simply based on the fact that if you hash some data, 1 in 2^32 hashes will, on average, start with 32 zero bits.
1 in 2^16 hashes will, on average, start with 16 zero bits.
1 in 2^96 hashes will, on average, start with 96 zero bits.
Asic-boost uses the idea that some of the hash processes can be reused for another hash, meaning the hash process is shorter in this case i.e. sometimes you can do the whole hash process a bit faster.
It has zero effect on the value of the hash.

1. I believe that the ticket mask is no need at all. does it filt nonce output within BM1397 chip as its internal function? or just the code in cgminer do filter? It makes code more complex and cost CPU time, too.  Only threshold setup within BM1397 chip, may help to reduce number of ouput nonce with more quality nonces output. One block headers only produce 0 to 3 nonces in average running.
 
2. I observed total nonces come from asic chips and total nonces pass 1st test, and total nonces fail to pass 1st test. I found that a lot of nonces which are from asic chips fail to pass 1st test in test_nonce() function under ASIC boost mode. Which should not happen, I believe. And this indicate ASIC boost mode can output bad nonces (or less quality nonce).
 
3. sha256 algorithm is very sensitive to input message. So those midstates will produce error and cause bad nonces output for sure. I believe, turning off some midstate will help the quality of output nonces, which will increase of expectation of hitting bitcoin.

4. " 1 in 2^32 hashes will, on average, start with 32 zero bits.",  a lot of miners have done this amount 2^32 of hashing, but, they won't get a 32 zero hash value. This saying is aganist my observation in years. There is always some area (sub-space of sha256 space) hide more quality nonces which can produce better (or smaller) hash values. I called these nonces as quality nonces. I often observed some miners can resolved a bitcoin under 30 seconds.  I think they may have few or some universal or nearest universal nonces. Otherwise, it is against the your logic (or theory). In fact, small home miners need few universal nonces to beat big miners, I believe.

[sidehack]

Fix your quotes, dude.

1, yes ticket mask is internal to the ASIC. Like he said, only nonces above the ticket mask are put into the stream of data coming back from the chip. It's similar to how cgminer will get a pool diff, so only nonces above that value will be forwarded to the pool server.

2. When you testd nonces, did you give it all of the appropriate data? ASICBoost uses an additional data field not previously implemented (left as zeroes I believe) in order to generate multiple midstates simultaneously from the same data. If you're not integrating that into the hash, most of your nonces would test bad because you're testing with incomplete data. This explanation is probably insufficient and Kano can tell you more.

3. Sounds like a CRC issue

4. If SHA256 had universal nonces, wouldn't that invalidate the algorithm as cryptographically secure and make exploitation trivial?

[kano]

...

To everything you said: No.

My post is facts. I'm not guessing anything.
Not much point trying to tell me I don't know what I'm saying when I know exactly how it all works from the ground up.
I've been writing drivers and code in cgminer since 2011.
Read my previous post - that's correct.

Your anecdotal data with bad code doesn't mean anything except that you misunderstand the data and have buggy code.