Pages:
Author

Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 75. (Read 90841 times)

newbie
Activity: 156
Merit: 0
Both memory model and openCL code of version 0.32+ are completely new.
It's somehow like Claymore 9 and 10+ : maybe better, maybe worse, but completely different. I cannot go back to the long-compiling versions, now i must still improve the new code.

Good news !
Code:
Detecting OpenCL-capable GPUs...
Calling clGetPlatformIDs
Returned CL_UNKNOWN_ERROR -1001
Found 0 OpenCL PlatformIDs
0█└☻

I can reproduce the no-gpu bug on my Win7+betablockchain rig i just installed, and on which i'm writing from right now. I didn't find the cause yet, but i can reproduce!

edit: Bad news this time
I found the reason it failed on Win7 is that my protection technique of injecting my opencl code directly into the drivers, bypassing the normal way of calling OpenCL compiler, to prevent hackers to dump my code on the fly, is just not compatible with Win7. I've the choice to give up security, or to giveup Win7 support. I couldn't find any way to keep both, so I drop Win7 support on the GPU part (cpu mining still works down to Vista 32).

Sorry JuanHungLo for the bad ending, but at least i fully understood the problem. Other miners work because they use a clear openCL api, I use a hacky one, on purpose, for security.
I'll update my documentation to state Win7 is not supported. I tested on Win8.1 and it works fine.
Maybe it's even better. Windows 10 often gives more mining speed than Win7. Windows 10 with at least 4Gb vmemory works with the same speed as Win7, and often quicker. I not understand why use Windows 7 at all.
For these, who affraid Win10 spying and many unuseful options and apps, exists LTSB version of Windows 10 wich have minimal size and don't have many apps... Just google Windows 10 LTSB.
all this protection would make sense if your miner was 20,30,50% faster than the others. But.its not the case  Roll Eyes
hero member
Activity: 935
Merit: 1001
I don't always drink...
Both memory model and openCL code of version 0.32+ are completely new.
It's somehow like Claymore 9 and 10+ : maybe better, maybe worse, but completely different. I cannot go back to the long-compiling versions, now i must still improve the new code.

Good news !
Code:
Detecting OpenCL-capable GPUs...
Calling clGetPlatformIDs
Returned CL_UNKNOWN_ERROR -1001
Found 0 OpenCL PlatformIDs
0█└☻

I can reproduce the no-gpu bug on my Win7+betablockchain rig i just installed, and on which i'm writing from right now. I didn't find the cause yet, but i can reproduce!

edit: Bad news this time
I found the reason it failed on Win7 is that my protection technique of injecting my opencl code directly into the drivers, bypassing the normal way of calling OpenCL compiler, to prevent hackers to dump my code on the fly, is just not compatible with Win7. I've the choice to give up security, or to giveup Win7 support. I couldn't find any way to keep both, so I drop Win7 support on the GPU part (cpu mining still works down to Vista 32).

Sorry JuanHungLo for the bad ending, but at least i fully understood the problem. Other miners work because they use a clear openCL api, I use a hacky one, on purpose, for security.
I'll update my documentation to state Win7 is not supported. I tested on Win8.1 and it works fine.

Thank you for your extra time and research.  I still continue to use your miner on all of my Win10-Vega56 rigs.  Awesome work.  Now I need to consider the upgrade to LTSB version of Windows 10 on a dozen or so rigs.  Hmmm.
sr. member
Activity: 1484
Merit: 253
JCE, i can't understand, why miner can't allocate all of 4Gb vmemory of my 270X. Max it can use is 3,5Gb. If I set multihash to use higher than 3Gb, miner gives CL_memory allocate error...
In info about devices at start miner shows that card have 4Gb vmemory...
sr. member
Activity: 1484
Merit: 253
Both memory model and openCL code of version 0.32+ are completely new.
It's somehow like Claymore 9 and 10+ : maybe better, maybe worse, but completely different. I cannot go back to the long-compiling versions, now i must still improve the new code.

