Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 105. (Read 444067 times)

solo mining is not working in ver 3.5 and newer

http://imgur.com/a/PIx8U
http://imgur.com/a/JRcaB

cpuminer-core-avx2 -a cryptonight -o stratum+tcp://xmr.suprnova.cc:5222 -u workerlogin.workerid -p x -q

I would like to test on my multiple windows machine (4790k, 35 2630v3, 2680v5, etc etc)
I do apologize for my stupidity but I can't seem to find any CLI instruction for specifying wallet address or worker name

Is this format correct?

cpuminer-core-avx2 -o stratum+tcp://xmr.suprnova.cc:5222 -u workerlogin.workerid -p x

Thanks for the report.  That's a significant difference, I'l have to pour through the code,
there must be something to be found.

Report:

Algo : cryptonight
CPu i7 2600 8Mb 4 threads
Miner version :3.5.5

[2017-02-08 02:15:35] CPU #3: 607 H, 57.22 H/s
[2017-02-08 02:15:35] CPU #2: 620 H, 58.35 H/s
[2017-02-08 02:15:35] CPU #0: 566 H, 53.32 H/s
[2017-02-08 02:15:35] CPU #1: 339 H, 54.51 H/s
[2017-02-08 02:15:39] CPU #1: 234 H, 54.61 H/s
[2017-02-08 02:15:39] Accepted 5/5 (100%), 2027 H, 223.50 H/s, 62C
[2017-02-08 02:15:55] CPU #1: 860 H, 53.05 H/s
[2017-02-08 02:15:55] Accepted 6/6 (100%), 2653 H, 221.94 H/s, 62C
[2017-02-08 02:15:55] CPU #3: 1178 H, 56.42 H/s
[2017-02-08 02:15:56] Accepted 7/7 (100%), 3224 H, 221.14 H/s, 62C
[2017-02-08 02:16:05] Stratum difficulty set to 4394
[2017-02-08 02:16:05] CPU #3: 518 H, 56.53 H/s
[2017-02-08 02:16:05] CPU #2: 1738 H, 57.86 H/s
[2017-02-08 02:16:05] CPU #0: 1574 H, 52.41 H/s
[2017-02-08 02:16:05] CPU #1: 506 H, 53.00 H/s
[2017-02-08 02:16:17] CPU #1: 680 H, 54.20 H/s
[2017-02-08 02:16:17] Accepted 8/8 (100%), 4510 H, 220.99 H/s, 62C
[2017-02-08 02:16:22] CPU #1: 259 H, 53.44 H/s
[2017-02-08 02:16:22] Accepted 9/9 (100%), 4089 H, 220.23 H/s, 62C
[2017-02-08 02:16:24] CPU #1: 126 H, 51.88 H/s
[2017-02-08 02:16:25] Accepted 10/10 (100%), 3956 H, 218.67


same setting get with Claymore 268 H/s   but yours easier to setup and run    more likeable

Thanks, but donation not necessary, your help testing was very helpful.

As I completely ignore the superbowl on this quiet sunday afternoon one football thought came to mind.
American football is the only sport I can think of that rewards a team for taking the ball out of play.

When the ball is taken out of play the team carrying the ball is not penalized in any way, they actually
gain by stopping the clock and securing their ball position.

In baseball if a ball is hit foul, it's a strike, if it's thrown out of play the opposing runners are awarded a base.

In soccer if the ball goes out on the sideline, the opposig team gets a throw in, behind the goal the opposing
team gets a goal kick or a corner kick.

In hockey when the defensive team shoots the puck out of play in their own zone it' a penalty.

In tennis you lose the point.

Football is also the only sport where they stop playing and walk off the field before the clock expires.

Thanks for testing. Did you notice any difference from 3.5.3?
What's your CPU?

cryptonight works fine for me, but slightly slower than Wolf0's cryptonight CPU miner.

CPUMiner-opt approx 90-95 h/s
Wolf0 approx 100-105 h/s

I have no way to measure power consumption.

Haha, good to hear

I'll send some small donation later, get youself a drink

I've discovered cryptonight is broken in 3.5.5, use 3.5.4 instead. I'm looking into it.

Got unlucky, first submit rejected and panicked. I made no changes in cryptonight so I was scared it
was another strange bug.

Cryptonight looks good.

All users should stop using 3.5.5-pre. It contains no fixes and no optimizations above 3.5.4, only some test
code that didn't work as intended.

If any problems are found in 3.5.5 they should be reported and users can revert to 3.5.4 (3.5.1 for x11evo
on Windows) until any problems are resolved.

Thanks. I guess I need to document in errata until I fiure out what's going on. I removed the swap macro as it
never worked on x11evo, but I guess that wasn't it.

Only AMD and only timetravel?

That's 3 bugs:

1 - swap macro doesn't work mining x11evo but works mining timetravel,
2 - x11evo permute optimization not working in Windows,
3 - silent exit after 50 submits mining timetravel on AMD,

that make no sense in one release, and all in algos that permute the hash functions.  I don't think it's a coincidence.

just tried, still exits on stats enabled

Have you tried submitting? -p stats

also my amds are now running past 50 accepted shares on timetravel on windows, so not submitting the benchs prevented the issue

Ooops. I started using a script for each build for less typing. Was on autopilot renamed exe to match arch.

thanks for this


small note: the windows bin for sse2 was renamed to *-core2.exe instead of *-sse2.exe as in previous builds, i renamed it to sse2 in my miner repo to not break scripts already in place for previous versions

cheers

cpuminer-opt-3.5.5 is released.

x11evo is fixed on Windows but performs at the same hash rate as 3.5.1. Linux users
get the optimizations from 3.5.4.

AMD users reported that in 3.5.4 timetravel exitted after 50 submits. There are two parts to
this problem. First the stats were being collected by default, second doing so resulted in the
miner exitting.

The default has been changed to disable stats collection by default and must be enabled by
including the word stats in the password. Stats collection has not been tested in 3.5.5 on
an AMD CPU therefore it may still cause the miner to exit if enabled. AMD user are encouraged
to report their findings.

See OP for details.

I think I've gone as far as I can with x11evo and windows.

There is no windows targeted code in the function. The only suspicious code, betoh, is also called
in the working case. betoh is defined in a system library, with no local copies in the application.

There is nothing suspicious in the code additions that trigger the rejects. It's a simple if statement.
Using thread-safe variables works in other algos on windows.

The logic is sound nearly fail safe. If it fails true it loses the otimizations. If it fails false it won't
recalculate the permutation for a new ntime. I have confirmed the first pass triggers a new permutation
to be calculated so the first block should work. Only if the second block is not properly detected should
the miner start producing rejects. But it always produces rejects from the start

I tried disabling some compiler optimizations.

I tried rewriting the function in different ways, getting ntime from the threaded work.data instead of
global stratum.

I tried running cpuminer from msys shell as well as from dos with bundled DLLs. Neither work.

At this point I think I've eliminated anything related to the miner, which is as far as I'm willing to go
at this point.

The next step would be to compare assembly code between windows and linux. It should be identical, if not
it may be a compiler issue. On the other hand if the assembly code is identical the problem must lay
elsewhere in the system.

Although it would be a good way to get up to speed on x86 assembly it doesn't help solve the issue with
cpuminer-opt and x11evo.

I will implement a workaround to disable the optimization in twisted_code on Windows platforms.
This should work but so should have the optimization on Windows, The impact of this is x11evo
will perform slower on windows, the same rate as in 3.5.1. On linux it will benefit from the higher
hashrates in 3.5.4.