|
Since you asked... When you don't have a GPU that mines and you don't have an FPGA and you need to work on code (as some of us do on our laptops) it's kinda hard without anything at all that hashes. It doesn't matter if it doesn't perform well in that instance.
|
|
|
|
No, as the maintenance burden isn't worth it.
And I want to do nothing to encourage botnet operators. In fact I want CPU mining on cgminer to be slow so that it is not the prime binary choice to include with trojans. |
|
|
|
|
Well I'm outta here again, time to take a break from these forums for my sanity till something hardware happens and/or the trolling stops..
|
|
|
|
|
How lucky am I? Is this an easter present from our friendly local christian to come trolling my thread again? It seems the forum mods are even on your side and refuse to accept your posts as trolls, nice to see lack of impartiality there. Let's see how long this post lasts.
|
|
|
|
CGMiner has nanosleep and sleep declared, which fucks the build for x86_64-w64-mingw32. Also, pthreads are not listed in the dependencies, and there is no option in configure to specify the prefix for pthreads.
We don't support building for w64 since it serves no useful advantage over 32 bit windows builds. Iin fact ming w64 is an unstable development branch and 64 bit builds use more ram and are less reliable. |
|
|
|
Thanks for that. It brings up two immediate questions though; I've just spent an hour scrolling through ckolivas' posts to try to figure them out but no luck so far... 1. Does he have the same MSI card I do? 2. He calls the driver "11.12" and then says he uses the amd-driver-installer-8.921-x86.x86_64.run "hotfix" with it. -So where is the "11.12"driver, and do I need to install that first, then the hotfix after? Thanks again! He gave you direct download links to them in his post...  |
|
|
|
Noticed that just about everyone on this thread is using Windows, except for Grover who had a few Linux questions. As someone thinking of building a LTC rig, why is everyone using Windows instead of something like BAMT, Linuxcoin, or Debian?
I primarily develop cgminer on linux so it definitely works fine there. I make it work on windows as well since so many people use windows. The fact is it works just as well on windows, and most users already are running windows, so that's how they get started, and they never even bother considering linux. Add to that extra overclocking and voltage control applications in windows that linux doesn't have, making it hard for them to care for the stability, security and other features that make linux suitable for dedicated mining rigs. However, linux users tend to read documentation and experiment for themselves till it's all working fine. |
|
|
|
|
litecoind is stuck in a timewarp where people are apparently developing on it, but in actual fact the code has not changed for a very long time with no real sign of progress. As I've said in the alt currency forum threads, I see no real sign of development or even trying to stay in sync with the bitcoind code base.
|
|
|
|
The supercomputer in our campus only allows 2048 cores for 24hrs max.
Considering a 7970 GPU contains 2048 shaders which are as good as cores... |
|
|
|
when mining on 4 gpu rig, on difficulty 1 , im geting such crash on internet reconnect : APPCRASH cgminer.exe ver 0.0.0.0 time 514557a8 module libusb-1.0.dll ver 1.0.9.0 time 51132051 code c0000005 exept. 00001e07 os 6.1.7600.2.0.0.256.1 1: 0a9e 2: 0a9e372d3b4ad19135b953a78882e789 3: 0a9e 4: 0a9e372d3b4ad19135b953a78882e789 windows 7 64; drv 13.1; sdk 2.7; cgminer 2.11.3; --scrypt, 2x 5970, getwork + LP, with failover set on stratum when on other pools, that have higher diff, rig is stable.  It looks like you are submitting lots of shares, your miner has disconnected 47 times due to an unstable pool/connection, cgminer has cached shares in the hope of resubmitting them when it reconnects with stratum, and then crashed due to running out of resources to spawn another thread trying to submit more shares. The amount of shares at diff1 on scrypt is obscene, choose a sensible pool. |
|
|
|
|
Update your SDK to 2.6 or 2.7 and delete any .bin files.
|
|
|
|
Well someone's gotta do it. Ill see what I can do. I can code and tinker. I just don't like to much. I'm gonna be gone a fair bit of April. So if you want to screw with my units you can but you may have to call one of my techs to hard reset them if you bork one and can't reset it remotely. It's an offer if you are interested in doing it right  Ps I've probably given you 50 coins by now, over the past couple years. Keep up the good work. Thanks. With xiangfu currently working on bringing the code into line with mainline cgminer, it would be helpful for me to test on an actual unit, and I have some time next week. However I would not be touching the p2pool software code at all since it is in python and a complete mystery to me. |
|
|
|
|
Usual instructions for when people DONT read the readme.
Reconfigure xorg for all devices, start x and export the DISPLAY variable before starting cgminer.
|
|
|
|
Sounds like the problem is all in the p2pool end anyway? Can you tell if it's actually successfully connecting directly stratum because that would be essential to avoid p2pool sending a lot and higher diffs would be essential to avoid p2pool receiving a lot.
Avalon Cgminer without fix protocol connects on stratum but resends all work over and over. There's something wrong with the way it reads the stratum response. Someone, Jeff I think, said it has a problem with double byte responses that p2pool makes. On getwork, it just hammers the server and the DOA rate is >25%. Using a very high diff 3000-4000 helps a tiny bit. The highest p2pool would let me go is 6535. Any higher number just comes back as 6535. Even soloing to a bitcoind alone will crash. It's too much. Hence the need to run a buffer like eloipool between it. https://github.com/forrestv/p2pool/commit/5f061e6c6753adf93acf04b8463badef88c4106eWell cgminer has changed a lot since the version included with Avalon with lots of bugfixes and improvements, and I can't attest to any code added to the Avalon release so... usual disclaimers apply. On the upside, Xiangfu has said to me on IRC that he will be updating the code to bring it in line with mainline cgminer. But then I'm still out of the loop and only obliged to audit his code if he wants to push it upstream to me. |
|
|
|
|
The slogan should be changed to "Litecoin: For butthurt GPU miners."
Disclaimer: I wrote cgminer.
|
|
|
|
|
There is no such thing as accepting shares from solo mining, only accepting blocks. cgminer will attempt to send any >64k shares with ltc mining, but they'll be rejected when solo mining since diff is now 5M as you can see in your snapshot. I see nothing wrong here.
|
|
|
|
|
You said you're mining solo? You'll only get accepted if you solve a block. Rough guess at your hashrate, that will be once every 5 days on average at the current difficulty. Try on a pool first to make sure you're really working properly
|
|
|
|
|
Sounds like the problem is all in the p2pool end anyway? Can you tell if it's actually successfully connecting directly stratum because that would be essential to avoid p2pool sending a lot and higher diffs would be essential to avoid p2pool receiving a lot.
|
|
|
|
Anyone resolve this ancient problem? One of my cards disappears from OpenCL when Xinerama is activated.
AMD OpenCL stupidly sees each "screen" as a device. That means that if you have 2 monitors connected to one GPU, you get two opencl devices. Presumably the converse is also true, seeing one device with 2 GPUs making one virtual "screen" with xinerama. I'm guessing if you force an extra output on the 2nd card, either by config or by adding a monitor/dummy plug to another output on it, you'll get two opencl "devices". Don't ask me who the moron in AMD was that thought opencl compute devices should be associated with screens and not physical devices.  I'm not using dummy plugs, but opencl still recognizes 2 devices. But are you using 2 GPUs on xinerama with one virtual screen only? Nope, its not the screens, they're recognised fine. It's something to do with xinerama. With xinerama "off" in the xorg.conf then clinfo reports all devices. If xinerama is on then only one device is registered. aticonfig --lsa shows all devices under all conditions. I'm begining to suspect its a driver problem?? Did you read my advice? Ignore the poster in between us. |
|
|
|
|
Show Posts
