GekkoScience 2Pac/Compac BM1384 Stickminer Official Support Thread

[vh]

Directly plugged in, but I figure the port can't handle it. will go out and look to buy a powered usb hub tomorrow.
It works, ran for nearly 18hrs before it dropped off.

On windows, disable this setting in the advance power options in the control panel if your PC is constantly on, just in case:

[gt_addict]

So ive done the following and it will run the Green compac I have but does not recognise the bitshopper compacs. Just comes up with "usb init failed"  

did you do the following...

Code:

cd ~/git/vthoang/cgminer/
sudo usermod -G plugdev -a `whoami` #whoami=pi if you did not change it
sudo cp 01-cgminer.rules /etc/udev/rules.d/
sudo reboot

it is right there in my prior post.
I don't see you quoting this.
When I did not do this, I also got "usb init failed".
EDIT: this is only so if you are actually talking about 2pacs. Original black Compac (not 2pac) is a whole another situation that vh is fixing, apparently.

I havent done that part yet as the fiest time i did it didnt seem to do anything just moved down a line woth the same root(?) ~/git/vthoang/cgminer/ without loading anything, so third time round i didnt do it.

But yes i am talking about the single chip bitshopper compacs.

[ppetrovic68]

It's possible VH's driver doesn't recognize the bitshopper product string. Reckon we'll need to get that fixed here directly since I'm working on bitshopper 2Pacs right now.

hmm... yes it is very possible I didn't finish connecting the dots there.  99.2% likely.
I'll add it shortly.

vh, how hard would it be to have "--enable-icarus" and "--enable-gekko" play nicely?

If I'm not mistaken make fails with double defined macros or something like that. If that's the only problem it should be easy to fix, right?

And if icarus driver could be tweaked not to accept Compacs and 2Pacs, that would be great

[Biodom]

So ive done the following and it will run the Green compac I have but does not recognise the bitshopper compacs. Just comes up with "usb init failed"  

did you do the following...

Code:

cd ~/git/vthoang/cgminer/
sudo usermod -G plugdev -a `whoami` #whoami=pi if you did not change it
sudo cp 01-cgminer.rules /etc/udev/rules.d/
sudo reboot

it is right there in my prior post.
I don't see you quoting this.
When I did not do this, I also got "usb init failed".
EDIT: this is only so if you are actually talking about 2pacs. Original black Compac (not 2pac) is a whole another situation that vh is fixing, apparently.

I havent done that part yet as the fiest time i did it didnt seem to do anything just moved down a line woth the same root(?) ~/git/vthoang/cgminer/ without loading anything, so third time round i didnt do it.

But yes i am talking about the single chip bitshopper compacs.

it does not do something visible, it just allows you to run cgminer executable (./cgminer) in ~/git/vhoang/cgminer folder without the use of sudo, but it is less relevant here since you are not using 2pacs, which i thought that you are since this is a 2pac thread.
Also, you don't need to do this more than once, of course.
Nevermind.

[gt_addict]

That makes sense. Thanks Biodom. Its running my single green compac now so i am hoping once vh updates it (and hopefully provides lamens terms to update the current version ive got  ) then ill be ready to go for when my 2pacs get here 

[vh]

New build is available (b756f23).   git pull and build as time permits.

- Supports bitshopperde compacs.
- Can now combine --enable-icarus --enable-gekko
- Auto recover attempts from usb write error.

Latest windows binary:
http://23.108.83.14/images/cgminer-4.10.0-windows-gekko-b756f23.7z

[vh]

That makes sense. Thanks Biodom. Its running my single green compac now so i am hoping once vh updates it (and hopefully provides lamens terms to update the current version ive got  ) then ill be ready to go for when my 2pacs get here 

Here's how to grab the update:

Code:

cd ~/git/vthoang/cgminer/
git pull
make -j 2

./cgminer -o stratum+tcp://solo.ckpool.org:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 32

Adjust that last line as needed.

[vh]

vh, how hard would it be to have "--enable-icarus" and "--enable-gekko" play nicely?

Pull the latest code and have at it.