Good news !
Code:
Detecting OpenCL-capable GPUs...
Calling clGetPlatformIDs
Returned CL_UNKNOWN_ERROR -1001
Found 0 OpenCL PlatformIDs
0█└☻

I can reproduce the no-gpu bug on my Win7+betablockchain rig i just installed, and on which i'm writing from right now. I didn't find the cause yet, but i can reproduce!

edit: Bad news this time
I found the reason it failed on Win7 is that my protection technique of injecting my opencl code directly into the drivers, bypassing the normal way of calling OpenCL compiler, to prevent hackers to dump my code on the fly, is just not compatible with Win7. I've the choice to give up security, or to giveup Win7 support. I couldn't find any way to keep both, so I drop Win7 support on the GPU part (cpu mining still works down to Vista 32).

Sorry JuanHungLo for the bad ending, but at least i fully understood the problem. Other miners work because they use a clear openCL api, I use a hacky one, on purpose, for security.
I'll update my documentation to state Win7 is not supported. I tested on Win8.1 and it works fine.
Maybe it's even better. Windows 10 often gives more mining speed than Win7. Windows 10 with at least 4Gb vmemory works with the same speed as Win7, and often quicker. I not understand why use Windows 7 at all.
For these, who affraid Win10 spying and many unuseful options and apps, exists LTSB version of Windows 10 wich have minimal size and don't have many apps... Just google Windows 10 LTSB.
member
Activity: 350
Merit: 22
Both memory model and openCL code of version 0.32+ are completely new.
It's somehow like Claymore 9 and 10+ : maybe better, maybe worse, but completely different. I cannot go back to the long-compiling versions, now i must still improve the new code.

Good news !
Code:
Detecting OpenCL-capable GPUs...
Calling clGetPlatformIDs
Returned CL_UNKNOWN_ERROR -1001
Found 0 OpenCL PlatformIDs
0█└☻

I can reproduce the no-gpu bug on my Win7+betablockchain rig i just installed, and on which i'm writing from right now. I didn't find the cause yet, but i can reproduce!

edit: Bad news this time
I found the reason it failed on Win7 is that my protection technique of injecting my opencl code directly into the drivers, bypassing the normal way of calling OpenCL compiler, to prevent hackers to dump my code on the fly, is just not compatible with Win7. I've the choice to give up security, or to giveup Win7 support. I couldn't find any way to keep both, so I drop Win7 support on the GPU part (cpu mining still works down to Vista 32).

Sorry JuanHungLo for the bad ending, but at least i fully understood the problem. Other miners work because they use a clear openCL api, I use a hacky one, on purpose, for security.
I'll update my documentation to state Win7 is not supported. I tested on Win8.1 and it works fine.
newbie
Activity: 2
Merit: 0
0.32a no more bad shers  Smiley
550/460 no difference compare to 0.31f
0.32a on vega 64 CC ~1407 MC 1099 i got 2153 h/s v7 wich this config :
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 4, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : x, "multi_hash":2000 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 4, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : x, "multi_hash":2000 },
on 0.31f i can get 2135 h/s wich :
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 4, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : x, "multi_hash":1968 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 4, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : x, "multi_hash":1968 },
when i increase multi_hash above 1968 on 0.31f hashrate get lower
drive 18.5.1
member
Activity: 145
Merit: 10
Just tried out 32a with the auto function and im getting CL_MEM_ALLOCATION_ERROR on one thread. The thread number that fails is random. Reducing the multihash value to 1840 solves it but it seems like there is a lot of speed left on the table

I have tried reducing the memory clocks all the way down but it still fails. This is on an 8x vega56 rig.
full member
Activity: 729
Merit: 114
P.S. Looks like at start and during several minutes in heavy algo speed every time differs...

I don't get this behavior while mining cn-saber.  I haven't tried cn-heavy.  Will report back.

EDIT: Yup I get fluctuating hash rates.  Kind of swings between 50-75 H/s range from avg total.
sr. member
Activity: 1484
Merit: 253
JCE, please, add in report speed statistics for periods of time. An half hour, hour, etc...
And it's need minrigspeed option to restart miner if speed lower than pointed in option for 5 min or time pointed in 2nd option minrigspeedperiod.

