Incompatible with some pools

[MaxDZ8]

An user reports miner cannot connect to the blocks factory qubit pool.
http://dgb-qubit.theblocksfactory.com/

Initial testing suggests the pool uses a slightly different protocol for authorize.

[MaxDZ8]

An user reported very high reject rates on the blocks factory.

In general, it seems everything NOMP based is broken.

P2P seems to be unaffected. It is clear this needs to be fixed again.

[MaxDZ8]

Albeit the above has been reproduced, it seemed to fix itself. Pool administrator has been contacted and he couldn't explain the issue.

The current codebase has been tested against some pools. It works with most...

• digihash.co Qubit would produce only invalid shares with insufficient difficulty resulting in almost immediate ban.
• MYR P2P UK node seems to decode difficulty incorrectly, causing a massive stream of shares (1-3 each second). Admin confirmed this appears to work as expected.

I also had issues contacting some pools but I suspect this to be my ISP.

[Golcoin]

hello friend, I am litejavichu of bitcointalk.
I tried it with my rig into two pools (Supra And Hashlink) on both gives many rejections and need five minutes to stabilize. when you get rejected the hahsrate decreases very fast and stays for a long time below.
To "MYR P2P UK node seems to decode difficulty incorrectly, causing a massive stream of shares (1-3 each second)".
I think the problem is the difficulty, as it communicates with the stratum. I tried to adjust intensity, but do not understand the parameter or as calculated.

regards

[MaxDZ8]

I am inclined to believe this might a side-effect of #11. I have indeed reproduced the pattern you describe an my system and I'll look for it.

According to the admin, MYR p2p uk node is really working as expected. I think it's overkill for an UK node but that's it.

[MaxDZ8]

Results of one day of investigation.

Many pools are non-conformant and require explicit adjustment. This has been a known issue for sgminer for ages but apparently pool owners cannot give less. Sgminer plans to either add a per-pool setting or deprecate the option altogether. In an ideal world, the latter would clearly be the best option, with misconfigured pools to just adapt or die.

Being enthusiast-oriented, sgminer can take it easy and do both if that's necessary.

As for me, the situation is more complicated as it's obvious an ordinary, occasional user cannot be bothered with those details. The fact the machinery is already there is not much of a plus.

The situation is frankly ridiculous as pool operators could fix this, resulting in a much improved mining ecosystem. But they don't.

The way M8M currently computes target difficulty is indeed wrong. It was manipulated to give the expected result and (besides the compatibility driver/HW issues) it is surprisingly functional.

[Golcoin]

Some pools have different difficulty connecting. I tried the latter and not
work, gives me error

2015-02-03 9:45 GMT+01:00 Massimo Del Zotto notifications@github.com:

Results of one day of investigation.

Many pools are non-conformant and require explicit adjustment. This has
been a known issue for sgminer for ages but apparently pool owners cannot
give less. Sgminer plans to either add a per-pool setting or deprecate the
option altogether. In an ideal world, the latter would clearly be the best
option, with misconfigured pools to just adapt or die.

Being enthusiast-oriented, sgminer can take it easy and do both if that's
necessary.

As for me, the situation is more complicated as it's obvious an ordinary,
occasional user cannot be bothered with those details. The fact the
machinery is already there is not much of a plus.

The situation is frankly ridiculous as pool operators could fix this,
resulting in a much improved mining ecosystem. But they don't.

The way M8M currently computes target difficulty is indeed wrong. It was
manipulated to give the expected result and (besides the compatibility
driver/HW issues) it is surprisingly functional.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[MaxDZ8]

Yeah, that's another problem and would probably require its own bug report... I'm managing it there anyway.

I also have sporadic connection problems but I am inclined to believe they might be not under my control.

Please provide list of non-working pools.

[MaxDZ8]

(Reopening again after github closed automatically on commit).

d547b26 appeared to alleviate the issue for low hashrate miners. It seems the situation hasn't improved (at best) for high hashrate. Where high hashrate means somewhere starting at R 280 with some OC.

It has been reported the amount of rejected shares grow with time (likely as the pool adjusted difficulty).
Another user also reported exactly 100% reject since start but it's unclear if this is due to the same reason.

Could not reproduce locally. An exhaustive unit test has been designed and will be carried out before next release.

[MaxDZ8]

Update as requested.

I performed several tests in isolation on some functions involving difficulty and target bits computation. Due to use of ulongs (or bigger) it's impossible to exhaustively test the input domain but we're still talking about ... 3 hours (x3 CPUs) of testing on each function so the chance those are buggy seems extremely slim. With those functions being bit-perfect, I am positive I can say fetching the data to the GPU works as expected.

Some additional "spurious" testing has been performed and again, the behavior turned out to be bit-exact to legacy miner code... most of the time.

It turns out legacy miners don't dispatch work deterministically. I spent the whole day trying to force an internal sgminer build in scanning deterministically with little success. At the end, I figured out a way to re-produce a predictable pattern which will be implemented in the next few days.

I suspect I might be packaging target diff incorrectly to CL buffer (or perhaps unpacking it incorrectly kernel side). I am not very inclined in believing this but the above testing method would send me on the right track.

It seems increasingly likely the problem might be in the CL stack itself. I have to note the few bug reports got so far (conveniently?) omit driver version. Shall this be the case, no fix can be produced but on the pro side, I'm going to produce a test (based on aforementioned data patterns) to submit to AMD driver team.

[MaxDZ8]

Update based on feedback from v801.

Pools which were known to not work are now fine, some tested pools appear to have problems.
I'm not sure that's my problem anymore besides for example #18.

Growing the pool compatibility tests.

[MaxDZ8]

Closing. A new issue will be added for each pool instead. As pools keep going out, I've given up on testing them on release.