 Show Posts
|
|
Pages: « 1 [2]
|
Hi man + others
Thanks for the info, these are my new set of results; (double threads = true)
I cannot push this over 86 with 80 being most stable (5200+ hash)
ALL CARDS ARE 8GB
"gpu_conf" :
[
{ "id" : 0, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0},
{ "id" : 1, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0},
{ "id" : 2, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0},
{ "id" : 3, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0},
{ "id" : 4, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0},
{ "id" : 5, "intensity" : 86, "worksize" : 8, "threads" : 2, "kernel" : 0}
]
}
[2018-06-08 15:09:52] GPU0: 896 H/s [T: 57c, RPM: 2187, CC: 1150 MHz, MC: 2175 MHz][BUS:5]
[2018-06-08 15:09:52] GPU1: 842 H/s [T: 72c, RPM: 2128, CC: 1150 MHz, MC: 2175 MHz][BUS:1]
[2018-06-08 15:09:52] GPU2: 848 H/s [T: 60c, RPM: 2031, CC: 1150 MHz, MC: 2175 MHz][BUS:4]
[2018-06-08 15:09:52] GPU3: 852 H/s [T: 63c, RPM: 2127, CC: 1150 MHz, MC: 2175 MHz][BUS:3]
[2018-06-08 15:09:52] GPU4: 893 H/s [T: 54c, RPM: 2918, CC: 1150 MHz, MC: 2175 MHz][BUS:2]
[2018-06-08 15:09:52] GPU5: 893 H/s [T: 44c, RPM: 3036, CC: 1150 MHz, MC: 2175 MHz][BUS:6]
[2018-06-08 15:09:52] Total: 5224 H/s
If I do I get this error:
Error CL_MEM_OBJECT_ALLOCATION_FAILURE when calling clEnqueueNDRangeKernel for kernel 0 for DeviceID 1 (Thread 3)
Set the intensity 72, it is the best for v7 at 588, decreasing temporarily the memory frequency for the test. 588 with such settings should produce about 950-970 hashes v7 |
|
|
|
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 ? Yes, I will obey your advice about 24 hours and the change of the miner, thx. You do not steal a hash, since all the shares that the miner finds reach the pool. But the hasht at this point is actually lower than the miner draws.  Why this happens, I do not know. I came here for help, because I did not have enough of my knowledge. But if you do not know, then I do not have anyone else to turn to ... |
|
|
|
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.
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? |
|
|
|
sorry but this is similar to the ones like : "calculator shows 50% more profit then i get. why is that?"
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 ....   |
|
|
|
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
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. |
|
|
|
... are you like SERIOUSLY asking this ? or just joke?
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. |
|
|
|
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 |
|
|
|
still huge hr fluctuations on heavy?
Still sometimes...  |
|
|
|
Dear, everything was fine for two days on the new version 1.5.3. He looked at the computer and again hdrop . There was not even any switching between the pools.  |
|
|
|
http://prntscr.com/jgvj1nI did not make screenshots until this moment, I tried to overcome the problem myself. I changed the riser, power supplies, added RAM, changed the priorities of the processes, intensity, voltage, timings, danced around the computer and so on. But nothing helps Hash changes to the heavy algorithm for + -100 and nothing can be done about it
|
|
|
|
To follow up my own post about pool switching, currently, pool switching causes hashrate fluctuations (at least for Cryptonight Heavy), although technically it shouldn't be much different from getting a new job from the same pool as far as performance is concerned. The fact that there are fluctuations after switching could lead you to find the problem that causes the fluctuations to begin with, maybe it will make it easier to debug that.
Just half an hour ago SRB did an auto switch and the hasrate dropped by 500 mh/s, and it's very slowly recovering. A manual switch also causes hashrate drops.
Same problem. When you run the miner on a heavy algorithm, a hasht is random. The maximum can go out after 5 minutes and after 6 hours. After switching to another pool or developer pool, the hash may also decrease, or it may remain the same. Videocards radeon 588, if it helps to establish the cause. |
|
|
|
|
