bitHopper
bitHopper copied to clipboard
BUG: UPSTREAM: CGMINER w/ Multiple Coins Crashes
EDIT: So cgminer crashes if it tries to mine multiple coin types. Use a different miner if you are doing that. The dev's refuse to fix it. I may.
Hi..this will be the most weird bug report I've ever done..
I did not touch BH since 2.4.4 which worked pretty good. It was the last version without the new bh.cfg (just to give you an idea) and plugins. Since this version, every newer version till bleeding edge simply don't work for me. I always get issues with RPC getwork flooding, connection refused errors, plugin errors or simply BH hangs after a while. Also there is a error about already imported stuff directly when starting BH. (peak init.py) I am using 3 clients all on cgminer (tried 1.6.1 and 1.6.2) and Win7 64bit.
I can't really provide a detailed bug report but maybe you know already, whats wrong.
Hope the next version will be stable again.
Cheers End
Getwork flooding may be related to LP/announces from digbtc...something to look into.
http://pastebin.com/DYAsfF3J
have commented out digbtc
I'm still running cgminer 1.5.6 as that's the only version that seems to work. All versions after that cause stalls in my miners. Maybe try 1.5.6.
Hmm..is was using 1.6.2 with 2.4.4 for a while without issues.. No stales here..
Works better with cgminer 2.0.0
Also having the getwork spam issue. Phoenix 1.6.2 Phatk 2.2 Win7 64. Edit: 2.4.4 also having issues for me.
Ok, with cgminer 1.5.6, everything's fine, no getwork spam
With cgminer 2.0, LOT'S of getwork spam almost immediately.
No other changes other than the cgminer version. Someone mentioned that 1.5.6. uses phatk2 whereas 2.0 uses phatk2.2. Not sure if that's a place to start looking for the problem.
I am having the same issue. Commenting out digBTC (all versions - BTC i0C, SDC) didn't help. Tried phoenix 1.6.1 and phoenix 1.6.2, ubuntu 11.04 and BAMT, phatk 2.0 and 2.2
I believe it is not miner related.
Try the latest version. I turned the timeout way down so miners don't keep retrying our proxy and causing us to completely flood a server.
Thanks. I'm still out at work on an emergency call... I'll let you know first thing in the morning. On Sep 7, 2011 2:31 PM, "c00w" < [email protected]> wrote:
Try the latest version. I turned the timeout way down so miners don't keep retrying our proxy and causing us to completely flood a server.
Reply to this email directly or view it on GitHub: https://github.com/c00w/bitHopper/issues/343#issuecomment-2032001
The problem is still there. It seems even worse. Previously it would work for 30mins to few hours. Now it seems to get into getwork flooding faster.
Update. It seems that the problem starts when a new block is announced, I am not positive about it though. A restart of the bitHopper does not solve the problem. However restart of the miners after the restart of the hopper helps. I guess this may shed some light on the source of the problem.
The flooding getworks are empty "[]" opposed to valid ones "[32adfsjf023784...many chars...23751sfds]".
It seems that my IP is getting banned on some of the pools because of the empty "getwork" flooding. So I would rate this as a priority.
vcaxx, if you haven't already, disable digbtc. That should "fix" it.
simonk83,
How exactly you disable digbtc? I deleted it in user.cfg. I also deleted digbtc in pools.cfg, though I did not do it in the latest version. But in both cases I am still getting their block announcements in the bitHopper output.
Is there some more that I should do?
Hi there, no that's fine. What you're seeing is just other people's announces from IRC. Sort of. If you've removed them from the configs then you should hopefully be fine. Hopefully you won't see any more spam.
OK,
After removing digbtc from pools.cfg in the latest version it seems to be working for now, before it would get into flooding within few minutes. I'll update if it starts again.
ozco and eligius are still lagging - I guess they blocked me. Is there a mechanism that hopper retries them after some time?
Thanks!
Yes there is a delagger.
Crap. This just started reoccuring this morning, but as joules suggested it seems it might be related to cgminer 2.0.0. With cgminer 1.5.6 it seems fine, but 2.0.0 causes the spam.
I spoke to the cgminer dev and he (quite rightly) pointed out that this problem doesn't exist when just mining "normally" so it's obviously BH related. Any idea what it could be c00w?
I'll take a look.
Thanks mate
I tested on my dev machine with 2.0.1. It worked fine. No obvious spam. I couldn't get it to work on my actual miner though.
I don't get any getwork spam. I do get issues with pool 0 not providing work fast enough. Which may be causing spam in older versions if it doesn't work correctly. But there appears to be no effect on hashrate.
Hi c00w. I tried 2.0.1 this morning. It ran fine for about 1.5 to 2 hours, then the getwork spam started. The only reason I noticed was because the fans quietened down :D Unfortunately it seems pretty random, but it should happen eventually.
Do any output messages come from cgminer? Like pool being slow etc...?
Doesn't seem to be, no. It just sort of sits on Accepted [blah blah]
Still happening with 2.0.2 :(
This time I got "Pool 0 is not accepting work fast enough"
Is it not doing work submission in parallel?
Not 100% sure what you mean by that but basically:
Suddenly heaps of getwork spam will occur Cgminer reports "Pool 0 can't provide work fast enough " All gpus stop working This continues until a new vote happens in bh (or maybe just a pool change) at which point it all starts working again. rinse and repeat
I can second that, but with phoenix 1.6.2 ... I do think it has to do with phatk. i switched to poclbm on my rig, and the problems with getwork disappeared.
Ok, trying poclbm now but its a good 150mh slower :(
I tried poclbm R6950 OC - Cat 11.7 - SDK 2.5 - Win7 x64 and went from ~360 down to ~358 still faster than phatk 1.x Also of note... Phoenix 1.5 and some phatk before 2.2, maybe diaplo, on R5750 has no getwork issues.
I am getting the irc disconnect/connect again, though (Off topic)
Yes c00w.. it does not submit work when the error occurs
Is there any sort of watchdog feature that can be added where, for example, if it sees say 20 getworks in a row without a submit then it does
Ok, poclbm gives the same problem. I also tried an older pharmacy version from cgminer 1.5.6 but that gives the same problem. Probably not phatk related then.
^ phatk, not pharmacy ;)
um, dunno if this bh.cfg option acts as a getwork watchdog but here it is
-
connection timeout for work requests
work_request_timeout = 2.5
@simonk83: Did you get rid of all 3 of the digbtc's in both pools and users?
Does making the timeout be abut 30 seconds help?
So work_request_timeout = 30?
Just driving back from the snow now, I'll try when I get home.
I think so macboy, I'll double check
Simon: Try this kernel. It's the one that is working with phoenix 1.6.2 and bH. I just applied this kernel to the phatk folder and dumped phatk2 from phoenix, and I'm up without getwork spam... bout 2 hrs so far :-) Going to run all night. Will update during lunch...
http://sourceforge.net/projects/phatk/files/phatk-2.2.zip/download
EDIT: My current config actually has all 3 digbtc's and still working...
Hi all,
Removed all the digbtc's - no help Changed the work request timeout to 30 - no help Macboy, I tried your kernel but as I'm using cgminer it spits the dummy and won't work. I tried renaming kernel.cl to match the cgminer version, but there must be more to it than that unfortunately.
Hmmmm. Try a timeout of like 0.3.
Just an update... Dumping phatk2 did work for me. Simon: Try phoenix with the above kernel... Should keep your hashrate the same. That's all I got.
CGminer can't handle multiple coins. We're seeing if we can convince the dev to give us an option to disable it.
No luck with the dev. But it looks like if we do a LP to the client every time we switch coin types it might work.
great, i surely didn't like cgminer dev attitude bout this
I think its fixed. I'm going to wait a little then close the issue. We needed to do an LP every time we switched coin types.
Its not fixed. However its an upstream bug that they won't fix. I forked cgminer but I haven't gotten around to implementing different cointypes.