I never understood why most mining software comes with "setx" in the sample batch file. This is wrong and dangerous. The command "set" is what should be used.

set modifies the current shell's (the window's) environment values, and the change is available immediately, but it is temporary. The change will not affect other shells that are running, and as soon as you close the shell, the new value is lost until such time as you run set again.

setx modifies the value permanently, which affects all future shells, but does not modify the environment of the shells already running. You have to exit the shell and reopen it before the change will be available, but the value will remain modified until you change it again.

I watch the "transactions" directly in the pool and see how my revenues fluctuate with every block, even though this shouldn't be the case with PPLNS. Yes, each rig mines a dev fee but this is only every one hour for two minutes. I see however huge variations (up to 100% in revenues from block to block) so from minute to minute (since suprnova finds basically all blocks currently).

In the above example. Let's assume a new block was found at 13:36:08. This means all work done from 13:32:12 until 13:36:08 was for nothing, because no shares were submitted, right? It is like if the rig was offline. Since the rig didn't submit any shares from 13:32:12 until 13:36:08 and on average 3-4 blocks were found during this time (all of them found by the pool, let's assume). In case of PROP that would mean zero revenues for those blocks found while the rig submitted zero shares. In case of PPLNS it would still mean some revenues but they would ramp down and be lower than nominal.

The lucky high-diff share found at 13:36:11 will count for the block which started (in oiur assumed example) at 13:36:08. It was found within 3 seconds. It was not the result of the previous four minutes of work, right?

One reason why I don't like too high diffs is because you will often end up with outdated work, i.e. no share found yet while a new block was already found. So the work has to be abandoned and it was for nothing. Yes, miners nowadays at least notice this, abandon the old work and begin with fresh work. Still, it was wasted time if no share was found. In the old days miners would stubbornly continue trying to find a share for the outdated work, wasting even more time, then find it and submit it and trigger a stale share in the pool.

Okay, here is a problem. See screenshot.





I'd say it is a problem that has two causes. The fluctuating hashrate due to the algo but mostly the suboptimal vardiff implementation of the pool, which ramps up way too much an then remains way to high for way too long. Both causes amplify each other.

See on the first screenshot around 13:30 how due to the skyrocketing hashrate to 80MH/s the pool ramps up the vardiff to 2.05G. However just then the hashrate drops (when hash order changed) to sub 30MH/s and the rig isn't able to find a single share for four minutes (13:32:12 to 13:36:11). Yes, I know the typical pool operator talk about how it doesn't matter for revenue because shares are weighted with difficulty. Sure. But 2.05G multiplied with ZERO shares is still ZERO over that four minutes period.

From experience I can tell that shares should be found/submitted every five seconds for an averager blocktime of 1min. Too low diff is bad (server traffic, latency), too high diff is bad too (no shares at all, working on outdated jobs).

I understand the pool operators' incentive to minimize server traffic by letting workers crunch higher diffs, but in this case the vardiff clearly is not working well because it goes way too high and remains there for too long. That's bad for the workers and bad for the pool too.

@ocminer: What you think?

@andrucrypt: Is it technically possible to optimize the miner to make the hashrate higher for those hash orders where it is much lower currently? Or is this limited by the varying usage of core and memory and the actual hardware specs with regard to both on which it runs?

No problem throughout the night on all rigs (R9 Nanos) with this latest version.
Also no more unrealistic "max" value now (the previous screenshots above showed 415MH/s, an order of magnitude more than the rig can actually push). It shows 63MH/s now, which is plausible and happens for certain hash orders (appr. 15MH/s per card).

You mean as easy to get as you, butt boy?

I noticed that the rigs would sometimes crash while or shortly after the dev mining period. Maybe the dev mining has a bug. At least it looks a bit strange in the console.
Sometimes they don't crash and just continue the normal mining as in these screenshots. The pool will however show lots of invalid shares during the dev mining period.
Also the cards cool down completely in those two minutes, so I don't think they are doing any dev mining in those two minutes. You might want to check to not lose out your fees.







I used the previous versions of this miner to mine x22i for two months and it didn't have this strange behaviour while mining the dev fee. No hundreds of lines of "oops, stale share" and cards wouldn't cool down at all.

What are you still doing here if you don't "bother mining this rubbish coin"? You seem quite angry that you couldn't easily fill your bags with this "rubbish coin".
If you think others will stop mining it because of a noob with five posts (of which three are utter crap) posting rubbish here --> forget it.

Here is a comparison between x22i and x16rt, tested on the same rig (4 x R9 Nano, stock ROM, Win7, Crimson 16.3.2) with the same settings on the cards (900MHz/500MHz/-72mV) and the same settings in the miner (--opencl-threads 2 --opencl-launch=18x0). Total power draw for the entire rig is measured at the wall, i.e. includes CPU (70W in idle).

x22i gives a constant 5MH/s per GPU at constant 650W total power draw.
x16rt gives 6MH/s to 12MH/s per GPU at 500W to 800W total power draw.

With x16rt the power draw changes dramatically every time the hash order is changing. Consider this and use lower intensity to not run into the max current breaker of the PSU if your PSU isn't oversized.

For x22i wildrig-multi-0.14.0-beta was used.
For x16rt wildrig-0.15.0.8-beta was used.

If there was only something like a Coordinated Universal Time standard that we could use to unambiguously communicate a point in time like the genesis of a blockchain to a global audience...

Okay, that makes very much sense. I was suspecting something like this but it's another thing when the dev confirms it. Keep up the good work.

Thanks. When the harder hash functions are to be executed, shouldn't the GPU temp remain at nominal? I see the temperature dropping during that time, implying that the GPUs are working too little on those harder functions. Or is my reasoning flawed?

EDIT: Haven't used x16r before. I used this miner only for x22i for two months now and I didn't see the mentioned behaviour on that algo.

Is it to be expected that the hashrate when mining x16rt is varying quite a lot?
In my case it varies between 8 and 16 MH/s (for each GPU) over a few minutes, with all GPUs on a rig showing the same ups and downs synchronously.
Is this a property of this new algo or rather a bug in this very early release?

EDIT: When the hashrate goes down, so does the temperature and fan speed on the cards. So they obviously don't work as much as they should/could.

It's "live" but not alive. The chain is stuck because the DAA is broken and has sent the difficulty to the moon half a day ago. No block since then. See my previous post.

DAA mooned. It's stuck.

PoS is rewarding wealth. PoW is rewarding work.

Therefore PoS = Piece of Sh..

Iridium is PoW.

Those who want to see the fraudulent legacy financial system, where newly issued money goes to the billionaires/monopolists, the friends of the central bankers, and then eventually a tiny bit of it "trickles down" to their wage slaves, bering introduced in crypto too --> Support PoS coins.

Those who want to see crypto as a system where newly issued money goes directly to the workers (aka miners) --> Support PoW coins

I guess most of the kids who scream for PoS on this and other forums have no clue what that concept really means. I doubt they are rich, probably just stupid.

Yes, and that was when BTC was nearly $20k, so they asked for $1M for a listing on their shitty exchange.

Neither Masari nor Iridium are scams. That ASIC loving pot avatar guy had his brain go up in smoke a long time ago. Not sure what he is still doing here after the anti-ASIC HF.

Never used the Windows wallet, but shouldn't there be a seed in order to backup and restore a wallet?

Sorry, I can't help you with the GUI wallet. I am using the CLI wallet.
If it is urgent, import your keys into the CLI wallet and get the transfer done.

Again, this is absolutely wrong. Why do you keep repeating these fairy tales? You can send out thousands of MSR in one tx and the fee will be typically 0.05 MSR even if your tx has many inputs.