@Multipool:

One potential issue I noticed when I was testing locally before opening this up to everyone else...

I had thrown the 'production' switch, which caused the work queue entries to start out at 30, but was only testing with about 300MHash/sec.  Occasionally (presumably after a new round began on the current pool or something), I would get dozens of invalid shares in a row from that pool.  Decreasing the work queue size seemed to mitigate the issue somewhat.

I occasionally saw work queue 'purge' messages going by in the log, but never noticed a non-zero number of entries being purged during these rejection streaks.

I noticed it in particular from Mt. Red, to the extent that I ended up disabling them as a target pool (and I don't specifically remember if it occurred on other pools or not), so it may have been a pool-specific thing, but I thought I'd mention it.

If you feel like explaining it, how is the work queue purging determined?  I know that Multipool-the-server implements Long Polling.  What about Multipool-the-client? 


aside:
For anyone running Multipool locally/with a fairly small hash rate, I might suggest decreasing the 'production' work queue size which defaults to 30 queue entries (around line 43) to avoid similar issues.  OTOH, maybe this is a non-issue and I was just having problems with Mt. Red.