Quote from: error on July 06, 2011, 04:16:00 PM

Nope, I see this directly at bitcoins.lc web site stats page. Also see them rejected in multipool's log. [...]
I have not yet gotten into the spaghetti code to see what, if anything, might be going on...

I had similar issues; they stem from the fact that Multipool.pl uses the "local" bitcoind to know when there is a new block.
IIRC, it also does not completely clear up the queue on a new block received (as threads have to pick that up).
As such, the following scenarios may develop:
- the miner receives the long poll, and the miner does _not_ clear its queue / request more work => nothing to do with Multipool.pl but I think phoenix did that Sad

-- you can verify this by seeing if the rejects are clustered after a long poll.
- your bitcoind sees the block & notifies the miners at the same time as all the pools you're getting work from also see it; all is well as the new work fetched by Multipool.pl is pristine and new.
- your bitcoind sees the block & notifies the miners PRIOR to a specific pool also realising there is a new block: your miners will request Multipool.pl more work, which in turn will straightaway request it from the pool (which would give work for the previous block); the pool finally realises there's a new block; your miners finish working those works and give them back to Multipool.pl which gives them back to the queue: rejected.
- your bitcoind sees the block & notifies the miners AFTER a specific pool realised there is a new block; the miners probably had already asked for "good" work but instead end up dumping work which isn't necessarily stale.

Additionally to that, Multipool.pl's handling of whether a share was already sent or not did not work properly. I merely ripped off that part of the code, saying " I will pass on to the pools whatever my miner gives me ". Reduced rejections a bit, but not enough -- reasons above.

The only way I see to fix the above is to have Multipool.pl have one longpoll connection per pool, and having it invalidate work queue-by-queue depending on whether it received a longpoll "ping" from that queue or not. After all, if the queue has not yet realised there is a new block, shares from the previous block would still be considered valid by them, _and_ they would not give a new block's work unless they know there is a new block.

Multipool.pl's code uses basic sockets and select(), and... threads.. I have been toying with the idea of doing the above using AnyEvent (async IO for Perl), but would only do/finish that for a _personal_ multipool switcher rather than something multiple people would connect to and distribute payments to etc.
I kind of gave up on beating Multipool.pl into submission not for lack of trying but rather as it came to a point where it'd be easier to rewrite most of it rather than trying to fix it. I develop in Perl for a living, so it's not like I can't read the code. There are too many places where I know what the code does, but have no clue as to the reason _why_ it's doing that

I will likely soon release what I am currently using for my PC, which has only _one_ graphics card. It uses bits of the algorithm from Multipool.pl but rather than getting shares and distributing them to miners, has the _miner itself_ connect to the best/wanted pool. I think there's another thread for another program that does this already for multiple cards as well, but it's a bit overkill for what I needed.

I am not sure if enough people would need a "personal multipool switcher which distributes shares", which is what Multipool.pl does, other than for having its code somewhere in Github so multiple such pool hopper pools can be created by anybody.. to warrant developing a better pool hopper that works that way. After all, if there are two/three pools like that, what is the point? Pointing them at each other?