Ups, only read the last two messages here after merging Wolf0’s kernel into the master-branch. So master-github is now on 3.7.8 including wolf’s current kernel.
I have tested it on an Nvidia GPU and had no issues, but running only for short periods of time. Let’s monitor that.
Did you notice any extra performance with 3.7.7c? I just compiled it tonight and didn’t notice any difference. One thing I will mention for anyone who decides to try 3.7.7c, is that it was actually overwriting my 13.x bin files with new 14.x ones. You need to follow the directions from seand52 about copying AMD driver files on this other post unless you want 100% hardware errors (or grab 3.7.7c from my dropbox):
https://forum.feathercoin.com/index.php?/topic/7978-hw-errors/
https://www.dropbox.com/s/waedf2ghtc33zun/NeoScrypt-3.7.7c.zip?dl=0
Please read the git log before complaining. 3.7.7c is a stability release that does not strive for any further speed up.
Please add support for old cards, 5800 6800 6900 series. Please!
Cards that lack the byte-addressable capability can’t be used for neoscrypt currently. Rewriting the algorithm to get rid of the necessity of byte addressing is not in the currenty scope.
Thanks :)
that file says '-thread-concurrency,******but when i try that it says unrecognized **
what is the way to set concurrency in this neo miner?
Thread-concurrency is obsolete now. The thread-concurrency and intensity flags both controlled the same, allowing one to override the necessities of the other and therefore possibly allowing for memory corruption and bad results.
Has anyone compiled https://github.com/vehre/neo-gpuminer from source on Linux and successfully mined PXC or FTC on the testnet? All I get are hw errors, with any settings I’ve tried. Specifying no options to cgminer beyond a stratum connection and user/pass, or using even a bare minimum of -I 12 -w 32 -g 2 doesn’t help. I’m on 14.6 catalyst drivers with APP SDK 2.9.
I’m happy to provide any additional logs/info/settings or help troubleshoot if anyone has any suggestions.
The bare minimum would be -I 8 -w 128 and -g 1
I am mining PXC on the life net and have no problems yet. FTC is not yet on neoscrypt therefore mining on testnet is ok and should work, although I haven’t tested.
Cheers Tmuir,
however my conf is virtually identical to yours. Plus, and where it changes, I have tried a range if Intensity from 3 to 14. (so that is unlikely to be the problem I am encountering).
Cross you fingers, my problem is due to a “different file” left by over by AMD 14.9 driver (other than the cgminer .bin(s), which I already deleted as part of testing (of course)).
Intensities below 8 are reported to be illegal and will not be consired.
It’s very confusing to find how to get neoscrypt mining going, and where to post problems. There is no one description of where things are and generally how to do them and confilicting posts. (posted this in the mining thread by mistake, last night)
Report issues at:
Hi curiosity81,
what developerS? As far as I know, is there only one actively (more or less) doing development on cgminer for neoscrypt.
Anyway, on a 32-bit system size_t usually is a 32 bit value. I.e., any data one wants to store in there has to be less than 2^32. What happens, when that value is exceeded is undefined. In your case the system resided to use 0, which shouldn’t be. I will take a look into it, as soon as possible.
Could you meanwhile file an issue at:
https://github.com/vehre/neo-gpuminer/issues
so that I don’t forget about this?
As a work around try to start cgminer with a low intensity, i.e., start with -I 8 and raise it untill cgminer can’t alloc the buffer anmore. The default of cgminer is to use dynamic mode, with tries to allocate a buffer as large as the one you pointed out, but I did not think about system with 32-bit. I am sorry for the bother.
Regards,
Andre
You can’t be using the latest cgminer 3.7.7b, when thread-concurrency is supported by the neoscrypt kernel. 3.7.7b dropped that support in favour of computing the amount of memory needed itself.
Note, when scrypt was selected during configure (autogen.sh), then the command-line option will be accepted, but is not used for neoscrypt.
What did you expect? The kernel in the regular cgminer has not gotten any optimizations. Unfortunately most of the time was spend in figuring the changes in the protocol.
To get more out of the HD5870 try to play with the worksize -w and intensity -I
I suggest starting with -w 128 and -I 8 and than increasing -I in steps of one untill the memory can’t get allocated anymore
and retry this series with -w 256 and -w 512, then choose the best result for your card and system.
Allways note down the number of hashes you get while running for an equal number of minutes.
Text file: windows.build.txt that comes with cgminer is a very description. Try that first, please.
Plus: Coding opencl is really nightmare: Comment one line or add one useless line will cause the result 100% different.
Sorry for my national holiday, but the result is exciting.
I totally agree, coding OpenCL is a nightmare. Unfortunately I can explain the theory, why this happens: The SIMD modell is playing against us. Adding or deleting instructions, that threads have to skip or used to sync execution heavily plays into overall performance.
Let’s look at the code at the end of fastkdf():
if (a >= output_len)
// copy
else
// merge
Now “a” depends on the input data, the chances that for a bunch of threads trying to execute this conditional on multiple (different) data - remember every thread has its own distinct data - makes some threads execute the then part, while others do the merge part. SIMD now dictates that all threads execute the same instruction or skip it. Or with other words: All threads execute both parts of the conditional. Now, OpenCL is able to switch off some of the threads, i.e., the threads sees the instruction, but does not execute it. It idles. The compiler tries to handle this, but is not always successfull.
So if just one thread needs to execute the other part of the contidional than all other threads, then nevertheless all threads will step through all instructions in both the then and the else branch.
So far just for the background. :)
Would also love to see NeoScrypt ported to sgminer. Sgminer is much less trouble to setup, less failure.
The issue is not porting the cl-kernel to sgminer, but the changes neccessary to cope with the changes in the network protocol.
So just to wrap it up:
-w should be the preferred worksize of the GPU. This is usually a value evenly divideable by 64 and I haven’t found a GPU yet, where this value is beneath 256. That is why cgminer chooses 256 as the default for worksize.
The HW errors occuring with 3.7.6x are most likely due to me failing to ensure, that the thread-concurrency had a value equal to or greater than the worksize. I am currently working on a version where I get rid of the thread-concurrency completely and make use of the worksize only. Thread concurrency is of no use in neoscrypt and makes sense in scrypt only (at least to me).
My current setting on an Nvidia Geforce 218 is:
-w 512
The thread-concurrency is implicitly set to 512 currently. My intensity is set to default (dynamic).
I don’t use configuration files, but only command-line settings. When you use configuration files, make a backup and set worksize back to 256 or 512 depending on what your gpu prefers (removing the line completely makes cgminer select the devices preferred value). Next make sure thread-concurrency is set to worksize or a greater value (again removing the line, make cgminer use a reasonable default value). Setting thread concurrency to a value significantly greater than the worksize wastes memory only.
(opt_neoscrypt|| opt_scrypt)? 84: sizeof(work->data), true))) {
have no idea how it compares to setting of my miner but i get most stable and fast hash with value -w 84
That line of code has certainly nothing to do with the worksize. The line you have copied there, is taking care about correct communication when solo mining.
as i see this is only change between them???:
- (get_global_id(0)% CONCURRENT_THREADS)];
- (get_global_id(0)% WORKGROUPSIZE)];
Correct, this is the only change direct change in the kernel. May be I have missed something in the miner corelating with this.
Advice: when you use config-file for running the miner, then please remove the “thread-concurrency” : N from the config-file, if N is smaller then the worksize!
Sorry for being imprecise. I am interested in the about last 1000 lines of the log, when the miner aborts on its own after running for 3-5 hours.
Please add those lines to the tickets on github.
Could you open an issue at https://github.com/vehre/neo-gpuminer/issues for every issue that occurs?
This helps to keep track about problems, when they occur, and if they have been processed, resolved and when.
Thanks for helping.
Hi raintowers,
can you run the miner with -TDP and log the output to a file? Send me the about last 1000 lines of the file, please.
That looks quite fine. Please retry mining setting intensity significantly lower, I.e. to 8 or even less (-i 8)