Quote from: tantive on June 14, 2011, 12:55:58 PM

@TheSeven: maybe I am wrong, but I am currently not sure if pyfpgaminer is still having some issues.

Currently I have two fpga board, running in different physical locations.
Both boards are running different bitfiles.

If I now compare the outputs of pyfpgaminer, then on both consoles I see around 10% rejected shares.
If I match the consoles timewise, then the rejects happen at the same points in time.

Do you have any idea if that could be related to specific api calls or something within the communication with the pool?

A)

Found share: eligius:dd51c0630a1638ba8e819b38aa18183b7d4e8d98d5260805d82f3ba9b3fdcbf8:bb9e77d84df7598d1a1d932f:7a031f22
eligius rejected share 7a031f22
Mining: eligius:f219c175c6f49f8ec2cf0b302307f4f439650c7886b7516ff06656ae84831717:dd20a1094df759a91a1d932f
Mining: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f
Found share: eligius:098e08762b694e86849b98bb5cfb58289fab9647e9ee082973af9c3cc8dfc00f:27be68d44df759c51a1d932f:6cfa9395
eligius rejected share 6cfa9395

B)
Found share: eligius:3f8347933e5369be01edc6f05284cdefce58f727e97ef6c9334bc8da642a4186:c87f6b0f4df759641a1d932f:0bb3d26f
eligius rejected share 0bb3d26f
Mining: eligius:0c6933c15b68a5a1480f60382eaa95058eb8ddc3abf2629332c2bbbf05571b68:e3ea48fe4df7597f1a1d932f
Mining: eligius:956dfec46f309dfe46db73459267fd2ac3a7b30d54b4ea1e6b437c879a2ee739:84ebf8984df7599a1a1d932f
Mining: eligius:6a27c65613e41864db70feefdb8db812aecc86a6dedb6104b10f06acb20d7f2b:213e86ab4df759b71a1d932f
Mining: eligius:434201cd46a5972605ee6a5f2fa4baa12f68b73871b164b82597f3a817258bb2:2dd2aca84df759d21a1d932f
Mining: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f
Found share: eligius:73347264657294419b1f2ce908373d775decd40116836091ceddc01b01492d5e:632383ca4df759ee1a1d932f:2b11428c
eligius rejected share 2b11428c

It's running fine over here with around 2% stales at continuum. Eligius is known to have very sluggish long polling, which means that it takes up to a minute until it notifies the miner that there is a new block. This could possibly explain a higher stale share rate, but 10% is a damn lot.

Assuming your miner runs at 100MH/s, it will start working on a new job every ~30 seconds. At the default settings it can buffer up to four jobs in the worst case (1 being worked on, 2 in the queue, 1 being fetched, waiting to be put into the queue), which would keep it busy for two minutes. That would be around 20% stales in the worst case, so it seems like long polling doesn't work at all for you.
Are you getting lines like "Long polling: eligius indicates that a new block was found" occasionally (every 10 minutes on average)?

I'm running mine with 7 configured pools, and it seems like some of them (however not the primary two ones) drop long polling after like a day. The long polling thread can't possibly die (while True: try: ... except: pass), so there are two possible root causes for this:
1. Something on the pool side stops answering long polling requests (this was my suspicion, that some pools keep banning me for having long polling sessions but not sending any shares, because I only use them as backups if the primary ones go down)
2. Something in the python http client module I'm using locks up the long polling thread for the pool, even though I've specified a timeout of 2 minutes.

I'll have a closer look what's going on. To mitigate the problem in the meantime, you can try setting "buffer": 1 and "fpgajobinterval": 10, which should bring the stales down to <5% even without long polling, but causes a higher pool server load.