Admitting the theft is at least a step forward to reversing it.
Even if it were only one miner being stolen from, that's enough reason for me to avoid Eligius until it comes clean.

There was an evidence denial posted recently, so, I'm reposting the evidence (see above) which was never refuted.
The poster didn't use basic discussion principles, so I can't really respond other than trying to steer him back to the factual evidence under discussion.
Here's the stats summary for the unpaid rewards on that typical miner loss I examined above:
http://eligius.st/~artefact2/us/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK
http://eligius.st/~artefact2/eu/1QEkXwhhHbaBCfmEHY7bh8QNPVkFtorQkK

No different than Pools being Bitcoin Forum->Bitcoin->Mining->Pools.
Just make Bitcoin Forum->Bitcoin->Mining->Pools->DeepBit!
There are so many parallel conversations going on that should really be separate threads just to keep them straight...

Not to mention remembering the last page I was at...

I get that when a pool starts you wouldn't create one right away as they might be some fly-by-night deepbit wanna-be.  But there is a critical mass at which its time to give them their own bucket.

Now that I'm out of newbie-hell on the forums I'd like to suggest that this now 160 page "forum" disguised as a single thread has now grown to the point (along with slush's thread) to a sub-forum of 'Pools"

http://forum.bitcoin.org/index.php?topic=17462.msg223800#msg223800

Thoughts?

I'd really like to be able to use a RSS reader focused on deepbit pool only.  Can't do that with a single thread...

I did, almost all the top miners did, as you'll see none of the current miners were active around June 14th when the shorting took place.
Using a different pool doesn't get my "borrowed without permission" BTC back from Eligius though.

Sorry for not quietly accepting the loss of BTC. . .
I'm the jackass for that.
The pool operator is totally in the right.
(that was sarcasm)

Regarding the maximumpps shorting system, it's totally different from "score based systems" - Here we had a pool operator reducing rewards for rounds less than 90 minutes and keeping the reduction to themselves (or loaning it to themselves if you want to give him the benefit of your optimism), there was a promise that rounds later that were longer would be repaid this loaned BTC, but this repayment was never implemented. there is a typical example of how it affected a user in my post above.
Of course optimism, hope, opinion, and LOTS of WAITING would be good in this case to reach the conclusion that nothing is fishy. Can the shorted miners use all those tools to accept current situation? yes, of course, they could also get a lobotomy and accept it.
Should miners quietly accept the fact that a pool took work under explicit promises, then failed to meet the conditions promised? Apparently you're saying I should. . .
Well, I did several days of waiting and hoping and being optimistic, and it didn't deliver the coins he owed me.

Temps on the cards are all around 70c.  Not sure how to check the VRMs, but the rig is a caseless rig with several large fans pointing at it.

I'll let it run for another day and see if it recurs.  Note, I switched to DiabloMiner yesterday because of the elegant simplicity of running a single miner that handled all the GPUs and because your miner handled network problems better.  That said, I had been running poclbm and phoenix for more than a month without any problems like this.  Hopefully it is rare.

To your last point, so it's reasonable to run two instances of DiabloMiner at the same time?  I am used to having to do that with phoenix and poclbm to work around their poor handling of network problems and slow-to-response getwork requests.  I suppose I could even setup some cron jobs to restart each instance periodically to make sure that if one of them gets in a bad state, it gets fixed hopefully before the second one gets in a bad state.

I suppose I could also try the newest AMD driver (I am still on 11.5).

Yes, I have this problem too. Maybe Tycho will clarify situation?

I had a problem overnight with DiabloMiner and I'm not sure if this is a known problem (couldn't find anything in a quick search).

I have two 5970s (four total GPU cores) and overnight, one of the cores went idle with DiabloMiner. I noticed long enough after it happened that any error messages were not in my scrollback buffer anymore, so I don't know what happened.

Is this a normal problem?  Restarting DiabloMiner fixed it, but I am worried that this wasn't a one time issue. 

