OP's numbers look plausible.
We established in other threads that current miners are unable to fully exploit the theoretical performance of the GTX 680, so the chip must not be running at "full load", hence the low 100W power consumption.
like its using 100% of 256 CUDA cores or something anything they could change in drivers or miners that could improve the mhash? Nope bitcoin mining needs good integer performance and that is something no nvidia device has. Drivers and software can't fix that. |
|
|
|
I have the same error  And I had to delete folder database to make the previous version work again. That may happen to you too, so do this in that case. Nothing has really changed from the previous release. You may want to build with IPV6 disabled. Please check the build readmes for how to do that. I tried the latest binaries and got the same error. I tried building without IPV6 and it STILL gave that other error. |
|
|
|
|
Your nvidia card will cost you more in electricity than it earns to mine.
Do not mine with a laptop, they are not designed to provide enough cooling to be running flat out for hours on end.
Your card only has 64 stream processors so the settings you are using will never work on it.
Get the latest binary.
Try just --shaders 64 and don't set thread concurrency or lookup gap.
LTC GPU mining is not remotely trivial to do at the moment, and it really is this hard for most people. They just battle on till they find what works.
|
|
|
|
I may code a python script sometime at the end of next week that calculates profitability with both litecoin and bitcoin and then hops between mining them based on that... is anyone interested in that?
Hopping between them would require a complete restart of cgminer at the moment. Also: http://allchains.info/calc.html |
|
|
|
Actually 40% you probably should add this also:
export GPU_USE_SYNC_OBJECTS=0
What does that command do exactly? I know that setting this variable to 1 solved the 100% CPU bug for some, but I've never found any explanation of it. pretty sure it locks the CPU usage to one core. 99% sure. That at least makes sense for "export GPU_USE_SYNC_OBJECTS=1". But what about "export GPU_USE_SYNC_OBJECTS=0"? It does not lock it to a cpu. It affects internal function of the amd driver, but what exactly, I don't know. As for "GPU_USE_SYNC_OBJECTS=0" that was actually a typo I meant to write 1! I doubt it does anything with scrypt mining. |
|
|
|
|
The latest git version will limit the size of the thread concurrency if you only git it --shaders alone, so it might be worth doing that and setting max allocation to 100%.
|
|
|
|
A fatal error occured. Litecoin can no longer continue safely and will quit.
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
litecoin in Runaway exception
Double plus ungood. Then I tried building it for myself: An error occured while setting up the RPC port 9332 for listening: open: Address family not supported by protocol
It seems any port I choose as a server for solo mining brings up that error. |
|
|
|
A fatal error occured. Litecoin can no longer continue safely and will quit.
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
litecoin in Runaway exception
Double plus ungood. |
|
|
|
export GPU_USE_SYNC_OBJECTS=0
What does that command do exactly? I know that setting this variable to 1 solved the 100% CPU bug for some, but I've never found any explanation of it. Beats me  |
|
|
|
Don't forget people do:
export GPU_MAX_ALLOC_PERCENT=100
before starting in any linux guide.
Okay! Thanks! Actually you probably should add this also: export GPU_USE_SYNC_OBJECTS=0EDIT: export GPU_USE_SYNC_OBJECTS=1I might add that the first percentage is not set in stone yet, perhaps something like 40% would actually be better... we're still working out the witchcraft brew. |
|
|
|
|
Don't forget people do:
export GPU_MAX_ALLOC_PERCENT=100
before starting in any linux guide.
|
|
|
|
Making some headway. Deleted the Nvidia OpenCL files and now I'm getting a "scrypt120724Juniperglg2tc8000w256l4.bin" being created in the cgminer folder. However still the same errors and hash rate.
Now time to fiddle with the thread concurrency manually. Suggest 3200 or other multiples of 800. |
|
|
|
I don't want to mine on the Nvidia adapter I want to mine on the ATI adapter. CGminer wants to mine on the Nvidia adapter. The platform switch doesn't seem to do anything.
That does not compute. It should... |
|
|
|
cgminer.exe -o http://litecoinpool.org:9332 -u username -p password --intensity 4 --scrypt --shaders 800 --gpu-platform 1 Same result as before. You will still need to read up about the gpu map. However you wont be able to mine on the AMD device and the NVIDIA device from the same cgminer instance regardless; you must choose one platform for each instance of cgminer. |
|
|
|
Use --gpu-platform 1 for your AMD device. |
|
|
|
Image:  only get ~20 kh/s cgminer --scrypt -I 16 --shaders 800
You'll have to fine tune it with thread concurrency, shaders alone still doesn't cut it. I haven't found the optimum autotune as of yet, and I'm not sure there will be one. |
|
|
|
Okay I've experimented some more and
export GPU_MAX_ALLOC_PERCENT=100
will obviously cause a problem, but it gives me massive scope for trying different tc, etc since I can theoretically allocate 3GB on a 7970. However the code would try to allocate the largest buffer by default which is not right with this value now, so I've committed a change (to git) that will find the nearest buffer size that is a power of 2 between the thread concurrency buffer requirement and the maximum allocable ram.
Playing some more with my 7970s I found the values it was already running were pretty close to optimal. The only thing I found useful with the increased ram available was that I am now able to increase threads a little more (5 instead of 4) which afforded another 5kh per device.
The good news is that this should be what the 5x/6x miners were looking for on linux. I suggest you download the latest changes from git and start experimenting with TCs that are a multiple of your shader count after setting the above variable to 100%.
Wow - I am leaving work and was planning to try the parameter at home - and now I see that you already did my homework :-) many thanks !!! To say the lack of progress on scrypt performance is bugging me would be an understatement in the extreme. Thank you for spotting this, but I fear even this is not the holy grail. Goddamn witchcraft.... |
|
|
|
|
Build away.
I don't have any other immediate change planned. I'm not sure this will ever be a simple start it and it will find optimum settings. Scrypt on GPU is half programming, half witchcraft.
|
|
|
|
|
Okay I've experimented some more and
export GPU_MAX_ALLOC_PERCENT=100
will obviously cause a problem, but it gives me massive scope for trying different tc, etc since I can theoretically allocate 3GB on a 7970. However the code would try to allocate the largest buffer by default which is not right with this value now, so I've committed a change (to git) that will find the nearest buffer size that is a power of 2 between the thread concurrency buffer requirement and the maximum allocable ram.
Playing some more with my 7970s I found the values it was already running were pretty close to optimal. The only thing I found useful with the increased ram available was that I am now able to increase threads a little more (5 instead of 4) which afforded another 5kh per device.
The good news is that this should be what the 5x/6x miners were looking for on linux. I suggest you download the latest changes from git and start experimenting with TCs that are a multiple of your shader count after setting the above variable to 100%.
|
|
|
|
AMD Buffer size problem (cause of my performance woes with 5850) I found an interesting thread on AMD Developer Central today: "Large buffers" http://devgurus.amd.com/message/1282913#1282913user drallan presents a workaround for the low maximum allocation: allocating several memory chunks and addressing everything as one block ... maybe the thread will go on and bring more ideas I am going to try setting "GPU_MAX_ALLOC_PERCENT" when I get at my machine after work Most interesting.... Woah it works!... for linux people, just start with export GPU_MAX_ALLOC_PERCENT=40 or other values and try again I was able to allocate whopping buffers on my 7970.... |
|
|
|
|
Show Posts
