Sure can let me get to my other laptop where they are so I can be sure the version numbers I post are correct.  Edit: here is pretty much the full list of what I have on this rig, shop rigs have many more. I hardly ever delete anything and the biggest reason most of my HDD's are so full. lol Forgot to mention everything I have is open source and public free miners. I have no private miners. Only reason I said anything is because some of I have may no longer be able to be found for download.  Forget the AMD stuff. |
|
|
|
Good luck with neo, its the same headache on ccminer, so i dont touch it  I couldn't believe it but now I can't reproduce the same hashrate on the original. Time to put it aside and clear my head. I'm a little frustrated with the problems with windows compile, grs, and now neoscrypt. I'll take another crack at it when my head is clear. Moving on. I found a few cpu miners, neoscrypt based & a few other I zipped into one package for you. Not sure if they will be of any help, I also have some GPU neoscrypt miner 3.7.8 & below if you'd like to take at look at those I can add them to the same zip package & host them somewhere? 8 TH didn't get much better results +100 or so, test picture below. As you can see the VB didn't fully load the cpu 100% so the top numbers this setup could do isn't shown with this miner threw VM.  Edit: Strange while I was off in the windows OS getting this post ready the speed & load on the CPU improved to around 98/99% load, temps were about the same.  Thanks for posting your results, Can you give me a list of the miners you've found? That will save some time testing all of them because I probably already have a few of them. New release coming real soon with hash rate increases in all algos and a new one. |
|
|
|
Good luck with neo, its the same headache on ccminer, so i dont touch it I couldn't believe it but now I can't reproduce the same hashrate on the original. Time to put it aside and clear my head. I'm a little frustrated with the problems with windows compile, grs, and now neoscrypt. I'll take another crack at it when my head is clear. Moving on. |
|
|
|
|
Another update on neoscrypt. More bad news but some potentially great news.
First the design is much more complicated as it supports 4 ooptimizing options that can be
mixed. That makes 2**4 combinations if they are all valid, which I don't think is the case.
However, it looks like my posted speed test was done with all options disabled, likely the
most compatible but slowest configuration. Yet this was still faster than v2.0.
Unfortunately the options I coded (all enabled) didn't work. I now have to take a step back
and do some testing on the original cpuminer-neoscrypt to find out what combitions work and
which is the fastest.
No new release for a while.
|
|
|
|
|
I have a request for some focussed testing of cpuminer.
I would like some confirmation that the cpu capabilities checking is correct with no false positives
or false negatives.
I need someone with older cpus to test cpuminer on an algo with multiple supported kernels
looking for two things:
1. cpuminer selected a slower kernel when it should have chosen a faster one. You would observe
this at startup.
2. cpuminer selected a faster kernel on a cpu that doesn't support it. This will likely cause
cpuminer to crash.
Thanks
|
|
|
|
|
Yesterday was pretty much a wasted day. Ispent all day trying to integrate cpuminer-neoscrypt
and now I'm back at square 1.
It has a two dimensional matrix of capabilities: 2 arch, and asm or not. And he coded it such
that it is almost impossible to compile more than one variation at a time. eEverithing is hooked
with #If.
I came to the conclusion this is going to require some significant reimplementation. I've decided
to only focus on the highest performing variation for the first release. I'l work out the rest at a
later date.
I will take this approach for cryptonight and argon2 and any other new algo additions in the future.
I got a little cocky with the ease in which I implemented the x11 and quark improvements.
Lesson learned.
|
|
|
|
I'm having trouble getting ccminer.exe to run in WINE. I looked through the threads a bit after failing to get it to work. Seems there are mixed results out there. wine ccminer.exe -q -a quark -o stratum+tcp://stratum............ get error Driver does not support CUDA 5.5 API! Update your nVidia driver! Card is GTX-750ti, OS Xubuntu 14.04, CUDA 7.5, nVidia driver 352.68. Pretty sure that's all up to date. What am I missing? Ask jublo, he made it working. Wich ccminer exe file are you trying to run? would the windows version run on Linux via wine?
No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening. It's fucking happened already. I've done it and confirmed I get full hash rate. The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time environment. All it needs is a common driver interface to talk to the host. I'm not sure if everything worked with the open source ccminer so I won't assume anything. Your OS is two years old and ccminer was compiled with the latest cuda 7.5, likely a compatibilty issue. Check if cuda 7.5 and the supported drives are available for your version (X)Ubuntu. You don't need cuda to run ccminer but you have to have drivers compatible with the cuda version used to build it. If you can't get cuda 7.5 supported drivers for your OS you'll have to upgdade the os or ask SP to build with 6.5. |
|
|
|
cpuSminer S=speed or cpuminer-s Thanks for posting your results. Strange is I get many more shares at the other site vs NiceHash? Wonder why that is? or I should say they seem to come in at a much quicker pace. Wondering if I can clone the VM and move it to another rig, should be possible I would think. If there is to much different in the rigs the kernel may crash of the OS. Might set up another VM on this other laptop for testing that. But then again the virtual HDD is 50GB and my 64GB USB drive is full with other saved stuff, I'll try transferring it across the network lan. Edit: Got to clean up my HDD's on this other laptop first didn't realize they were so full 240GB SSD & 500GB IDE both almost full. lol Between Wallets, miners & games it doesn't take long. Not counting in the many .iso of OS I have downloaded to try out.  The share rate is determined by the difficulty. Pools adjust the difficulty based on the hash rate to prevent powerfull miners from flooding the server frequent small shares. With very low hash rates the difficulty can reach the minimum while still not achieving the target share submission rate. Edit: check the hashrate at the pool. I've noticed that the infrequent share submission results in the pool reported hash rate fluctuates from -50% to 200% of cpuminer's reported hash rate, which tends to average out at 100%. If the pool reported hash rate is consistent below this range then there may be a problem. A key thing to remember is that the miner reports the share rate not the share size. So the shares are less frequent but larger, everything else being equal. Hope this helps. |
|
|
|
cpuSminer S=speed or cpuminer-s Thanks for posting your results. |
|
|
|
Now how "bad" is the TLB trashing in wine?
As bad as in windows
or as bad as in linux?
anyone knows?
I know TLB trashing is a hardware limit yet linux "behaves" best with windows 7 slightly behind it and
windows 8.1/10 is total garbage in this regard.
I don't know but if it affects mining perfornance I'd guess there is no difference given the performance is the same. I'm specutating* too much. I should stick to what I know. *That's the second interesting typo today. I think i'll copyright it. It even works in this context as a mix of speculating and spectating. |
|
|
|
would the windows version run on Linux via wine?
No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening. It's fucking happened already. I've done it and confirmed I get full hash rate. The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time environment. All it needs is a common driver interface to talk to the host. As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers, just the cuda tools. I've done that too. Yeah, no shit - I know this. I also know at least in the case of AMD, you need to call into the driver to load the binary ONTO the GPU. How exactly does Wine handle this without explicitly catching the calls and making sure it calls into the Linux lib, which will properly handle it from there? Maybe Nvidia has a different system for this, I don't know. Sounds like an inferiour design on AMD. Linux sits between wine and and the driver, it just provides an api to direct windows system calls to the linux versions. The gpu talks to the windows ccminer via apis in wine but all it has to do is obey the command to accept a cuda binary file and run it, then send the results back to ccminer on the host. Nothing more than a simple command interface and data transfer are needed. I don't know why it's so difficult for AMD. The GPU talks to the host driver so it can talk to any linux process, that's it's access to the file system. Wine doesn't need to handle it. Wine only gets involed when giving commands to the gpu or talking to windows processes like the file system when retrieving the results. It's probably the shitty AMD drivers. Maybe the GPU thinks it's running on windows and thinks it's the victim of spoofing or something. AMD drivers are fucking terrible, granted - but I would think it should work mostly the same way... maybe WINE doesn't yet have support for it with AMD? I don't know why they'd need to. Sending commands from the windows app to the gpu should be through a standard interface and the gpu bypasses wine for file transfer. |
|
|
|
would the windows version run on Linux via wine?
No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening. It's fucking happened already. I've done it and confirmed I get full hash rate. The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time environment. All it needs is a common driver interface to talk to the host. As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers, just the cuda tools. I've done that too. Yeah, no shit - I know this. I also know at least in the case of AMD, you need to call into the driver to load the binary ONTO the GPU. How exactly does Wine handle this without explicitly catching the calls and making sure it calls into the Linux lib, which will properly handle it from there? Maybe Nvidia has a different system for this, I don't know. Sounds like an inferiour design on AMD. Linux sits between wine and and the driver, it just provides an api to direct windows system calls to the linux versions. The gpu talks to the windows ccminer via apis in wine but all it has to do is obey the command to accept a cuda binary file and run it, then send the results back to ccminer on the host. Nothing more than a simple command interface and data transfer are needed. I don't know why it's so difficult for AMD. The GPU talks to the host driver so it can talk to any linux process, that's it's access to the file system. Wine doesn't need to handle it. Wine only gets involed when giving commands to the gpu or talking to windows processes like the file system when retrieving the results. It's probably the shitty AMD drivers. Maybe the GPU thinks it's running on windows and thinks it's the victim of spoofing or something. |
|
|
|
would the windows version run on Linux via wine?
No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening. It's fucking happened already. I've done it and confirmed I get full hash rate. The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time environment. All it needs is a common driver interface to talk to the host. As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers, just the cuda tools. I've done that too. |
|
|
|
THE FROZEN CPU MINER--
Sorry, I just watched Ted 2 on DVD... and remember an old SNL skit. JBM is perhaps too simple... --scryptr
Phew, I was thinking of another movie with a frozen theme intended for a young audience. I googled cpuminer-opt and the only thing it found was this discussion. So it's all set. Thanks to Tanguy for suggesting it. |
|
|
|
Things are progressing well with the integration of the faster neoscrypt kernel. It's almost ready
to compile, just cleaning up the declarations and definitions to avoid collisions.
I noticed that the hash functions are all declared in miner.h. Is that necessary? Isn't the scanhash
function the gate to the algos? And more importantly could this be at the root of my multiple
def problems with GRS on linux and whatever else on windows? All these macros get imported
to the hash function and the declaration in miner.h makes them visible to the world.
Wolf, do you think I'm on the right track?
Ice cold, I believe. I haven't checked in depth, but I'm pretty sure your issue is two seperate implementations of the same shit. There in fact two seperate implementations of the same shit, all the spf stuff. I may have selected one version in one algo and another version in another. Hmmm, something else to follow up on. I planned on cleaning that up any way, I think the versions are identical. I didn't want to rush that as there may be a better version. I still think there is merit to my theory when I think about it more. The macros are all run by the hash function, and being macros have global scope in the file. Declaring the hash functions miner.h exports it to the world where the linker finds it and the 5 copies of each macro. On the other hand it doesn't happen with the other macro based algos so what do I know? |
|
|
|
Private kernal for sale. 0.1BTC
Release 2 sp-mod private (750ti) (faster than release 78)
x11: +2.4%
x13: +5.4%
x15: +4.5%
lyra2v2: +6.45%
quark: +3.2%
qubit: +2.3%
I wish I could code cuda. I have added 2-300khash in the quark algo on gtx 970. Now peaking at 19.45mhash with +155 on the core.(g1 gaming). Will be included in sp-mod private 3 Ppl want a linux version. I don't want to release the sourcecode. So no linux. Switch to windows, or loose hashrate:) wow ... so you are willing to 'lose' the support of linux miners to try and push them towards windows? ... not likely sp ... and something i will NEVER do with the total costs and instability and the sheer work involved in such a stupid thing as that - especially with a farm ... if farm owners WANT to do that - then fine ... but those who will stick to linux - like me - will research ( or commission ) another way ... no tanx - ill just add a few more powerful cards - and find a better way ... #crysx Kinda shitty to try to hide it behind the "I dun wanna release source" lie (the lie being the insinuation that linux support requires source.) there has to be a better way of doing 'all this' wolf ... im actually getting disheartened by the whole crypto scene the way it is - and its driving me to think about whether its a good idea to stay in the open like this - or fall into the background and just 'watch' the workings of development and crypto - while utilizing the offers that come our way on occasion ... is it any wonder why the HUGE farms only get bigger? ... not releasing YOUR source is one thing - not releasing OUR source is another ... which is exactly what oss is all about - its OURS ( as in the community ) ... im linux all the way - and i wont change ... stubbornly refuse to give in to the closed system ... paid miners and paid software and paid systems are one thing ... but to do this that sp is saying he wants to do - that has now got my nose out of joint also ... i wont bend to such things - and agree that it is not right to state such things with the purpose of holding the source code for private use only ... im a supporter of both oss AND the devs ... you know this - sp knows this - the community who know what im about know this ... but thats statement is ludicrous ... i just need to find and settle in my new place - and rebuild the new farm ... only a few months away ... then we can talk business ... #crysx You know you can run windows binaries, including ccminer, on linux using wine. Just install wine and run wine ccminer ... But then again, considering how much you've contributed you have a right to be a little demanding. In fact your position is very similar to my opinion on the matter. The big guys are the early adopters and pay the development costs of leading edge products. For that they get exclusive rights to the product for a period of time. A win-win I'd say. |
|
|
|
cpuminer-opt also I like it. I don't have a big ego so I don't need my name in it. I think there is already one out there with that name. I'll look into cpuminer-opt being taken, I was going to go with it.. How about Fast CPU MIner as a brand and keep the cpuminer command name? It's hard to call it fast compared with GPUs but it's the fastest CPU miner available (that is a challenge to anyone with anything better) and getting faster. JMINER--- Or something simple. --scryptr yup - im all for simple to ... jbm ... i like it ... #crysx It's taken, I also like the idea of paying homage to it's original name. |
|
|
|
cpuminer-opt also I like it. I don't have a big ego so I don't need my name in it. I think there is already one out there with that name. I'll look into cpuminer-opt being taken, I was going to go with it.. How about Fast CPU MIner as a brand and keep the cpuminer command name? It's hard to call it fast compared with GPUs but it's the fastest CPU miner available (that is a challenge to anyone with anything better) and getting faster. |
|
|
|
|
Things are progressing well with the integration of the faster neoscrypt kernel. It's almost ready
to compile, just cleaning up the declarations and definitions to avoid collisions.
I noticed that the hash functions are all declared in miner.h. Is that necessary? Isn't the scanhash
function the gate to the algos? And more importantly could this be at the root of my multiple
def problems with GRS on linux and whatever else on windows? All these macros get imported
to the hash function and the declaration in miner.h makes them visible to the world.
Wolf, do you think I'm on the right track?
|
|
|
|
Fx-8320
Aes-mi enabled
Starts at about 500 Kh/s then drops to about 420.
Never submits any share :-/
What algo? Some take a while for the first share. I tested all supported configurations before release and it submitted shares for all of them. The drop in hash rate is a bit concerning though. No other major cpu activity? Sorry, X11. Drop may be cause of other activity (will fix with priority) or some sort of throttling. Will test more tomorrow. No problem and thanks for testing. I've taken a quick look at the faster neoscrypt cpu kernel (the term doesn't really apply to cpus but whatever) and it seems to have a remarkable resemblence to the ccminer kernel (proper usage of the word). It may be worth taking a look, it might give some ideas for improving ccminer. |
|
|
|
|
Show Posts
