Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 232. (Read 237263 times)

too much theory guys.  Better take a 24,48h average from the pool, at the end that's what really matters.
If you get numbers you don't like, switch mining software

Don't get mad, but i really don't have time and nerves for these kind of things.

I mean if your point isn't that the miner/me is stealing from you, then what is it? What are you trying to say ?

I made calculations another way, but I'm agreed that there is something wrong...
You calculate what speed miner gives and must. I calculate how much shares miner must give with mining speed and how much it findes.
Miner gives less founded shares for speed that it indicates.
i calculate next way:

My speed is 2150 h/s. In hour - 2150 h/s * 3570 (-30 sec devfee) = 7675500 h. Now devide by difficulty - 7675500 h / 200007 = 38.38 shares. But real founded shares is about 33-34 in hour...

Can anyone suggest the proper intensity setting for a vega 56 ... if I use the default it crashes...

Thanks for the reply, dear! There were no thoughts about theft of hash. Based on your mathematics, you can calculate the real hash of the miner 1213 * 240000 = 291120000 total hash. 291120000 h / 54190 sec = 5372 h/s. Why then this figure is obtained, not 5800? What am I doing wrong?

Got something weird happening when mining IPBC, if I just use my Vega 56 on its own it gets 3800h/s but when I mine alongside my RX 550's it drops to 3000h/s even though intensity etc. is all the same.

Anyone got any ideas?

Coin switching for the same algo shouldnt be hard, your proxy sends info in json which coin to mine, minert just switches to the pool/wallet for that coin, and continues to mine.

If you manage to make it stable enough ("it never does, it's a continuous fight against new drivers and windows updates" )) ), i can make SRBMiner compatible with it.

I know you all have your conspiracy theories that a miner must steal your hashrate, but i will have to dissapoint you.
Your math is bad, to get average of something you divide total with something, in this case :

Total time in seconds since connected to pool / total number of sent shares (good & bad)

And end of story. This is how you get average time needed to find a share.

Sorry im not stealing 9% of your hashrate.

Your case:
Mining time 15 hours, 3 minutes 10 seconds = 54190 sec (in this case this can be taken because you did not have pool disconnects)
Total shares : 1213
Average : 54190 / 1213 = 44.6 sec

Now check your screenshot.

Good point Sx5000 !
I'm waiting for Dok's reply..

have a litle trouble

algo heavy

cards rx470-570 4gb
double treads work fine
in config "intensity" : 29, "double_threads" : true

single treads dont work with error
Error CL_INVALID_BUFFER_SIZE when creating scratchpad buffer for DeviceID 0 (Thread 0)
in config "intensity" : 57, "double_threads" : false

if set intensity 0 setting 44 and slow rate
same rig work fine with config "intensity" : 58, "double_threads" : false
same drivers version 18.2.1 same swap size 60gb for 12 card same windows version 1709

Not at all like this. It shows not the calculator, but the miner. The calculator does not calculate the profit, but the efficiency of finding shares. So this efficiency is lower than stated. Just want to understand why. If you are used to deal with everything superficially - your right.

Forgive me, doctor Here you have 2 pictures with arrows, compare, can understand what I'm talking about ....

Is this possible to mine with cpu in this miner and if yes, how?

sorry but this is similar to the ones like : "calculator shows 50% more profit then i get. why is that?"

Come on, for someone like you, I posted a log. Hash did not fall over time. In another competitive miner, the hash is shown below, but it corresponds one to one. I like this miner, I respect his developer, and want to thoroughly understand him. If you really can not help, just pass by.

WoW! what a noob!

You want accuracy then use the right numbers.
the difficulty was 240009
your hashrate was descending with time, so 5880 h/s is just not accurate.

or

stop being so anal, 9% discrepancy is not bad for the crypto mining world.

Baz

I ask you seriously. Discrepancies of 9%, if for you it is a joke, then for me - no. I want to understand this question. The first time I encounter this.

... are you like SERIOUSLY asking this ? or just joke?

Hello, dear! My miner version 1.5.8 works with a speed of 5880hs. The average time to search shares in the complexity of 240000 in statistics is 44 seconds. According to my calculations, it should be less than 240,000 / 5880 = 40.8. At a time of 44 seconds, the real hash is much lower than the displayed hash of 240,000 / 44 = 5450. This is lower by 9%! Tell me why this can be, where is my mistake? Is the miner configured incorrectly? Log and the file of the confusion I am enclosing.
 https://mega.nz/#F!VponVS7a!dVMraUtitFxEnegGc4QsMg

I used the proxy with SRBMiner with good results, and tested with XMR-stak also. However, I need to add TLS support and that means I have to learn more stuff. I could also employ the max allowed difficulty in the pool switch too, it may be another parameter in the coin-switch (auto coin switch is in the works, not working ). When thing get stable enough for SRB (it never does, it's a continuous fight against new drivers and windows updates and new algos) but if at all, coin switching through job json would be super awesome (without miner restart ;=) ), to overcome the namespace problems (everybody is calling some algo differently) since there's no set standard for algo names, you could go with e.g. "_SRB_powtype": "CryptonightV7" , so the proxy can add that to the job json..

But in future if the algo names follow standards, pools can send the "powtype" for any job, this way they can signal miners any algo change due to forks etc. with no problems, so hashrates are not lost with people trying to guess when the fork is going to happen, e.g. they could send "CryptonightHeavy" for block 30000, and "HavenAlgo" for block 30001 so the change would be seamless (even for miners that would need a restart, they would restart at the proper time!), this would be very good for a comfortable transition to new algos. A man can only dream

I am going to re-think is integrating coin switching worth the time and effort because its not as simple as i thought.
First idea was to use minecryptonight.net API which is so easy, just give it your hashrate and it returns the most profitable ($$$) coins.

But when you mentioned switching by difficulty, etc here things got more serious

As you are already working on that proxy, i will probably leave it to you, and i will focus more on the 'miner things' , i should find the cause of why does kernel recompilation sometimes creates 'better' kernel. There are a lot of parameters used internally, not visible to the user.
I have to go back to debugging the opencl kernel, this will take some time.
Also i want to make miner more stable, as some users are experiencing stability issues i can't reproduce

Back to the proxy, i did not check it out, but as in the current state, it can to coin switching for SRBMiner too?

Also some info :

Next version in a day or two , with support for the upcoming Masari and Haven forks. It's already integrated and working, but i want to be sure  that everyting is ok before releasing the new version

Certainly that was not the case for heavy coins. You could mine 5 units per hour in one half of the day, 8 units in the other half. You may guess which half is the better choice. Market value does not have to be the ultimate decision factor.