And if icarus driver could be tweaked not to accept Compacs and 2Pacs, that would be great

Nope.   

Use the -n flag and --dev flag in cgminer to select the device you want.

Use --enable-gekko to support the Compacs and 2Pacs.

[gt_addict]

That makes sense. Thanks Biodom. Its running my single green compac now so i am hoping once vh updates it (and hopefully provides lamens terms to update the current version ive got   ) then ill be ready to go for when my 2pacs get here  

Here's how to grab the update:

Code:

cd ~/git/vthoang/cgminer/
git pull
make -j 2

./cgminer -o stratum+tcp://solo.ckpool.org:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 32

Adjust that last line as needed.

Superb!! Thanks vh. I'll do the update after work.

Edit: just did the update as i had five minutes. Works a treat   

[MrZoidberg]

Hello, sorry for the noob questions.

1. What is the significance of the -p x flags?
2. When using ckpool, what is the benefit of specifying --suggest-diff 32

Thanks!

[sidehack]

-o is the pool, -u is the username, -p is the password. Most pools don't require a specific password but it's there just in case, so most people just use something generic like "x" or "123". Some pools use the password field to pass in additional parameters for multi-coin or leasing rigs and whatnot.

Since most pools expect you to run a multi-terahash miner but these guys are, at best, about 40GH, the initial diff threshold the pool gives will be ridiculously too high - a lot of them now start at 4000 or so. --suggest-diff tells the pool to start at a lower number so it can more quickly and accurately gauge the actual mining speed of your sticks.

[MrZoidberg]

Awesome, thanks! So if I'm using a 2PAC, --suggest-diff 32 would be appropriate?

Also, on ckpool, they quote the numbers "shares", "bestshare" and "bestever". What is the significance of these?

Thanks again.

[sidehack]

Shares are what you're sending to the pool. It's the result of the hashing calculation. The diff you get from the pool is a share value threshold below which cgminer doesn't bother to send that share to the pool. This keeps down traffic, since if a pool accepted every value-1 share bandwidth requirements would be through the roof with modern high-hashrate miners. Your returned shares could have a value in the millions or billions; this is statistically unlikely but it does happen on occasion. The more hashrate you have, the more likely you are to return higher shares, so the higher the pool's discard threshold gets. Every share is weighted by that threshold and summed up (that's the "A" field in cgminer's display, means Accepted), and that's what is used to determine your mining payout because it's a representation of how much work you're doing. Shares are all weighted by that diff value but every individual share could have a different value (which is reported in cgminer when a share is accepted). The only share that actually matters is the one over network difficulty, which is the one that makes a block. The rest are just used to divvy up the block payout to everyone in the pool.

So "shares" is the total number of shares you've submitted, "bestshare" would be the highest-value share you submitted in the current round (?) and bestever would be the highest-value share ever submitted under your mining account. They're not really used for any payout calculations or anything (except total shares, indirectly), but some people like to know that info.

[lanegg]

This seemed too easy and I am doubting myself. Are these hash rates correct?

https://i.imgur.com/ocRhwRl.png

I know I've overclocked the sticks to 250mhz so technically no longer supported, but I thought the max was 15gh/s? Or is that just the CYA max?

Also, how do I check what the vcore is as referenced in the graphs in vh's OP here? I have seen references and pictures of the potentiometer but I haven't seen a ELI5 on how it works, which apparently I need...

[vh]

This seemed too easy and I am doubting myself. Are these hash rates correct?



I know I've overclocked the sticks to 250mhz so technically no longer supported, but I thought the max was 15gh/s? Or is that just the CYA max?

Also, how do I check what the vcore is as referenced in the graphs in vh's OP here? I have seen references and pictures of the potentiometer but I haven't seen a ELI5 on how it works, which apparently I need...

Yes it's correct, but it's about 10% off due to the amount of HW errors the chips are throwing out. 
I deleted the word max in my example, its meaning was in reference to the highest you'll see for that specific frequency.

[vh]

Also, how do I check what the vcore is as referenced in the graphs in vh's OP here? I have seen references and pictures of the potentiometer but I haven't seen a ELI5 on how it works, which apparently I need...