I really hope to find a solution for this one because it is really slick to only have to run one instance of DiabloMiner vs multiple instances of phoenix/poclbm.

I just tried the newest build, and somehow the hardware errors are around 180 instead of 180000 and speeds are as good as the old version. Whatever you did worked, thanks.

I was using the -g option with various values but I find it increases rejects and for some reason -f1 decreases the speed even though its supposed to increase it for my system.

Are the grouped rejects related to a pool specific protocol like longpoll, is that what you meant?

I have more testing and pool hopping to do later, but for now I am happy with this miner again.

I got the bitcoin client working. It's at 48 connections and your miner is hashing. That's about all I know what to look for to be able to tell if it's working. The command I use to connect is diablominer-windows.exe -u XXXX -p XXXX -v 19 -w 192.

I have a monitor hooked up to the second card. As I said in the other thread, if I disconnect the crossfire cable I get bad core usage fluctuations according to msi afterburner. It's more stable with it connected. Crossfire is disabled in catalyst control center as well. All along I've had full load on both cards, other than fluctuations. Do I need a dummy plug? To my understanding a dummy plug is only used if you don't have a monitor hooked up. I can view the desktop on my 2nd monitor as well. Thanks again for all the help.

I've been battling with learning how this works for about 4 days now. I've managed to get diablominer to work for me using the api.bitcoin.cz pool. I'm not too sure on what I'm seeing at the bottom of the screen. I average around 400 mhash's, at least I think.

I'm assuming that mhash 401.1/402.8 means that 401.1 is realtime because it fluctuates and 402.8 stays the same meaning it's an average. At first I thought that those were the numbers both cards were pushing.

Anyway, I'm running 2 6850's. Crossfire is disabled. Catalyst 11.5b and sdk app 2.4. There are monitors hooked up to both cards. There's a crossfire cable in place. Both gpu's report full load according to msi afterburner. Diablominer reports that it's connected to both cores (barts 1 and 2). I start the program by going to the c drive and shift right clicking the diablominer folder to open a cmd with the path already specified. Then I type out the start command diablominer-windows.exe -u xxxxx -p xxxxx -o api.bitcoin.cz -r 8332 -v 19 -w 192.

All is well and good except for the fact that I read on here that people with single 5870's are pushing around the same hash rate as me.

I've also read on here that people are starting their miners in java directly, but, according to the original diablo3 post, I'm doing it the right way.

So, which way is the right way? Why are my 2 card's producing the same hash rate as a single card?

Another thing is that I've been 100% unsuccessful at solo mining. I have the bitcoin daemon. I start it with the -server command. It starts. I have the config created and it's right (i've tried about 4 different suggestions). When I start diablominer, it gets as far as connecting to the first gpu core and stops.

So, yeah, lol. I'm at a loss here. Any help would be greatly appreciated.

You need to run 4 different programs, as 6xxx are 2 gpu's (pretty sure), and you have 2 of them.

Thanks for the info man. I needed some closure lol. I think my main problem is the power supply in my computer under volting causing fluctuation performance (600w coolermaster). I'm going to try unplugging my 2 dvd burners and my second hdd to see what happens. So do you recommend reverting to an earlier revision of sdk?

I'm pushing ~450mh/s on 2 6850's oc'd to 875 on the cores. Does that sound right? Based on what I've read on this forum, people with single 5870's push the same thing. So, in theory, I should be pushing at least 650 and at most 800. I'm running one of your recommended settings -v 19 -w 192 after hours of fishing for the sweet spot. I made a post in the newbie section, http://forum.bitcoin.org/index.php?topic=18632.0, because I was unable to post here. There's more info on the way I have things set up, in that thread. Another question I have is, is it safe to assume that your program reporting accept: 0 reject: 0 hw error: 0 is normal on solo mining? I'm guessing that it wont start processing a block until it finds one, so those numbers will remain at zero, right? I know, I'm a nub, but, you gotta crawl before you walk, lol.