P.S. Looks like at start and during several minutes in heavy algo speed every time differs...
member
Activity: 190
Merit: 59
I don´t really want to go through that discussion again. I don´t care what is shown on the screen. If one miner, over the span of 10 days, gives 10 billion hashes and another gives 9 billion hashes, but both shows 12KH/s, then these miners are not the same speed. One is real (JCE, XMR-Stak) and another is fuckin´ liar and cheater.

Cheers Smiley
full member
Activity: 729
Merit: 114
In fact, JCe-miner is the first closed source miner that reports spot-on hashrate as the pool does.

Srbminer and cast-xmr report way more than pool. XMR-stak reports accurate, but the JCE is much faster

not really. it depends.  I have been using other miner and in fact, I get higher avg hashrate than the miner reports at the pool side.  Right now JCE gives me higher at least on Tube.
sr. member
Activity: 1484
Merit: 253
JCE, I think you must change string when kernels compiles. It still writes "...it will be long..." Now it quick )))
newbie
Activity: 18
Merit: 1
Quote
@JCE-Miner

Is it possible that the config generated by the --auto option can also be written in a text file or at least showed in the output?
I have good results for the Vega on the auto config and it would be nice to know the parameters of the config just in case i want to use the -c option later on.

Tnx dev.
Keep up the good work!

Lol ... It is already in the output ... i didn't notice.

member
Activity: 190
Merit: 59
I started 032a on one of my rigs. 032 had many invalids at start, 032a has a good start without invalids Smiley
member
Activity: 190
Merit: 59
In fact, JCe-miner is the first closed source miner that reports spot-on hashrate as the pool does.

Srbminer and cast-xmr report way more than pool. XMR-stak reports accurate, but the JCE is much faster
member
Activity: 350
Merit: 22
this is the total amount of shares found, divided by the uptime.
Said differently, the full average of effective speed (taking into account shares really found, ignoring fees and rejected stale shares).

It should be the same as reported by your pool, minus ~1% since some shares are reported good because of ping but are dropped at last instant by the pool. Most pool do that, the notable exception is Nicehash who explicitely refuse any stale share, even cause by ping delay. Hence why you get more reject on Nicehash.

Optimal settings of 0.32+ may be different from previous versions since the code is all new.

Version 0.32a online

Same as 0.32, but bad shares are fixed.
0.32 is removed from github.
full member
Activity: 729
Merit: 114
@JCE-Miner

is the net effective hashrate the cumulative of 46 hours of mining?

13:53:32 | Total: 7277.79 h/s - Max: 7289.39 h/s
13:53:34 | GPU 3 Thread 3 Lane 688 finds a Share, value 100001
13:53:34 | Accepted by the pool.
13:53:36 | Pool mining.bit.tube:13333
13:53:36 | Currency BitTube (TUBE)
13:53:36 | Current pool Difficulty 100001
13:53:36 | Valid Shares found 11877
13:53:36 | Total hashes 1186051850
13:53:36 | Miner uptime 46:18:46
13:53:36 | Effective net hashrate 7113.78 h/s
sr. member
Activity: 1484
Merit: 253
Tested new 32 version. Works fine. Especcially fast compiling - it's amazing! Thanx for it!

But I noticed that settings for GPU's now optimal some other than before. Maybe it's due to 18.7.1 driver.
Now best m.hash for heavy algo is 944, not 832 or 864...
For normal V7 close to twice m.hash from heavy.

And i noticed that speed now not so stable on heavy algo. It jumps +50-100 h/s up and down even after 10 minutes of mining...
member
Activity: 190
Merit: 59
Great, thanks! Fast compiling is really amazing, the rig that was starting 15 minutes before, now starts in seconds, this is really useful for testing and troubleshooting
member
Activity: 350
Merit: 22
i'm turning one rig to win7 + betablockchain, but i've very little time to test everything.
I could reproduce the bad share bug, now fixing.
Pages:
Jump to: