not using a bat, and running straight from the command line, what's the command to enable only a single GPU?
-d 0, it's in the help.
|
|
|
does anyone else have problems in a multi-gpu rig with gpu 0 consistently crashing when mining neoscrypt algo? it's only gpu 0, the rest are fine and hash away reliably.
I don't think I've seen a single GPU crash, usually it's the driver or the miner. Try swapping GPU0 with another to see if the same card crashes in it's new slot. Also see if the card will mine at a lower intensity.
|
|
|
I get 16.2 MHASH@quark with compute 5.2 build for x86 in the opensource version. (gigabyte windforce 970)
Compute 5.2 has bether launchconfigurations.
OMG I installed cuda 6.5 with support for compute 5.2, using the run files, what a pain! but now lyra works and I get about 700 Kh/s more on a single 970 :-) awesome ... where do you get the 5.2 patch for cuda 6.5? ... i still have to manually edit the Makefile.am to stop it trying to compile compute 5.2 ... great work though ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ... #crysx pallas: I prefer using the run file because it gives the option not to install the drivers. With the dist package you get the included drivers whether you want them or not, and the're usually old. crysx: The 5.2 version of cuda is a full package, not a patch, that adds support for compute 5.2. Whether you choose to use 5.2 it is still determined by Makefile.am. There's no harm in compiling for 5.2 when you don't need it as long as you also include the compute versions you do need. It just takes longer to compile and the executable is larger.
|
|
|
Thanks! It is indeed faster on 970, but lyra doesn't work, it doesn't validate on CPU. It also segfaults at times when exiting. Both problems where present on the previous version as well. Need some debug info?
Set -i 17.5
Thanks but same validation error. Besides, the segfault is on all algos.
Ubuntu 15.04 with distribution cuda toolkit (6.5 and compute 5.0)
Lyra2 works on a 970 for me (compiled for 5.2). Segfaults on ^C still occur but don't appear to have any residual effect. I've noticed the default intensity is too high for some cards/algos. Ive also noticed some odd behaviour with intensity. Quark would initially run with -i 23.5. The next time i started it it failed at -i 23.5 but ran at 23. Then 23 failed and I lowered it to 22.5. 970 + 780ti.
|
|
|
Look's like neoscrypt is broken in release 54. I suspect there are some errors in the vector implementation done in the lyra2re rewrite since they share some code.
Neoscrypt works well for me in release 54.
|
|
|
If you have flooded the pool with rejected shares the pool might ban your ip adress. Change the ip
It may be the reason. I forgot about that. I can't do it right now but I will report you if it was or not soon as I check it. Thank you. Two heads are often smarter than one ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) EDIT: But I also tried to mine on Suprnova (for the first time with neoscrypt) and had same result. I doubt it banned my ip ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) You haven't mentioned what versions you are using but I suggest you stick with the one that used to work and troubleshoot from there. Make sure you are in fact using the intended version. If it used to work but now doesn't the problem is not with the miner. More detail about the failure would also be useful. I have a Windows machine that I need to reboot once in a while because it fails to connect to westhash quark (retry loop). That's the only affected pool/algo. After the reboot everything is ok again. Updating drivers hasn't solved it. There is something peculiar about Nice/Westhash as it always fails to connect on the first attempt. ffpool doesn't have this problem and neither did yaamp. I'm using 1.5.52. I need to come up with a new compile strategy because VS Community (the free one, not the trial) refuses to start after 30 days. Then I can instrument ccminer to focus in on the connection failure.
|
|
|
So far the pool is running very good, we are in need of more hashing power to other algos than quark. If someone has an request for coin, just message me, I'll be happy to add it !
The flippant answer is whatever is paying most. The problem is it could change from one day to the next You already have the most interesting coin at the moment so it should be no surprise the hash is concentrated on quark. What's your plan? You already mentioned you are an auto-exchange profit switch multipool. Within that is there a specific niche you want to target, like new coins, established coins, obscure algos, etc? Do you want a lean operation or do you want anything and everything that's mineable & exchangeable? I'm pretty satisfied with your current selection of coins but here are a couple of suggested additions: HTML5/X15 has been paying well for a while. There are a couple of Neoscrypt coins that have their moments. A couple of weeks ago vertcoin/lyra2 had a nice pop. Edit: Nevermind, I see you just added it. Dime/Quark was interesting on the old yaamp pool. I previously mentioned Cryptonight as I have not found any other auto exchange pools that mine that algo. Keep up the good work.
|
|
|
You're adding apples and oranges.
|
|
|
7x970 - Lyra2 won't start (out of memory) 4GB system memory
7x 970 ?! ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) mobo are so expensive... you need at least as much ram than vram here something like 28Gb to run that kind of system Surely there has to be a workaround. I mean the memory/swap doesn't even seem to be allocated let alone used, not even for a second. Something like initializing the cards one after the other instead of all at the same time or something? Or giving the cards different jobs instead of working together on one big job? I have no idea but I'm sure there's a way. How many cards can you run? It's cheaper to add more RAM than splitting the cards into multiple rigs.
|
|
|
Pool is running really nice, steady rise in Hashrate.
Which additional coins would you like to see ? We can also implement new algos if asked for.
Agreed. Nice to see your fees lower than your ancestor. Someone on the old yaamp thread requested cryptonight. I second the request. One feature that I found yaamp was missing was the ability to mine single coins. I don't know how difficult it would be to implement but the ability to profit switch among individual coins would seem a useful and unique feature.
|
|
|
Any chance cryptonight could get into this multiago pool? I think tsivs ccminer code would need to be plopped into the regular ccminer code (he eventually stripped all algos except cryptonight from his fork.
ffpool and hashpower each have their own thread now so you might be better off posting your request there. yiimp is a test pool so probably isn't suitable. The biggest ccminer forks are produced by Epsylon3 and SP_. They also each have their own thread tracking their development. I think it's a great idea to get cryptonight in a yaamp clone. I'm not aware of any existing cryptonight pools that auto exchange.
|
|
|
I haven't tried hashpower yet, that's another thread
Umm, I think you might be on the wrong thread, as this one is Hashpower's... Ooops.
|
|
|
My payouts from ffpool have been confirming quickly. I would not be in favour of higher fees for faster confirmations in any case.
Yes, ffpool sends with higher tx fees and their payments have been going out fine. Hashpower, on the other hand, has far lower tx fees, to the point where they're being treated like 0 fee transactions and have gotten buried in the backlog. If they get dropped from miners' mempools, I dunno how the issue will be resolved, but it seems a bit extreme that it's even a possibility. I'm not particularly worried about payments taking a few hours to confirm, but when they're taking so long that they're potentially in danger of being dropped from miners' mempools and/or never confirming, that seems like a problem. [/quote] I haven't tried hashpower yet, that's another thread, but I have noticed delays with some other pools. But when you consider it takes most coins 5 hours to mature another few hours isn't a big deal. I'm pleased with ffpool's fees (lower than yaamp's) and payouts so far. If fees could be lowered by reducing the payout interval, even better. Every 3 hours is a bit much when only raking in a couple of mBTC. How about .001 BTC minimum daily and .005 intraday?
|
|
|
Mining seems to be working well so far, and the pool's coin selection is at least good enough that my miners are spending time on it on-and-off, so that's a plus. Payouts have been regular, but with a slight problem... It's not entirely the pool's fault, but it seems that payouts are being made with extremely low transaction fees, which due to the strange spamming of the blockchain that's going on right now, has resulted in payments that haven't confirmed in over 15 hours as of writing this. Obviously lower tx fees are good for profitability of the pool/its miners, but when it's at the point that transactions simply aren't confirming at all, perhaps some adjustment is due ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) . Just for comparison's sake, another YAAMP clone my miners have been frequenting is spending more on tx fees (though it has higher pool fees in general) and its payments have been going through fine all day. My payouts from ffpool have been confirming quickly. I would not be in favour of higher fees for faster confirmations in any case.
|
|
|
what are you guys getting on X11 with the EVGA Superclocked 750ti ?
I get about 3070 KH/s.
|
|
|
Profit estimates on yiimp seem off. For example zr5 in the pool status shows an estimate of .0001 for the current & 24 hr estimate but .7772 for the 24 hr actual and in the pool details it shows ziftr paying .0014. Also the block reward in the pool details is different from the block list. The other clones seem to have got it right.
I also noticed that yiimp mines two algos not supported in Epsylon3's fork of ccminer. I presume they will be added shortly as there appear to be open source versions of ccminer for both floating around.
|
|
|
i've heard the hash per watt on a tesla card is dismal. they werent really made for mining, or the miners aren't coded to be efficient on tesla cards
Tesla is Kepler based but a Maxwell version would be interesting. I wonder how long Nvidia would let someone mine using their test drive... http://www.nvidia.com/object/gpu-test-drive.html
|
|
|
What a beast! With a beastly price. Half of that would be nice.
|
|
|
i mean yaamp's code, not site, just try and see for yourself, multialgo switching makes huge difference
i see what you mean ... on this fact alone - it does seem that way ... multialgo switching has abrupt changes to contend with and so suffer share rejects everytime the switch happens ... this is a loss of shares and productivity - even though they are small between switches ... we have seen this happen with our own miners / farm ... but that is with ANY multialgo multipool - not just yaamp.com ... look at epsylon3 .. he is one hell of a developer - and now running his own yaamp-coded pool with more algos added ... it sort of goes to show that if even a seasoned developer like him is willing to look at - setup - and improve the code - then the pool code is still on a reasonably good level ... nicehash has the same sort of issues ( though they dont mine coins - just divert hashrate ) with multialgo switching ... so much so - that they devote an entire section on the website to it ... single algo / single coin pools may be more 'efficient' ( for lack of a better word ) at mining - but we believe that the losses are so minimal thats its close to negligible ... #crysx I don't have a problem with rejects upon switching algos on any multipool. I don't use the pools' multialgo features, but I also incur the overhead of killing and restarting ccminer. I don't think there is a truly elegant way to switch algos. The pool signals by disconnecting so any unsubmitted shares are lost. Whether the miner reports that as a reject is irrelevant, it's lost work. To have a seamless algo switch requires a cooperative disconnect where the miner is allowed to complete the work in progress.
|
|
|
|