 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
|
Nah, 6.5 on both boxes. Slightly older 6.5.12 on Linux and 6.5.19 (the latest 6.5 + compute 5.2 support I think) on Windows. Tried x64 builds too, doesn't seem to make much of a difference either way. Weird shit. I did manage to make the win build a little better by manually unrolling stuff, just looks like the win version of nvcc isn't really trying to figure stuff out itself. Which brings me back to weird shit.
|
|
|
|
Trying to make a Windows build for the modified lyra is leaving me with a seriously  face. Same exact code and nvcc generates something completely different that actually runs slower than the original, be it on a 970 or another 750 Ti. That in addition to VS insisting on rebuilding EVERYTHING after changing something for a single source file in the project file, gotta love it. |
|
|
|
and a little more  (the 750ti is oc at +200 mem/core, actually core matters more than mem)  Nice, didn't take you too long  I'm thinking we agree on how it should be done, tried that one thing I hadn't had time to try yet  Weirdest thing is power use dropped from 440ish to 400ish |
|
|
|
Hi All Being watching this thread with interest the past could of weeks & decided to move over from ageing old AMD's to Nvidia and build my first 750ti rig. which is now up and running I've got to ask tsiv how are you getting 5700 from the 750ti? mine are only doing 4600  wDragon Wrote a faster version of the lyra kernel. Magic. |
|
|
|
Zero shuffles in this mofo, would run on sm_32 straight as is and 30 for sure after replacing ldgs with regular loads. Probably lower but CBA to check.
Meeeh, actually mining VTC instead of dumbassing it and mining for 0.33 on Nicehash seems to be on par with Nicehash quark profitability, more or less. Curiously enough Westhash is paying 0.6 for l2v2 and it's likely that somebody's still making profit on their orders at that price.
To mine the coins directly is always more profitable. 750ti @ 5.7MHASH is nice. What is the clockrate? True enough, personally I wouldn't have a clue what quark coin to mine though. The cards are Palit StormX Duals at stock OC, 1202 (1281 boost) GPU and 1500 (or 6 GHz) memory. Power usage went up from 380 to 440 W compared to the original miner. Pretty much the same as running quark, probably pretty close to TDP as 440 W is just about high as I've seen that rig pull from the wall. |
|
|
|
Give me coins still hasn't changed their difficulty modifier... One could say they're being... difficult... So, I heard rewriting Lyra2REv2 is all the rage these days...
*pretty picture omitted*
Yea, fortunately it's not that hard to add --diff 0.5 on the command line. Just hoping they give a bit of a heads up before changing it if they ever do. For sale, available, or private?
Undecided, private and for virtual **** waving for the time being. Not very impressed with the OSS + donation model so far, pretty much quit for while but we'll see. Let's just say I didn't exactly drown in donations for the CN and spreadX11 miners, then a certain somebody comes along with some optimizations and decides to sell them for 0.1 BTC. Why bother. A rewrite of lyra2v2 with shfl up instruction is old news. nicehash payouts for the lyra2v2 algo has gone down from 0.8BTC/GHASH on launch and down to 0.35BTC/GHASH making it less profitable than quark even with an optimized miner.
Zero shuffles in this mofo, would run on sm_32 straight as is and 30 for sure after replacing ldgs with regular loads. Probably lower but CBA to check. Meeeh, actually mining VTC instead of dumbassing it and mining for 0.33 on Nicehash seems to be on par with Nicehash quark profitability, more or less. Curiously enough Westhash is paying 0.6 for l2v2 and it's likely that somebody's still making profit on their orders at that price. |
|
|
|
So, I heard rewriting Lyra2REv2 is all the rage these days...  |
|
|
|
Cryptonight sp-mod version 1 exe file has been sendt to the donators. My first afternoon of work gave an increase of around 10% on the 750ti.
This will increase in the next releases.
If you want to join the train please donate 0.2 BTC and recieve both the optimized Spreadminer (with source) and the Cryptonight mod.
my BTC adress is in my signature.
Do you have an estimate on how much extra hash can you squeeze out of your cryptonight miner? On a sidenote, your spreadminer v7 has the lowest fluctuation I've ever seen in any algo. It only fluctuates 1-3 kh/s. I think 30-100% faster is possible but it will take alot of work. I have started with the easy pickings. Big numbers. I know the code is shit but what exactly did you plan on doing to get those improvements? Perfectly optimizing (to zero runtime, not possible but for the sake of argument) everything but the core phase 2 gives you 21% which would be nice of course. Then you have a loop with 262144 iterations, each of which does something like 8 16-byte reads/writes to pseudo-random locations in the 2MB scratchpad. No way to get coalesced memory access and the GPU can't do shit to hide the memory latencies because you're running a really really small work, due to being limited by the 2MB / thread scratchpad requirement. |
|
|
|
Guys cheap spr at Bittrex!!!
When public pool up it will be better to mine so wait and mine instead of buy. Everyone will have chance to mine not just big farm. Its already public, just msg me which miners you need and i'll send them to you What do you mean which miners? And I would be careful. Pools running SPR have the ability to steal your coins! huh ? How should I steal the coins ? And why ? The pool is free, the miners are "standard-miners" like ccminer/sgminer and you can always watch your stats in the miner and at the pool i.e. found blocks etc. so there is very low danger of "pools stealing coins" .. lol You can get hit by a car by walking over the street, you know ? Nice try, but SPR is designed to allow anyone in the pool to steal coins. You would have a better chance of running across a busy 10 lane highway, than mining in a pool. Its all about crypto, you know ? EDIT: And if the value of SPR would be higher, someone would invest much more energy in this to make it even MORE secure... Its currently just too cheap to invest a lot of (man)power in it Does that easy way stand up to the challenge of releasing the full source code for the modified miners? |
|
|
|
I can`t understand, Nvidia GPU miner working with compute_30 at this moment or no? I compile it with compute_30, miner start and mine, show me 900kh speed, but i can`t find blocks. Overall i have 7500Kh/s mining in 1 wallet.
You have to have patience when solo mining... Instead of getting constant shares all the time you will now be getting blocks several times a day. From my experience, at this difficulty and your 7500Kh/s hash rate, you should have gotten around 3 blocks in the last 12 hours if you are set up correctly with the stock Spreadcoin miner... But be aware, it isn't consistent like clockwork, I have gone 7 hours without seeing a single block only to have 5 of them pop up in the next 2 hours... It's all about long term average. Hope that helps! I know for solo mining need lucky, not only hashrate )) but i mining 27 hour with 7500kh/s and got nothing. My videocard on kepler kernel and support only compute_30. Maybe 3 months later someone addon support for Compute 3.0 ? Compute 3.0 support was released later the same day as the original. |
|
|
|
Guys need help on one of my rigs after few minutes after start minerapp appear this screen https://i.imgur.com/0rIGSuz.png?1 and go on and on like this any ideea how to fix this or why appear? Thx in advance this means you found a block. Congratulations. Final Hash: 00000000000000000000000000 Are you sure? Sorry, i got it wrong. That was a "booo", not a " yay"... Damn, this does not look good at all... Some other things that give away the fact shit ain't going too well:  I'm guessing some memory allocations are failing (and the miner dev is lazy and isn't doing any checking if they succeed or not) causing all the kernel launches just fail and return instantly. No way a 750 Ti is doing 530 MH/s Try running with a lower value for the -x parameter. The higher the -x the more GPU memory is used. |
|
|
|
Hmm, strange ... I have 2 rigs with 970s - one with 6 cards and one with 5 cards. They both seem to find block on a regular bases without any rejected issues. Driver is 344.75
I also had 344.75 and was getting pretty much 100% crap. Upgraded to 347.25 and running with -x 13:  Not exactly great but seems a bit better. Trying to get hold of CUDA 7.0 to try it out, might be a while. Also made the found block notification a lot less noisy in the latest release, that huge dump was intended for debugging and I just didn't realize it was getting printed even when not running with -D. |
|
|
|
On a related note, I am I bit concerned about the miner on non-750Ti cards. I'm getting pretty much zero rejects and exactly as many blocks as you could expect against the current network hash rate on my 750 rig, but a fair amount of rejects (but not 100%) on the 970. Can't see any particular reason why the same code would work on 750 and not on 970 though. It is a mystery. Just seems bit odd that near all the rejects I get are on the 970. Could be coincidence but I can't help but wonder... [2015-01-23 01:11:53] accepted: 1/1 (100.00%), 10038 khash/s (yay!!!)
[2015-01-23 04:56:03] accepted: 2/2 (100.00%), 10036 khash/s (yay!!!)
[2015-01-23 16:48:20] accepted: 3/3 (100.00%), 10040 khash/s (yay!!!)
[2015-01-24 07:28:52] accepted: 4/4 (100.00%), 10039 khash/s (yay!!!)
[2015-01-24 07:53:30] accepted: 5/5 (100.00%), 10034 khash/s (yay!!!)
[2015-01-24 09:22:16] accepted: 6/6 (100.00%), 10034 khash/s (yay!!!)
[2015-01-25 05:06:02] accepted: 7/7 (100.00%), 10035 khash/s (yay!!!)
[2015-01-25 16:22:12] accepted: 8/8 (100.00%), 10047 khash/s (yay!!!)
[2015-01-25 21:06:44] accepted: 9/9 (100.00%), 10027 khash/s (yay!!!)
[2015-01-26 04:59:57] accepted: 10/10 (100.00%), 10034 khash/s (yay!!!)
[2015-01-26 13:35:12] accepted: 11/11 (100.00%), 10038 khash/s (yay!!!)
I don't believe I had any rejects on your original spreadminer on my 970s. Seemed to work with the same consistency as 750s for me, unless this is newer code you're talking about. Talking about the original, yep. Oh well, maybe my 970 is just jinxed  register pressure can do that at some extend. I had a similar problem with a previous version of keccak and compute 5.2 where none of the hash were getting validated due to some bad allocation (The content of the register wasn't what it was supposed to be... and the problem wasn't showing at compile time...) Well, I went ahead and added CPU verification into the original spreadminer. Running in benchmark mode quickly shows if things are working or not. And the verdict for my 970 is that it doesn't work. Windows binary is still in build and will be added later, fuck compiling shavite for four different targets. The weird part is that people, including me, have been successfully running it on 970s and now suddenly it's all "no, fuck you dad." Maybe some driver upgrade messed something up..? Hnnngh, do I really need to register as a super official extremely important CUDA developer to see if compiling with CUDA 7.0 would make any difference... Edit: Win32 binary up at https://github.com/tsiv/spreadminer/releases/tag/v0.1r3 and source at https://github.com/tsiv/spreadminer as always |
|
|
|
On a related note, I am I bit concerned about the miner on non-750Ti cards. I'm getting pretty much zero rejects and exactly as many blocks as you could expect against the current network hash rate on my 750 rig, but a fair amount of rejects (but not 100%) on the 970. Can't see any particular reason why the same code would work on 750 and not on 970 though. It is a mystery. Just seems bit odd that near all the rejects I get are on the 970. Could be coincidence but I can't help but wonder... [2015-01-23 01:11:53] accepted: 1/1 (100.00%), 10038 khash/s (yay!!!)
[2015-01-23 04:56:03] accepted: 2/2 (100.00%), 10036 khash/s (yay!!!)
[2015-01-23 16:48:20] accepted: 3/3 (100.00%), 10040 khash/s (yay!!!)
[2015-01-24 07:28:52] accepted: 4/4 (100.00%), 10039 khash/s (yay!!!)
[2015-01-24 07:53:30] accepted: 5/5 (100.00%), 10034 khash/s (yay!!!)
[2015-01-24 09:22:16] accepted: 6/6 (100.00%), 10034 khash/s (yay!!!)
[2015-01-25 05:06:02] accepted: 7/7 (100.00%), 10035 khash/s (yay!!!)
[2015-01-25 16:22:12] accepted: 8/8 (100.00%), 10047 khash/s (yay!!!)
[2015-01-25 21:06:44] accepted: 9/9 (100.00%), 10027 khash/s (yay!!!)
[2015-01-26 04:59:57] accepted: 10/10 (100.00%), 10034 khash/s (yay!!!)
[2015-01-26 13:35:12] accepted: 11/11 (100.00%), 10038 khash/s (yay!!!)
I don't believe I had any rejects on your original spreadminer on my 970s. Seemed to work with the same consistency as 750s for me, unless this is newer code you're talking about. Talking about the original, yep. Oh well, maybe my 970 is just jinxed |
|
|
|
Bad news I was too careless and lost all my mined spreadcoins. I contacted several data recovery companies and most probably it will be impossible to recover my wallet. Without these spreadcoins I will have no incentive to futher develop and support SpreadCoin. Sorry for wasting your time with this cryptocurrency I think I found a way to recover my spreadcoins but you may not like it.
As I lost my wallet.dat I don't know exactly what blocks I mined and exactly how many coins I had.
I can approximately determine block before which my lost coins are situated. Everyone who have mined coins before this block will send them to him/herself (this can be made automatic). This will mean that this coins are not mine. Then, using some hack and releasing a new client I can send myself amount of the rest coins (or maybe less, say 80%).
This rasises two concerns:
1. What if someone will forgot to send coins to him/herself? These coins will still be spendable so he/she will not lost them. This raises the second concern:
2. What if I am a scammer and want just to double my coins, keeping old ones and getting new ones? The only way to prevent this that I see is to limit the percentage of presumably lost coins that can be spend but this is not trivial.
What do you think about such a plan? Is it acceptable in you opinion?
P.S. This way there is no need for anyone to donate coins to me.
And you guys fell for this ?!  No we didn't, that's exactly why it was not done. The donation proposal was mine, and this was a response to it. Please do not "cherry pick" posts from the forum in order to prove a point that no one cares about. Just to remind you, if he had said: "I have instamined too few coins, and want more to keep developing the coin because i am a greedy bbastard", we would have donated in the same way, because we wanted to reward him for developing the coin. You don't seem to get that. The community of early adopters WANTED to give him a reward for having created the coin, and we did so. So please, your point was made, you don't trust Mr. Spread, and that's fine. You don't like this coin and that's fine too. We got it. If you have NEW concerns, please post them, but stop repeating yourself. I'm not dismissing you as a troll because about one in ten out of your posts brings real concerns and constructive criticisms, but those are the ones where you actually write what you think, not the ones where you place lots of quotes, and Complex question fallacies full of passive aggressiveness. So if you keep posting the good ones, the real criticism without malice or implied accusations, you are really welcome as a member of this community. But please, it's getting tiresome to keep separating the wheat from the chaff and if you keep acting that way you'll fatally be ignored in the end. That's a horrible signal-to-noise ratio. Hit my "ignore the troll" threshold a long time ago. |
|
|
|
I'm confused. You said you found a bug in the hash? Or are you considering the lack of verification to be a bug? I left it out kinda intentionally since submitting "bad" solutions doesn't really hurt and I just didn't bother with the CPU verification. But yea it would be nice and very helpful in debugging. Running in benchmark mode with a low target would be a good tool for checking if the GPU hashing works or not, instead of having to wait until you actually solve a block.
It is a bug in my version. I have replaced some of the kernals in the miner to give a small boost. When changing kernals, things can go wrong, and it would be helpful to have the cpu to doublecheck the result. Aah, got it. Thought you found something wrong in the original. |
|
|
|
On a related note, I am I bit concerned about the miner on non-750Ti cards. I'm getting pretty much zero rejects and exactly as many blocks as you could expect against the current network hash rate on my 750 rig, but a fair amount of rejects (but not 100%) on the 970. Can't see any particular reason why the same code would work on 750 and not on 970 though. It is a mystery. Just seems bit odd that near all the rejects I get are on the 970. Could be coincidence but I can't help but wonder... [2015-01-23 01:11:53] accepted: 1/1 (100.00%), 10038 khash/s (yay!!!)
[2015-01-23 04:56:03] accepted: 2/2 (100.00%), 10036 khash/s (yay!!!)
[2015-01-23 16:48:20] accepted: 3/3 (100.00%), 10040 khash/s (yay!!!)
[2015-01-24 07:28:52] accepted: 4/4 (100.00%), 10039 khash/s (yay!!!)
[2015-01-24 07:53:30] accepted: 5/5 (100.00%), 10034 khash/s (yay!!!)
[2015-01-24 09:22:16] accepted: 6/6 (100.00%), 10034 khash/s (yay!!!)
[2015-01-25 05:06:02] accepted: 7/7 (100.00%), 10035 khash/s (yay!!!)
[2015-01-25 16:22:12] accepted: 8/8 (100.00%), 10047 khash/s (yay!!!)
[2015-01-25 21:06:44] accepted: 9/9 (100.00%), 10027 khash/s (yay!!!)
[2015-01-26 04:59:57] accepted: 10/10 (100.00%), 10034 khash/s (yay!!!)
[2015-01-26 13:35:12] accepted: 11/11 (100.00%), 10038 khash/s (yay!!!)
|
|
|
|
I will merge the original c code into the spreadcoin fork. the gpu finds a solution, it will be verified by the cpu. The current build have no verification done by the cpu.
I'm confused. You said you found a bug in the hash? Or are you considering the lack of verification to be a bug? I left it out kinda intentionally since submitting "bad" solutions doesn't really hurt and I just didn't bother with the CPU verification. But yea it would be nice and very helpful in debugging. Running in benchmark mode with a low target would be a good tool for checking if the GPU hashing works or not, instead of having to wait until you actually solve a block. |
|
|
|
I have found a bug in the hash. The problem is that tsivs code is missing verfication by the cpu before sending the results. Build 2 comming soon
Care to elaborate on the bug part? Might see if I CBA to fix it in the official release. tsiv: I started to merge your spread code in ccminer, but without testnet or a pool, its hard to finalize it... I added the cpu part https://github.com/tpruvot/ccminer/tree/spreadx11i will rebase it on my final 1.5.2 That CPU code seems to be just the X11 part of the hash though, completely ignoring the miner signature and whole block hash? And yea, I know exactly how annoying it is to test when your only method of verification is actually solving a block. I ended up hard coding it to work on a static block of input data that I knew the correct hash for until I got the damn thing working Well, more or less working apparently. |
|
|
|
Something I noticed about the throughput values and it kinda makes sense too: Multiples of SMM count seem to work best for the -x parameter. 5 for 750 Ti, 13 for 970, 16 for 980. Only have 750s and a 970 to test with but 20 or 15 for 750 Ti and 13 or 26 for 970 seem to work well.
Isn't that usually the case? Makes sense to me, just never really crossed my mind before. Still most if not every bit of ccminer code seems to just use a more or less arbitrary numbers for throughput. Probably wouldn't be a bad idea to always base it on SMM count one way or another. |
|
|
|
|