In case you aren't, keep some air flowing across them to keep the chips from overheating at that frequency.

If you intend to stay at 250MHz, you can turn the potentiometer lightly clockwise until the HW error on that stick stop increasing.  

Otherwise, for best results, lower the frequency until all four shows HW:0; until you have a way to measure core voltage or overall amperage.    

[sidehack]

Look at your WU number for a practical reference of how much work is being done. I believe the hashrate is calculated statistically off the rate of share returns, but the WU (work units) is a reflection of the actual data being processed. For 100MHz you should see about 150, so 250MHz is 2.5 times that at around 380. If everything's working as expected, your HW will be zero and WU will be a lot higher.

Hashrate (GH) is calculated as 0.11 times frequency (MHz), so 100MHz gets 11GH and 250 should see 27.5GH. At that frequency, you need a core voltage about 700mV (1.4V device-level). The stock voltage is about 620mV, good for 150MHz or so. The stock voltage setting, your wiper (the point opposite the flat) is in about 7o'clock position; try turning it to 12o'clock. That should get you close. But as stated, you will definitely need a fan for cooling because the sticks will be drawing about 10W by the time you get them leveled out.

[vh]

When I added in the ticket mask support, the Work Units stop scaling linearly.  

Reduce the WU calculation by a factor of (ticket mask + 1).
250MHz = ticket mask of 3 = WU: 95/m. -edit: fixed

Everything still applies otherwise.

[lanegg]

If you intend to stay at 250MHz, you can turn the potentiometer lightly clockwise until the HW error on that stick stop increasing.

