|
You're all making it worse. Repent and say some prayers to St. Eligius.
|
|
|
|
Maybe not so important since it's just a matter of displayed device name.
I believe you are looking for confirmation from debug output. I took a debug log after I upgraded my BFGMiner from 5.2.0 to the broken version of 5.3.0 on the 5th of September. I think it confirms that the device name of my Antminer U3's were recognised as CBM device. Below are some of the lines on that debug log. I can send you the whole log (only about 1 minute worth of messages though) if you are interested on that. .
.
[2015-09-05 20:32:08] CBM 0d nonce = 0xd26d8507 = 0x49b61420 hashes (0.034306s; 0.027740ns/hash)
[2015-09-05 20:32:08] CBM 0a: Popping work from get queue to get work
[2015-09-05 20:32:08] CBM 1c nonce = 0x508863f4 = 0x42218fd4 hashes (0.031638s; 0.028515ns/hash)
[2015-09-05 20:32:08] CBM 1a: Popping work from get queue to get work
[2015-09-05 20:32:08] CBM 0a: Got work 3252 from get queue to get work for thread 0
[2015-09-05 20:32:08] CBM 1a: Got work 3256 from get queue to get work for thread 4
[2015-09-05 20:32:08] Selecting pool 0 for work
[2015-09-05 20:32:08] Generated stratum header 000000031f1b418f32e1029d0ba699fb6c6d69fa2b4505f910a6ac6a00000000000000001316c7f355e434897ef09f8d8721ec6ac457b46185081a8c5b9521989568c0b955eb351e18134dc100000000
[2015-09-05 20:32:08] Work job_id 1441477890 107367 nonce2 0000039d
[2015-09-05 20:32:08] Generated stratum work
[2015-09-05 20:32:08] Pushing work 3292 from pool 0 to hash queue
[2015-09-05 20:32:08] Selecting pool 0 for work
[2015-09-05 20:32:08] Generated stratum header 000000031f1b418f32e1029d0ba699fb6c6d69fa2b4505f910a6ac6a00000000000000004d2c4d682acf97793bc560e527dd3f2cb2eead8cb51c3b79b23c7b5b1dd3718055eb351e18134dc100000000
[2015-09-05 20:32:08] Work job_id 1441477890 107367 nonce2 0000039e
[2015-09-05 20:32:08] Generated stratum work
[2015-09-05 20:32:08] Pushing work 3294 from pool 0 to hash queue
[2015-09-05 20:32:08] CBM 0: No data in 0.075 seconds
[2015-09-05 20:32:08] CBM 1: No data in 0.075 seconds
[2015-09-05 20:32:08] CBM 0 no nonce = 0xffffffff hashes (0.078335s)
[2015-09-05 20:32:08] CBM 0a: Popping work from get queue to get work
[2015-09-05 20:32:08] CBM 0a: Got work 3260 from get queue to get work for thread 0
[2015-09-05 20:32:08] Selecting pool 0 for work
[2015-09-05 20:32:08] Generated stratum header 000000031f1b418f32e1029d0ba699fb6c6d69fa2b4505f910a6ac6a0000000000000000335850b265322e3909d4501e6c911f47c655ca5b115b19bc9b542a5b9266912755eb351e18134dc100000000
[2015-09-05 20:32:08] Work job_id 1441477890 107367 nonce2 0000039f
[2015-09-05 20:32:08] Generated stratum work
[2015-09-05 20:32:08] Pushing work 3297 from pool 0 to hash queue
[2015-09-05 20:32:08] CBM 1 no nonce = 0xffffffff hashes (0.077746s)
[2015-09-05 20:32:08] CBM 1a: Popping work from get queue to get work
[2015-09-05 20:32:08] Selecting pool 0 for work
[2015-09-05 20:32:08] Generated stratum header 000000031f1b418f32e1029d0ba699fb6c6d69fa2b4505f910a6ac6a0000000000000000ed92f07d4de37dc46ceaeb3ebe8f5206ffdcd29f446484f36d6323b0e0a9b12f55eb351e18134dc100000000
[2015-09-05 20:32:08] CBM 1a: Got work 3264 from get queue to get work for thread 4
[2015-09-05 20:32:08] Work job_id 1441477890 107367 nonce2 000003a0
[2015-09-05 20:32:08] Generated stratum work
[2015-09-05 20:32:08] Pushing work 3300 from pool 0 to hash queue
[2015-09-05 20:32:08] PROOF OF WORK RESULT: true (yay!!!)
[2015-09-05 20:32:08] Proof: 0000000057e1afcb8faa3fcd24aca544e542a1bf3eda5347d80d989d18de1cfa
.
.
[2015-09-05 20:32:43] Summary of per device statistics:
[2015-09-05 20:32:43] CBM0 | 30s:28.72 avg:46.69 u:45.24 Gh/s | A:1 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM0a | 30s: 7.18 avg:11.67 u:11.96 Gh/s | A:1 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM0b | 30s: 7.18 avg:11.77 u:10.40 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM0c | 30s: 7.18 avg:11.77 u:11.65 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM0d | 30s: 7.18 avg:11.77 u:11.51 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM1 | 30s:29.06 avg:47.24 u:41.67 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM1a | 30s: 7.26 avg:11.80 u:10.45 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM1b | 30s: 7.26 avg:11.90 u:10.47 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM1c | 30s: 7.27 avg:11.91 u:10.95 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43] CBM1d | 30s: 7.27 avg:11.91 u:10.05 Gh/s | A:0 R:0+0(none) HW:0/none
[2015-09-05 20:32:43]
Nah, I was looking for some hint as to what went wrong during detection.  |
|
|
|
yup...just now 1 block rewarded from thin air? all of the big contributors are around 93%? i'm mining for about 1 year and i'm around 93% myself...it is too much of a difference. and i should say that the overall luck in theory should be even better than 100%. big question marks for me  ...i wish you all miners all the best, but i'm outa here  Goodbye, person who doesn't understand how mining works...  |
|
|
|
Can you run the broken version with -D -d? and paste the output?
Ooppsss... I have already cleaned up everything related to the previous HEAD version, including the compiled package. I need to figure out how to tell OpenWRT build package to roll back to previous commit. Is this quite important Luke? For instance, do you suspect something might broke other parts? I prefer to move on with your latest commits, but if that would be important I will try to roll back and re-compile. Maybe not so important since it's just a matter of displayed device name. |
|
|
|
I saw that you have commited some changes on your github, especially commit 8488cf0 on the device name for compact device. I will try if that would fix the issue I am seeing. I can confirm that your new commits fix the issue that I had as you can see on below link (I am not sure why I cannot insert image to this forum any more)  Strange, it shouldn't have... Can you run the broken version with -D -d? and paste the output? |
|
|
|
|
Hmm, maybe try changing the single-quotes to double-quotes.
|
|
|
|
I've been working on trying to calculate the reg_data for BM1382/4 on demand, and have an algorithm that seems to mostly work... But there's 6 exceptional cases in Gekko's cgminer table that don't fit it: For 181.25 MHz, Gekko is using 0e83, but this seems to actually be 187.5 MHz, while 181.25 MHz should be 0e 03. For 412.5 MHz, Gekko is using 1006, but this seems to actually be 206.25 MHz, while 412.5 MHz should be 100 5. In four cases, Gekko is using what appears to me to be an overly-precise divider out of the norm pattern: - For 143.75 MHz, Gekko is using 1687, but 0b03 seems like a better choice.
- For 168.75 MHz, Gekko is using 1a87, but 0e03 seems like a better choice.
- For 212.5 MHz, Gekko is using 1086, but 0802 seems like a better choice.
- For 237.5 MHz, Gekko is using 1286, but 0902 seems like a better choice.
Can anyone shed some light on these differences? For reference, here is the code I am using to calculate the register data: In C... bool bm1382_freq_to_reg_data(uint8_t * const out_reg_data, const float mhz)
{
if (mhz < 100)
return false;
float best_delta = FLT_MAX;
unsigned best_dc = 0;
unsigned try_list[4], *tlp = try_list;
if (mhz >= 200) {
if (mhz > 400) {
*(tlp++) = 0x0101;
*(tlp++) = 0x0205;
} else {
*(tlp++) = 0x0202;
}
*(tlp++) = 0x0406;
} else {
*(tlp++) = 0x0403;
}
*(tlp++) = 0x0807;
for (unsigned *tli = try_list; tli < tlp; ++tli) {
const float d = *tli >> 8;
const float df = 25. / d;
const float delta = fmodf(mhz, df);
if (delta < best_delta) {
best_delta = delta;
best_dc = *tli;
if (delta == 0) {
break;
}
}
}
if (!best_dc)
return false;
const float d = best_dc >> 8;
const float df = 25. / d;
const unsigned di = best_dc & 0xff;
const uint16_t reg_num = ((unsigned)((mhz / df) - 1) << 7) | di;
pk_u16be(out_reg_data, 0, reg_num);
return true;
}
In Python... def freq2reg(f):
best_delta = 99999
best_d = 1
d_to_try = []
if f >= 200:
if f > 400:
d_to_try.append(1)
d_to_try.append(2)
d_to_try.append(4)
d_to_try.append(8)
for d in d_to_try:
df = 25. / d
delta = f % df
if delta < best_delta:
best_delta = delta
best_d = d
if delta == 0:
break
best_df = 25. / best_d
if best_d == 1:
di = 1
elif best_d == 2:
if f > 400:
di = 5
else:
di = 2
elif best_d == 4:
if f > 200:
di = 6
else:
di = 3
else: # best_d == 8
di = 7
return (int((f / best_df) - 1) << 7) | di
|
|
|
|
Hmm, I did test that it works on my Compac pre-prod sample before posting it here :/
Does it work any better if you use RPC's pgaset?
bfgminer-rpc 'pgaset|cbm0,clock,x0783'
It probably has to to with the changes made between pre- and post-production sticks. Is the command you suggested something I enter from the command line or batch file? I am not familiar with RPC. I'll see what I can find out about it in the mean time and try that way, if I can figure it out. You'll need to run BFGMiner with --api-listen --api-allow W:127.0.0.1 and then you can use the bfgminer-rpc command from a prompt. |
|
|
|
Using 5.3.0 to run a couple gekko compac sticks and no matter what value I input for --set compac:clock= the sticks hash as if they were set to 225 (x0882), so at about 11GH/s each. Any idea why the sticks are not taking the frequency setting?
Found this bug. Will fix in 5.4. Workaround: Use --set cbm:clock=x0783 instead. I forgot to set the "compac" name on the driver... :| Wonderful, thank you! Now I have to dig up my usb tester and start dialing these sticks up. edit - I have been unable to produce successful results with the revised cbm command, my sticks still hash at default frequency. Hmm, I did test that it works on my Compac pre-prod sample before posting it here :/ Does it work any better if you use RPC's pgaset? bfgminer-rpc 'pgaset|cbm0,clock,x0783' |
|
|
|
Using 5.3.0 to run a couple gekko compac sticks and no matter what value I input for --set compac:clock= the sticks hash as if they were set to 225 (x0882), so at about 11GH/s each. Any idea why the sticks are not taking the frequency setting?
Found this bug. Will fix in 5.4. Workaround: Use --set cbm:clock=x0783 instead. I forgot to set the "compac" name on the driver... :| |
|
|
|
The name of the devices of my Antminer U3 have now changed to CBM where previously they were shown as AMU on version 5.2.0. I can't see to reproduce this. Mine always shows up as AMU... What command line do you use? |
|
|
|
i have noticed that most of the miners on eligius (me included) are around 93% payouts. i begin to not like this statistic..it has to mean that in a way or other this is a 7% fee pool  No, because fees would be taken out after the risk/luck factor. |
|
|
|
|
There basically is no "correct". Stratum never had any way to request a difficulty "officially".
Originally in BFGMiner, --request-diff only supported GBT pools (since only GBT had protocol support for it).
Back in 2013, I extended it to stratum with a new mining.suggest_target extension.
This used a full hex target String to avoid the problems encountered with a difficulty Number (inaccurate, etc).
Then over a year later (2014), cgminer decided to introduce their own --suggest-diff option that was incompatible.
A month later, they changed it, but still left it incompatible.
AFAIK their "justification" for this gratuitous incompatibility is based on some passing ideas slush had, but never added to Stratum himself.
|
|
|
|
I'm trying to request a starting diff by using --request-diff 48, but the command doesn't seem to work. My entire batch files is: bfgminer.exe -o stratum+tcp://solo.ckpool.org:3333 -u 1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.bmoscatosticks -p x -S rockminer:all --set rockminer:clock=280 --set compac:clock=x0d82 --request-diff 48 --api-listen --api-allow W:10.0.0/24 CKPool does not honour target requests. |
|
|
|
Hi,
is it possible to use bfgminer as a stratum -> getwork proxy ?
I like to use rented hashpower to mine on my local wallet. Nicehash only supports stratum targets.
I tried different combinations and I know it can used as getwork -> stratum proxy and stratum -> stratum as well as getwork-> getwork.
Did I make a error in the configuration ?
bfgminer -o 127.0.0.1:8888 -u user -p pass --stratum-port=3333 don't work
regards
It is impossible to translate getwork to stratum like that, but it doesn't matter because Core doesn't even support getwork anymore. You can do GBT to stratum with the --stratum-port 3333 option, but no = in arguments... |
|
|
|
|
Note: -O3 is known to break some software, so please use -O2 if you want BFGMiner to be reliable.
|
|
|
|
I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?
You're conflating standards with the IsStandard filter. The former is defined by common use, while the latter is miner/relay policy entirely up to the individual user to decide. You can decide to filter with SCRIPT_VERFIY_LOW_S if you like, but maybe 5% of legit transactions will probably be filtered if you do so. If everyone did, then those 5% would never confirm until someone malleated them. |
|
|
|
Rules 2-6 are also not implemented, and BIP 66 extended rule 1 to all transactions, regardless of their version. But the main reason it isn't suitable right now is the "Block validity" section, which uses block version >=3 to trigger it. We already are on block version 3 for BIP 66, so this needs to be updated for another version. Furthermore, when we were initially planning to begin roll-out, Peter Todd (IIRC) brought forward some very real issues with the BIP that would have potentially been problematic, so there was a general feeling that BIP 62 had not been sufficiently reviewed/considered, and was therefore too risky. |
|
|
|
I mean really , why  Because I am able to do it. With Great power comes great responsibility my child......  Eh, you realise this kind of thing doesn't need any power, right? It's literally just a few lines of code in any old boring node... |
|
|
|
|
Show Posts
