Search content
Sort by
Showing 9 of 9 results by joz
I had 2 Compac-F's and everything was going fine. I ordered one more (419 mining), added it to the mix (each on an independent gekko usb hub section), and it ran up to just about expected speed, then it started dropping to very low hash, followed by zombie. I went to unplug it and the entire PCB was too hot to touch, had to hot-potato it from the USB-plug end. Never had this experience with my other F's. I unplugged all the miners and just plugged this one in by itself. Same thing happened. The bad news is is that it appears to have taken the gekko hub port-pair with it. Now when I plug a working F into either pair, the light doesn't stay on. If I pull on the miner (as in beginning to take it out) the light stays on, but as soon as I release pressure it turns off.
What recourse do I have here?
What recourse do I have here?
⭐ Merited by n0nce (1)
I am running 7 CompacFs right now on t2 Gekko hubs and my 8th stick does the same as yours. I have played with it and I am not able to get it stable. I finally got fed up with it and I am just runnign the 7 sticks and it is humming along no issues. It just must be silicone lottery.
yettihead
Guys, the silicone lottery is for how good the boob job turns out. For electronics it's the silicon lottery (no 'e')! Just it's like the third time I've seen it wrong in this thread.
FWIW I'm able to run a Compac-F natively off of an Intel NUC (6CAYB - older model) USB port, albeit at ⅔ optimal speed - that being at 350 MHz, where it runs stable at 222 GH/s and pulls 2.4 A
Re: GekkoScience NewPac / Terminus R606 (BM1387) Official Support Thread
Try something like this:
Compiles clean, and should work just fine. Didn't test myself, since not running a node.
Code:
diff --git a/cgminer.c b/cgminer.c
index ece7ce10..ab52e30a 100644
--- a/cgminer.c
+++ b/cgminer.c
@@ -2960,7 +2960,7 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
flags = json_string_value(json_object_get(coinbase_aux, "flags"));
default_witness_commitment = json_string_value(json_object_get(res_val, "default_witness_commitment"));
- if (!previousblockhash || !target || !version || !curtime || !bits || !coinbase_aux || !flags) {
+ if (!previousblockhash || !target || !version || !curtime || !bits) {
applog(LOG_ERR, "Pool %d JSON failed to decode GBT", pool->pool_no);
return false;
}
@@ -3039,10 +3039,12 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
ofs += ser_number(pool->scriptsig_base + ofs, height); // max 5
/* Followed by flags */
- len = strlen(flags) / 2;
- pool->scriptsig_base[ofs++] = len;
- hex2bin(pool->scriptsig_base + ofs, flags, len);
- ofs += len;
+ if (flags) {
+ len = strlen(flags) / 2;
+ pool->scriptsig_base[ofs++] = len;
+ hex2bin(pool->scriptsig_base + ofs, flags, len);
+ ofs += len;
+ }
/* Followed by timestamp */
cgtime(&now);
index ece7ce10..ab52e30a 100644
--- a/cgminer.c
+++ b/cgminer.c
@@ -2960,7 +2960,7 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
flags = json_string_value(json_object_get(coinbase_aux, "flags"));
default_witness_commitment = json_string_value(json_object_get(res_val, "default_witness_commitment"));
- if (!previousblockhash || !target || !version || !curtime || !bits || !coinbase_aux || !flags) {
+ if (!previousblockhash || !target || !version || !curtime || !bits) {
applog(LOG_ERR, "Pool %d JSON failed to decode GBT", pool->pool_no);
return false;
}
@@ -3039,10 +3039,12 @@ static bool gbt_solo_decode(struct pool *pool, json_t *res_val)
ofs += ser_number(pool->scriptsig_base + ofs, height); // max 5
/* Followed by flags */
- len = strlen(flags) / 2;
- pool->scriptsig_base[ofs++] = len;
- hex2bin(pool->scriptsig_base + ofs, flags, len);
- ofs += len;
+ if (flags) {
+ len = strlen(flags) / 2;
+ pool->scriptsig_base[ofs++] = len;
+ hex2bin(pool->scriptsig_base + ofs, flags, len);
+ ofs += len;
+ }
/* Followed by timestamp */
cgtime(&now);
Compiles clean, and should work just fine. Didn't test myself, since not running a node.
Verified that works! Yay solo mining with newpacs on bitcoind v0.21! Thanks 100knot2dae!
Do you want to submit this patch to vh's cgminer? I can also do so if you'd like.
Re: GekkoScience NewPac / Terminus R606 (BM1387) Official Support Thread
Just a heads up that for me, updating from 0.19.0.1 to 0.20.0 bitcoin core gave this error in cgminer 4.11.1, "JSON failed to decode GBT". Im just running the NewPac against local wallet so anyone else doing the same may have trouble if they update the local wallet.
Yes, you are right, I can confirm, core did a change in response of gbt.
This afect not only cgminer (vh) also the original and ckpool.
I switched back to 19.1 and wait for core 0.20.01
I've also been mining solo with NewPacs for a long time. Finally went to upgrade my 0.19.1 node to 0.21 and ran into this. It's still a thing, and core doesn't see it as something to fix on their side (rightfully so, as described in issue 19182). So, I guess the cgminer fork supporting GS miners needs to be updated. @vh is this something you can do? Looks like we just need to not require the coinbaseaux flag in the GBT response.
Re: [14000Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB
Why could[n't] we have the old stats until the new are available!??
He's not just changing the stats. The pool's reward system changed too. The old stats never supported the new reward system.Hey Luke, it says Eligius is one of your projects/didn't I read somewhere that you created it? Could you help out with a temporary stats page if wizkid is too bogged down?
Do you still have a role on the admin side of this pool. Is it all wizkid now?
Re: [14000Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB
...Really 
I fail to see how your post is contributing.
I fail to see how your post is contributing.Allow me to paste it again for you:
At this point it would be somewhat more difficult to go backward, since it would require redoing all servers again.
As mentioned many times, the pool itself is fully functional (as evidenced by our last block), just the front end is not done/working yet.
I'm likely going to just do up a temporary stats front end at the next opportunity just to have some basics available while work is done on the full setup.
As mentioned many times, the pool itself is fully functional (as evidenced by our last block), just the front end is not done/working yet.
I'm likely going to just do up a temporary stats front end at the next opportunity just to have some basics available while work is done on the full setup.
Oh yeah, you're right, totally see the answer there about the pool's hash rate and payout period.
Re: [150+ PH] SlushPool (slushpool.com); World's First Mining Pool
Hi guys. Bitcoin noob here and am trying to mine with a super-joke hash rate, just as a proof of concept/research. I've got a whopping 11 Mh/s off an onboard GPU (haha) connected to slush. It reports accurately and everything. My question is:
If I use this mining calculator with this hash rate, it says I should earn about 4 sathoshi/week. I've been mining at this rate on slush for a week, and even though my stats estimated daily reward says 1 satoshi, my confirmed/unconfirmed reward remains 0. Will I ever get even a satoshi? Is this because I only get that estimated rate applied to blocks found, and so it would build up far slower than 1/day? Is 1/day based on if the pool is constantly finding blocks? Thanks for your help/sorry for the noob question.
If I use this mining calculator with this hash rate, it says I should earn about 4 sathoshi/week. I've been mining at this rate on slush for a week, and even though my stats estimated daily reward says 1 satoshi, my confirmed/unconfirmed reward remains 0. Will I ever get even a satoshi? Is this because I only get that estimated rate applied to blocks found, and so it would build up far slower than 1/day? Is 1/day based on if the pool is constantly finding blocks? Thanks for your help/sorry for the noob question.