That fixed the HW errors. They are now 0 after running for about 10 minutes. I also backed the throttle down to 225MHz. I have a little USB fan cooling the devices but right after I posted my first reply I got a seg fault that crashed Raspbian and had to hard reboot it ('reboot' command wouldn't actually reboot it, it would just hang). I am not sure if they are related but since I had the devices hashing all night @ 100MHz without issue it seems too coincidental to not be the cause. I'll keep an eye on it for sure.

try turning it to 12o'clock.

I definitely don't have 20 year old eyes anymore but it looks like the dial on the pot has two flat sides. Are you saying I should turn it nearly half way? Clock or counter clock-wise? Is there a way to check what the actual wattage being pulled is (like in the USB management)? I didn't see it on a cursory glance but maybe its something that can be calculated?

Thanks for the support guys!

[lanegg]

I got the kernel panic again. Here is the output that was dumped to the terminal if anyone is curious.

Code:

sudo ./cgminer/cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u lanegg.worker1 -p x --suggest-diff 32 --gekko-2pac-freq 225
 kernel:[ 2411.725280] 7e80: b32b7f0c b32b7e90 80421330 80420098 b32b7ec4 b32b7ea0 3972d000 8085c400
Message from syslogd@pihole at Mar 25 12:15:13 ...193/128 GSD 1
 kernel:[ 2413.803925] bbe0: ffffffff b73258c0 00000000 00000000 80063d84 00000000 00000000 b93fe694
 kernel:[ 2411.733465] 7ea0: b9f89820 b9f8ddc0 808c85b0 80864100 70700568 00000000 b32b7ee4 b32b7ec8
Message from syslogd@pihole at Mar 25 12:15:13 ...143/128 GSD 0
 kernel:[ 2413.812110] bc00: b523bc44 b523bc10 804c50d0 804c4f10 b71be480 00000000 00000000 b73258c0
 kernel:[ 2411.741650] 7ec0: 80028e0c 800da270 00000001 808640a0 00000007 b32b6028 b32b7f4c b32b7ee8
Message from syslogd@pihole at Mar 25 12:15:13 ...2.83K/128 GSD 0
 kernel:[ 2413.820295] bc20: 00000000 b523a000 80063d84 00000000 0000007b b93fe694 b523bc8c b523bc48
 kernel:[ 2411.749836] 7ee0: 80029394 b33e4648 70700568 b33bad80 802c550a 00000013 b32b6000 00000000
Message from syslogd@pihole at Mar 25 12:15:13 ...135/128 GSD 1
 kernel:[ 2413.828481] bc40: 804bdc90 804c5084 024000c0 80557bdc b9258b40 000000db 00000000 b52ba220
 kernel:[ 2411.758021] 7f00: b32b7f1c b32b7f10 80422684 80420e28 b32b7f7c b32b7f20 80169f80 80422678
Message from syslogd@pihole at Mar 25 12:15:13 ...138/128 GSD 2
 kernel:[ 2413.836666] bc60: 00000000 b9317480 000005dc 00000000 00000038 0000004c 00000000 b73258c0
 kernel:[ 2411.766206] 7f20: b32b7f4c b32b7f30 8007d5f0 800d9b28 b9f8ddc0 80175008 aa082a00 70700590
Message from syslogd@pihole at Mar 25 12:15:13 ...564/128 GSD 1
 kernel:[ 2413.844851] bc80: b523bca4 b523bc90 804bdce8 804bdac4 b523bcf4 00000000 b523bd24 b523bca8
 kernel:[ 2411.774392] 7f40: 70700568 00000000 802c550a 00000013 b32b7f6c b32b7f60 b33bad81 70700568
Message from syslogd@pihole at Mar 25 12:15:13 ...204/128 GSD 0
 kernel:[ 2413.853036] bca0: 80516fac 804bdcc0 4559cf63 00000000 b52d2494 00000000 00000038 b523bd40
 kernel:[ 2411.782577] 7f60: b33bad80 802c550a 00000013 b32b6000 b32b7fa4 b32b7f80 8016a1b4 80169b68
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.861222] bcc0: 000005c8 00000003 00000000 00000020 00000000 000005c8 00000014 b523bd50
 kernel:[ 2411.790763] 7f80: 01b18370 70700590 70700468 00000000 00000036 8000fd28 00000000 b32b7fa8
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.869407] bce0: 00000038 000005dc b71d8380 000005dc b523bd24 ffffff97 8051682c 00000040
 kernel:[ 2411.798948] 7fa0: 8000fb60 8016a17c 70700590 70700468 00000013 802c550a 70700568 01b18370
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.877594] bd00: b73258c0 b523bdf0 00000038 80517344 b523bd40 00000000 b523bd94 b523bd28
 kernel:[ 2411.807133] 7fc0: 70700590 70700468 00000000 00000036 00000000 00000000 00004000 00000001
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.885779] bd20: 80518de4 8051685c b93fe694 80517344 b523bedc 00000038 00000008 00000040
 kernel:[ 2411.815319] 7fe0: 76e950ac 718fc5c4 76e84e1c 76d15f2c 60000010 00000013 00000000 00000000
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.893964] bd40: b523bd40 b523bd40 00000000 8056bc48 00000000 00000000 00000000 000005dc
 kernel:[ 2411.869975] Code: e7904001 e3540000 0a00005b e5953014 (e7949003)
Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.902149] bd60: 00000038 b71d8380 ffff0000 8056c432 b73258c0 00000038 b523bedc 00000030

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.910334] bd80: 00000000 b523bdf0 b523be8c b523bd98 80541eb0 80518d30 00000038 00000008

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.918519] bda0: b523bddc b523bdd8 00000040 b523bdb8 805bc7bc 800d9b28 808bb180 00007b00

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.926704] bdc0: 80517344 00000000 00000000 b7325b00 00000000 63cf5945 00000000 63cf5945

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.934889] bde0: 00000000 00000000 ffff0000 00000232 00000002 00000001 00000000 00110000

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.943074] be00: 00000000 8032d670 00000000 00000000 0301a8c0 63cf5945 7b007b00 00000000

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.951259] be20: b523be74 7efaea48 00000000 00000100 b523a0f8 00000000 00000000 8032d8e8

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.959444] be40: b523be7c 80030460 b523be64 b523be58 80030460 8003029c b523be84 b523be68

Message from syslogd@pihole at Mar 25 12:15:13 ...
 kernel:[ 2413.967629] be60: 800311ac b73258c0 00000000 b6a19800 00000122 8000fd28 b523a000 00000000