[ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 164.

kramble

sr. member

Activity: 384

Merit: 250

Quote from: ?? on ??

Awesome

I think I spoke too soon. Its just started kicking out "H-not-zero" errors and stopped accepting shares (all now being rejected by the pool). Not at a diff change either as we're on block 37207 according to the pool. Restarting cgminer hasn't helped, its just seems broken Sad

Then again, I think its the pool that's died, according to the dashboard.

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 09:48:11 AM

great work are you going to do a build for cm1 and ztex?

Its a common build so it should work on CM1, ztex and lancelot. I've just been testing it on windows today (since the CM1 is currently powered off my win7/64 PC), but I'll do the raspi build and check it out for the ztex and lancelot there (its all a bit tedious shuffling devices and power supplies to check all the combinations, plus for some reason I can't seem to get the CM1 to run on raspi with 3.1.1 though the 3.7 build did work, but wasn't submitting shares). Plenty to fiddle with. Anyway I'll try to get the initial version up on githib today and worry about fully testing all the combinations later.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 08:02:30 AM

Quote from: BlueDragon747 on December 14, 2013, 07:43:08 AM

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it Embarrassed

Yeah, agreed. I'm not even sure my raspi problems are due to the wallet. It could just be a buggy network stack eg the raspi wired ethernet port is connected via the internal USB hub, which could be causing random network hangs. It could just be that the wallet traffic is sufficient to trigger this, even though its stable in normal use. I have tried swapping to a different board (I have two pies), but the problem still occurs. I am on an old wheezy debian though, so the next thing to try would be an update to a more recent version, but I'm a bit loath to do this as there is a lot of customization I'd need to redo.

Anyway if I can get it mining on the pool, this won't be an issue any more Cheesy

EDIT. Yep mining on pool with 3.1.1, just needed to change a couple of lines of code. Found a block at 16k diff within 10 minutes too (I seem to be good at finding blocks on pools, I managed a 1.6G bitcoin block on only 50MH/s a few months back). I just need to check it out solo in case the diff change has broken that and I'll get it up on github.

lol 10 minutes yeah I would say that is almost showing off Tongue

on the cm1 have had a 1.2M share when soloing last week and a 723k share on the ztex few days ago Grin

great work are you going to do a build for cm1 and ztex?

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 07:43:08 AM

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it Embarrassed

Yeah, agreed. I'm not even sure my raspi problems are due to the wallet. It could just be a buggy network stack eg the raspi wired ethernet port is connected via the internal USB hub, which could be causing random network hangs. It could just be that the wallet traffic is sufficient to trigger this, even though its stable in normal use. I have tried swapping to a different board (I have two pies), but the problem still occurs. I am on an old wheezy debian though, so the next thing to try would be an update to a more recent version, but I'm a bit loath to do this as there is a lot of customization I'd need to redo.

Anyway if I can get it mining on the pool, this won't be an issue any more Cheesy

EDIT. Yep mining on pool with 3.1.1, just needed to change a couple of lines of code. Found a block at 16k diff within 10 minutes too (I seem to be good at finding blocks on pools, I managed a 1.6G bitcoin block on only 50MH/s a few months back). I just need to check it out solo in case the diff change has broken that and I'll get it up on github.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it Embarrassed

The only thing I could even guess at that would effect the whole network is that maybe the close 20 block retarget causes an issue?, any one else have any ideas about the cause or a way of getting more repeatable results to narrow down the possible cause Undecided

on the cgminer overload method there are two ways of getting the wallet working, kill a few cgminer instances and often the wallet would just start working again but sometimes it would need a close and restart of the wallet, this issue I can recreate but this does not result in finding a bug in the code as it just hangs or locks Cry

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 13, 2013, 07:00:25 PM

Quote from: mogrith on December 13, 2013, 06:08:55 PM

Quote from: pamuc on December 13, 2013, 03:47:17 AM

Quote from: kr105 on December 13, 2013, 03:11:32 AM

Quote from: pamuc on December 13, 2013, 02:40:30 AM

Is the system still working?
All of my blocks mined last night are shown as "Generated but not accepted"...
Any hints?

Try with my version of cgminer, even on solo.

I'm using kramble's blakefpga version. Worked perfectly until yesterday... Strange...

I have this issue often. Diff changes seem to knock wallet off network and all blocks mined become orphaned and block count fails to rise. I have to close and relaunch wallet. No prob in miner but in wallet.

cgminer has been known to crash the wallet and I notice that when you connect to the pool with diff 2, cgminer does the difficult @ 2.000397 maybe this has issues?

if someone can find this bug in the wallet then I can patch it, atm the only way i have seen this bug is to overload the wallet with cgminer rigs and it starts to lose connections and eventually locks up and needs to reset

cgminer 3.1.1 with kramble's fpga mod (ztex/cm1) is better but does occasionally lock the wallet

I did not get this problem with reaper when solo mining nor did I need to reset my wallet when using reaper Huh

I run the wallet on raspberry pi, and the problem I have is the pi completely locking up. It just hangs, nothing in the logs, nothing running (I have a watchdog that flashes a LED on the GPIO once a second via a bash script, and it just stops). Need to power cycle to reset. This happens with both cgminer and the old python miner, so its not just cgminer. Its very intermittent, originally happening perhaps once every day or so, then I had a good stretch where it was stable for a whole week (after diff had dropped off from its peak, so maybe the Mr Big miner had given up), and recently its been crashing every few hours (so much so that I switched over to litecoin mining overnight for the last week). This makes me think its more to do with what's happening on the network side rather than the miner.

PS I don't see any orphaned blocks when this happens, after restarting everything is fine and the blocks continue to confirm, but as the whole box is locking up rather than just the wallet, I guess this is a different sort of bug.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 13, 2013, 11:07:29 PM

Quote from: BlueDragon747 on December 13, 2013, 10:38:29 PM

Quote from: kr105 on December 13, 2013, 10:29:27 PM

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

Bitcoin 0.8.5 and 0.8.6
https://github.com/bitcoin/bitcoin/blob/0.8.6/src/main.cpp#L934

still uses +20 for coinbase maturity Undecided

so with Bitcoin its 100 +20 buffer
and with Blakecoin its 120 +20 buffer

from what Gavin has said with regards to Bitcoin is that the network is 100 and this is the minimum maturity and the +20 (has been a few different values) this is for an extra buffer to avoid stales and issues with sending newly matured coins ?

it can be reduced even removed from the wallet as long as the minimum of the network maturity is used which is 120 for Blakecoin, only reason it has been left as +20 is there was no good reason to change it Embarrassed

Yes, as you said this makes Bitcoin have the 120 confirms everyone knows about and as on the OP you said that BLC had 120 confirms, i used that confirms amount on the pool. But anyway, as you said, it doesn't hurt to have an extra 20 confirms buffer, just try to note about this on the OP so nobody else gets this confusion

made a reference to the +20 buffer, 140 total maturity in OP

Gavin did also say that it was mainly for the main stream end user wallets and not a pool or network level service so you can compile it with a lower value if you wish but also take the chance of any issues Wink

btw great work on the pool very smooth and it was upto 21GH/s Grin

for the pool this is my cgminer.conf:

{
"pools" : [
   {
      "url" : "stratum+tcp://stratum.blakecoinpool.org:3333",
      "user" : "UserName.Worker",
      "pass" : "WorkerPassword"
   }
],

"intensity" : "9",
"auto-gpu" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "2",
"log" : "5",
"no-restart" : true,
"queue" : "5",
"scan-time" : "10",
"worksize" : "128",
"temp-hysteresis" : "4",
"blake256" : true,
"vectors" : "1",
"no-submit-stale": true,
"kernel-path" : "/"
}

kr105

hero member

Activity: 938

Merit: 501

Quote from: BlueDragon747 on December 13, 2013, 10:38:29 PM

Quote from: kr105 on December 13, 2013, 10:29:27 PM

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

Bitcoin 0.8.5 and 0.8.6
https://github.com/bitcoin/bitcoin/blob/0.8.6/src/main.cpp#L934

still uses +20 for coinbase maturity Undecided

so with Bitcoin its 100 +20 buffer
and with Blakecoin its 120 +20 buffer

from what Gavin has said with regards to Bitcoin is that the network is 100 and this is the minimum maturity and the +20 (has been a few different values) this is for an extra buffer to avoid stales and issues with sending newly matured coins ?

it can be reduced even removed from the wallet as long as the minimum of the network maturity is used which is 120 for Blakecoin, only reason it has been left as +20 is there was no good reason to change it Embarrassed

Yes, as you said this makes Bitcoin have the 120 confirms everyone knows about and as on the OP you said that BLC had 120 confirms, i used that confirms amount on the pool. But anyway, as you said, it doesn't hurt to have an extra 20 confirms buffer, just try to note about this on the OP so nobody else gets this confusion

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 13, 2013, 10:29:27 PM

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

Bitcoin 0.8.5 and 0.8.6
https://github.com/bitcoin/bitcoin/blob/0.8.6/src/main.cpp#L934

still uses +20 for coinbase maturity Undecided

so with Bitcoin its 100 +20 buffer
and with Blakecoin its 120 +20 buffer

from what Gavin has said with regards to Bitcoin is that the network is 100 and this is the minimum maturity and the +20 (has been a few different values) this is for an extra buffer to avoid stales and issues with sending newly matured coins ?

it can be reduced even removed from the wallet as long as the minimum of the network maturity is used which is 120 for Blakecoin, only reason it has been left as +20 is there was no good reason to change it Embarrassed

kr105

hero member

Activity: 938

Merit: 501

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: mogrith on December 13, 2013, 06:08:55 PM

Quote from: pamuc on December 13, 2013, 03:47:17 AM

Quote from: kr105 on December 13, 2013, 03:11:32 AM

Quote from: pamuc on December 13, 2013, 02:40:30 AM

Is the system still working?
All of my blocks mined last night are shown as "Generated but not accepted"...
Any hints?

Try with my version of cgminer, even on solo.

I'm using kramble's blakefpga version. Worked perfectly until yesterday... Strange...

I have this issue often. Diff changes seem to knock wallet off network and all blocks mined become orphaned and block count fails to rise. I have to close and relaunch wallet. No prob in miner but in wallet.

cgminer has been known to crash the wallet and I notice that when you connect to the pool with diff 2, cgminer does the difficult @ 2.000397 maybe this has issues?

if someone can find this bug in the wallet then I can patch it, atm the only way i have seen this bug is to overload the wallet with cgminer rigs and it starts to lose connections and eventually locks up and needs to reset

cgminer 3.1.1 with kramble's fpga mod (ztex/cm1) is better but does occasionally lock the wallet

I did not get this problem with reaper when solo mining nor did I need to reset my wallet when using reaper Huh

mogrith

legendary

Activity: 1470

Merit: 1001

Use Coinbase Account almosanywhere with Shift card

Quote from: pamuc on December 13, 2013, 03:47:17 AM

Quote from: kr105 on December 13, 2013, 03:11:32 AM

Quote from: pamuc on December 13, 2013, 02:40:30 AM

Is the system still working?
All of my blocks mined last night are shown as "Generated but not accepted"...
Any hints?

Try with my version of cgminer, even on solo.

I'm using kramble's blakefpga version. Worked perfectly until yesterday... Strange...

I have this issue often. Diff changes seem to knock wallet off network and all blocks mined become orphaned and block count fails to rise. I have to close and relaunch wallet. No prob in miner but in wallet.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 13, 2013, 05:23:40 PM

Quote from: BlueDragon747 on December 13, 2013, 05:22:18 PM

Quote from: kr105 on December 13, 2013, 05:16:56 PM

Quote from: BlueDragon747 on December 13, 2013, 05:08:49 PM

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

I got them too, I'm not sure if it is a bug on cgminer or the pool, I'm looking at this now.

ok working again Cheesy

It seems to trigger with a certain target threshold btw, as I have not done anything yet Tongue

well I best keep testing Grin

kr105

hero member

Activity: 938

Merit: 501

Quote from: BlueDragon747 on December 13, 2013, 05:22:18 PM

Quote from: kr105 on December 13, 2013, 05:16:56 PM

Quote from: BlueDragon747 on December 13, 2013, 05:08:49 PM

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

I got them too, I'm not sure if it is a bug on cgminer or the pool, I'm looking at this now.

ok working again Cheesy

It seems to trigger with a certain target threshold btw, as I have not done anything yet Tongue

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 13, 2013, 05:16:56 PM

Quote from: BlueDragon747 on December 13, 2013, 05:08:49 PM

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

I got them too, I'm not sure if it is a bug on cgminer or the pool, I'm looking at this now.

ok working again Cheesy

kr105

hero member

Activity: 938

Merit: 501

Quote from: BlueDragon747 on December 13, 2013, 05:08:49 PM

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

I got them too, I'm not sure if it is a bug on cgminer or the pool, I'm looking at this now.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

kramble

sr. member

Activity: 384

Merit: 250

Quote from: kr105 on December 13, 2013, 03:59:30 PM

Quote from: BlueDragon747 on December 13, 2013, 02:49:57 PM

would be perfect if you can help kramble get a version that works well with fpga and also works on the pool?

Yes, Kramble just PM me if you need any help with cgminer

... Or maybe i should port the version 3.1.1 instead of the current one? I wasn't aware that cgminer dropped support for other hardware before, I selected this version because it was the last one to support GPU mining.

Thanks, I'll have a closer look at the code changes later this weekend and see if I can get the stratum code working in 3.1.1
I only chose this version as I wanted it to work on the raspberry pi and I'd seen a lot of comments recommending this version over later ones. I don't know whether anyone will want to run both FPGA and GPU mining simultaneously from the same cgminer, so maybe its best if we just keep the FPGA and GPU versions separate? Anyway I'll sign off now for tonight.

kr105

hero member

Activity: 938

Merit: 501

Good news guys, the pool fee has been lowered from 7% to 3% !

kr105

hero member

Activity: 938

Merit: 501

Quote from: BlueDragon747 on December 13, 2013, 02:49:57 PM

would be perfect if you can help kramble get a version that works well with fpga and also works on the pool?

Yes, Kramble just PM me if you need any help with cgminer

... Or maybe i should port the version 3.1.1 instead of the current one? I wasn't aware that cgminer dropped support for other hardware before, I selected this version because it was the last one to support GPU mining.

Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 164. (Read 409641 times)