Yeah I even tried explaining but I didn't spell it out, so even if I put it into the readme, it would have been "too hard dunno wtf you're  talking about" or wouldn't have been read.

Try hand editing the conf file. Apparently there is sometimes a problem with the "vddc" entries. I don't know why.

You don't copy dlls, you copy any .bin files

HW is hardware errors. Your card is producing nothing but garbage and not a single share so you're pushing them too hard.

The axe murderer comment was not coincidence, given the history of Hans and linux

In fact his code never got incorporated because it had too many problems. It had nothing to do with him being a murderer. Once he was convicted, though, all the people working on his project slowly all walked away one by one, thus leaving the code to rot.

I judge all code by the code's merit. If it's GPL compliant and good code, then even if it's from an axe murderer, I'll take it. I have thought about this long and hard in the past. Read Rusty's take on it:

http://rusty.ozlabs.org/?p=196

Thanks very much for taking the time to explain. I misunderstood completely where the capacitor was. Sent you a little something for your troubles and work on developing this pay scheme.

It does indeed sound like your network is simply overloaded. cgminer hits the network very hard, and with that many GPUs, especially after a longpoll, they'll all be looking for work at the same time. If it happens at twice as many GPUs when you decrease threads to 1, then that will be diagnostic.

You can halve the number of connections potentially by decreasing threads per GPU from 2 to 1

--gpu-threads|-g <arg> Number of threads per GPU (1 - 10) (default: 2)

Try setting it to 1. I know some miners have a little pause between connections to cope (like diablominer) whereas cgminer is absurdly aggressive with trying to keep the GPU busy - this is also why it's more suitable for mining with p2pool. Perhaps yet another option is required...

You are allowed to change your vote too

The binary kernel that is generated occurs only ONCE when you first run cgminer. That means that if you run cgminer with sdk 2.5 and then install sdk 2.6, it won't make any difference. However if you install sdk 2.6 first and then run cgminer for the first time, you'll get a binary kernel from the 2.6 sdk (i.e. the slower one). Since none of that code was changed in cgminer between those versions, I suspect that's what you're seeing. The newer *driver* may be faster, but the newer *sdk* is what causes the problem. Try deleting the *.bin files and start cgminer again and you'll see.

Thanks. I thought the code looked very quirky and operating system dependant anyway (which others had already noted) so I wasn't planning on it.

Thanks for your support of cgminer To be perfectly honest, I wish that CPU mining was the end of the discussion and that  GPUs weren't better at mining bitcoin specifically. However, that is NOT the case, and I believe in bitcoin more. I have no love whatsoever for alternative currencies and even if someone offered to keep CPU mining code maintained for the sake of alternative currencies, I would not accept their input, sorry.

By the way, I'm not saying this disadvantages the long term miners in any way...

http://ozco.in/content/share-payout-comparison-bitcoin

It seems to me if a pool has a long enough run of luck, you join in and benefit while the value slowly works its way back down as the luck turns.

POLL regarding cgminer: CGMINER - Remove CPU mining?

https://bitcointalk.org/index.php?topic=58222.0

Increasingly, CPU mining for bitcoins is becoming irrelevant. The only people who still are CPU mining either have access to free electricity by pilfering it off someone else or have some very rare set up involving solar power or something else. Worse yet, it is the number one target for trojans creating illegal botnets or using power on work computers in an unauthorised fashion. The only use I still have for CPU mining is as a test that cgminer works on machines that have no GPUs that can mine.

As maintainer of cgminer, while the CPU mining code is what cgminer started out as, I find it an annoyance to maintain, with random bug reports about difficulty building it, performance being not as good as the best CPU mining algorithms, 64 bit versions not being available for windows, older assemblers failing to compile it, requests for more sse* support, patch submissions to improve CPU mining by .1 MH/s and so on. The fact is it's not much more than annoyance to me and any time I spend working on the CPU mining code is time I could have spent usefully on the GPU mining code. Also, as CPU miners earn almost nothing by mining, their contribution to my BTC balance is never going to be some kind of incentive for me to work on it. The only ones earning a lot from it (the illegal botnets) are most definitely not donating.

Furthermore, FPGA mining code is coming to cgminer, and adds yet another type of device that cgminer will support, but a useful one. At this time, the code has been abstracted out to work with any additional devices in the future, but it also makes it an ideal time to remove the CPU mining code, which is in my eyes, irrelevant.

I would like to remove it entirely, but it wouldn't be difficult to keep the existing code there and make it not compile unless consciously configured at build time. I fear that this will end up being even more work than just leaving it as is, since the same number of people will be wanting CPU support.

Clearly my preference is to remove it. Comments would be appreciated too. Saying "it's good to keep" without explaining why I should have to maintain it will not be a convincing argument. Oh and I'd be happy for someone to step up and maintain it and I would pull their changes into the master git tree unless their code proved unsatisfactory.

Thanks.

Don't forget to poll every DGM pool to find which is currently paying the most per share and hop to that site till the value drops on the next block they find...

Edit: If it wasn't obvious, this was me explaining how DGM is hoppable.

Great, I look forward to a new kernel for cgminer... though I expect I'll end up doing that myself based on your work 

Verbose mode required to see it. It means that if you were on a pool you would have been counted as submitting a share, whereas solo mining it means you found something that looked good, but when tested wasn't good enough to be a real block, so worth nothing.

I'm not actually sure what it is you want... you have a script already and by default cgminer tries to restart dead GPUs already.