Maybe Pooler can fork the CGMiner-CPU-only code and implement his minerd code into it ?
The cgminer-cpuonly code IS the cgminer code, just with a different configuration option (--disable-opencl) when I build it. |
|
|
|
|
The donor pool had two short outages today so you would have noticed a difference with the new code by now.
|
|
|
|
The git tree should now have a fix for this issue in it.
Got it running now on the machine I compile on and re-enabled donations on it, will let you know if I see any problems. Thanks a lot. This all assumes the donor pool actually has trouble, so I've put it back to the one that has been unstable lately just now (which means you'd have to restart the miner, sorry). Funny how for a change I'm wishing for pool instability (shh! no one tell the admin  ) |
|
|
|
|
The git tree should now have a fix for this issue in it.
|
|
|
|
Would a 64-bit cgminer benefit in any way? I thought if I had some free time, I could try to compile in MinGW-W64
None whatsoever unless you're CPU mining, and even then you'd need to port the assembly code to make it work properly. Also mingw 64 is still much buggier than 32 bit and people have lots of problems with it. |
|
|
|
Thanks guys, I now have a postulated mechanism for failure with donations on which is why I came up with the idea. I've since moved again to a different pool for donations but I realise it also provides a bug mechanism (though harder to hit) without donations, so I'll work on a fix. Nothing like discovering a hard to find bug  |
|
|
|
Hardware Errors=0 even though one card is "DEAD" ? Hardware errors are very different to a card becoming unresponsive under load. Usually hardware errors occur if someone has unlocked the shaders in a card that has faulty shaders, or they are overclocking beyond reliable levels but below crash levels. Hitting hardware errors without a hardware hang/dead card is actually quite rare. |
|
|
|
Try turning donation off
Ok will try that and with LP on to make the test equal. Thanks. I'm thinking this may all be related to my donation pool being flaky lately with the move and nothing to do with the new version. |
|
|
|
When I switched to cgminer a couple months back I noticed that I always had a much higher reject rate. I get typically 3-7% rejects regardless of pool, Ars, Eligius, BTCGuild and others. Not sure what causes this and haven't tried to debug yet. I just let it be because I like the interface and monitoring in cgminer but it would be nice to track this down and see why the rejects are high. Before, same HW/OS setup, I used to get more like 0.7%.
Should I turn LP off? I thought that was to help reduce rejects.
There was a bug that would cause higher rejects with multipool setups that was fixed in 2.1.0. We're only turning LP off at the moment to debug a network connectivity issue. |
|
|
|
2.2Gh/s
Only change was adding this to .conf:
"no-longpoll" : true,
...which I have now removed, as the intermittent "not responding" problem was costing much less than 6%. That's a lot shyter than I would have expected... I guess longpoll is still a most valid mechanism. Was there any difference otherwise? |
|
|
|
Can you guys try starting it without longpoll? Maybe the longpoll switch code is responsible which is new since 2.1.0
Seems implausible, as I had the problem with 2.1.0. English grammar can be confusing at times, I admit. It's been there since 2.1.0.... it's not in 2.0.8 but is in 2.1.0 |
|
|
|
...
Anyway, lets see if we can find anything else in common, besides just cgminer.
- Im using google DNS
- I have donations enabled. (thinking of disabling it, just for testing)
- I have several pools configured in fail-over (but Ive since encountered the problem on several different pools)
- Im behind a NAT router
- hmm?
...
Donation and NAT, but not Google DNS; failover-only pools in this order: Eclipse port 9007; Bitminter; Eclipse port 8337; local bitcoind Hmmm... Can you guys try starting it without longpoll? Maybe the longpoll switch code is responsible which is new since 2.1.0 cgminer's stale rate should be exceptionally low even without longpoll, but it will be slightly higher. |
|
|
|
|
Thanks very much!
Those who gave me alternative payments in case chefnet didn't pay out, please PM me your address and I'll send it back if you like.
|
|
|
|
|
Yay thank goodness.
By the way, error 503 is a server not responsive, too busy etc. error... though it is possible to generate this artificially from the miner's end by having DNS issues, router problems and so on. Disabling cached connections in 2.1.1 after failure seemed to achieve sweet FA unfortunately. So I'm now officially in the NFI position.
|
|
|
|
I cannot code for a 5970 or 6990 without poking and prodding them with code, and since I don't own one, it's unlikely to happen in a safe manner. If I just guess, I'll likely do something which could be bad...
Would it be beneficial if we get you a 6990? That would most definitely come under the definition of rhetorical questions. Given 6990s cost more than any other card on the market, I think I know what the likelihood of that happening is, though. But just to be clear since I haven't answered: of course it would... |
|
|
|
|
Whatever, a GPU pushed too hard will produce errors, not rejects.
|
|
|
|
Now IF you have rejects not related to pool latency then your cards are trying to tell you something. It is possible to drive the card to the point of failure such that despite the higher hashrate you have some many rejects that shares/min is lower. Of course this should be immediately obvious with the giant ugly number next to R.  Just to be clear to others, the ugly number next to R is Hardware Errors. That's the only time overclocking too much or unlocking broken shaders and what not will actually decrease your effective useful hashrate even though apparently stable; when your cards starts making shit up. |
|
|
|
Over in mining hardware I just whined that I had an instance of a "SICK" GPU even after falling back to pretty vanilla settings of gpu-engine 725 (stock) and gpu-memclock 300 for my 5970s. Is there any chance that SICK like the following is not a GPU hardware issue? [2012-01-02 17:56:39] Thread 2 idle for more than 60 seconds, GPU 2 declared SICK!
[2012-01-02 17:56:39] Attempting to restart GPU
[2012-01-02 17:56:39] Thread 2 still exists, killing it off
[2012-01-02 17:56:39] Thread 8 still exists, killing it off
[2012-01-02 17:56:39] Thread 2 restarted
[2012-01-02 17:56:40] Thread 8 restarted
[2012-01-02 17:56:40] Accepted 00000000.30702585.cb8fdf73 GPU 5 thread 11 pool 0
[2012-01-02 17:56:41] Accepted 00000000.676a69c6.4b59b7db GPU 5 thread 5 pool 0
[2012-01-02 17:56:43] Accepted 00000000.1e5767ae.f669070b GPU 2 thread 2 pool 0 # note how healthy it is now!
Anything's possible, but note that the restart code was tested extensively on literally dozens of GPUs to get this sick restart code working -when possible- and the person who helped me test it had 72 GPUs that would often have boxes going down with any other miner. The idea was to make it recover to a fine state after enough rest if possible. So yes it's possible. Maybe even likely, who knows, but this particular scenario was not unusual even at normal clocks when some GPUs were run flat out, regardless of which miner it was. Interestingly it became FAR more common with the phatk2 kernel (which is what is used in cgminer) since that seemed to run GPUs that little bit more than anything else. |
|
|
|
|
I'm sick of adding special case command line parameters...
|
|
|
|
|
Show Posts
