Ah okay. Thank you very much for clearing things up for me. I think i have a better understanding of what's going on, now. But i think there is an additional reason, why the client fetches new data. This is because my CPU miner, which is ofc. very slow, requests new work every somewhat 60 seconds and i doubt, that it can go through all nonces in this short time.

Another thing i've noticed btw.:
My version of proclbm (included with guiminer) is not updating it's internal timer, when getting new data through a long poll. It will fetch new work every X seconds, no matter if it got new work through a long poll a second ago. I didn't notice this behaviour in DiabloMiner, so i think it's not meant to be this way.
This supports my theory, that there has to be another or additional reason for the client to fetch new work, me thinks.

But, in the end, a lot of getworks are not bad for me, but for the pools, because they get more requests, right? I don't think i should have to care about that too much any further, should I?

Every time the client requests new work from the proxy, so every 40-50 seconds, this will happen:

The proxy asks the first pool in his priority list for new work. If that pool does not respond within X seconds, the proxy goes on and asks the next pool in his priority list.
This will repeat until a pool does respond and delivers new work which the proxy can relay to the client, or the end of the prioriry list is reached.

If a pool does not respond within a given time, which is about 3 seconds, the proxy will continue with the next pool in the priority list.

Okay. I've been running a miner for somewhat a week now and recently have set up the flexible mining proxy, found on this forum. As i had some problems with that and wanted to understand, what's going on behind the curtain, i extended the codebase by some logging and a console window. By doing that and observing the output of the communication client<->proxy, i noticed a strange behaviour of the mining clients, that i do not understand:

The worker logs in to the proxy, new work is requested and forwarded to the client. The client starts processing.
So now, after 45-50 seconds the client logs in again and requests new work again, no matter if it has returned a result for the work it has previously requested or not.
It can happen multiple times in a row, that it re-requests new work, without returning something.
On the other hand it can happen, that the client is able to provide, say, 2-3 solutions within that said 45-50 second time frame.
So everything from 0-X results may get returned by the client between those calls to fetch new work - i supposed this is bases solely on luck.
Thing is, if it will not return something, the ratio requested:returned will go down, which, sounds bad and as a side-effect, it got me banned on BitcoinPool.com.
I tried a lot to figure out, why there is this re-request every 45-50 seconds and how to change it.

I even tried to implement a very basic throttle, that will keep track of the number of work units the client is currently working on and which blocks all further requests, until solutions for the these units are returned by the client. The throttling did not work as expected: the miner went somewhat crazy by not getting new work. The miner even ran out of work and stalled, when it was working on a work unit and for some reason kind of discarded it, without returning a solution for it, which would have freed up the slot for a new request.

tl;dr
The client requests new work every ~45-50 seconds, no matter if it has returned a result for the previous work or not. This decreases request:returned ratio.
Why is that happening? Can this be prevented? Is there a good explanation about the techniques behind all this around? All i could find was some basic blah blah. :|
( A side question would be: what exactly does the client get from the pool? If mining solo, i work on a whole block, but what am i mining on when mining for a pool, exactly? )

Here's a sample of my log:

[ 19.06.2011 13:56:10 ] [3] Polling BitcoinPool
[ 19.06.2011 13:56:11 ] [3] BitcoinPool responded.
[ 19.06.2011 13:56:11 ] [3] Processing work for BitcoinPool (09fb56385d5851ce7533d20134635832)
-------------------------------------------------------------------------
[ 19.06.2011 13:56:33 ] [3] Worker returned work for BitcoinPool (09fb56385d5851ce7533d20134635832)
[ 19.06.2011 13:56:33 ] [3] Sending work to BitcoinPool ......success!
[ 19.06.2011 13:56:34 ] [3] Work unit is:valid
-------------------------------------------------------------------------
[ 19.06.2011 13:56:55 ] [3] Worker returned work for BitcoinPool (09fb56385d5851ce7533d20134635832)
[ 19.06.2011 13:56:55 ] [3] Sending work to BitcoinPool ......success!
[ 19.06.2011 13:56:56 ] [3] Work unit is:valid
-------------------------------------------------------------------------
[ 19.06.2011 13:57:01 ] [3] Polling BitcoinPool
[ 19.06.2011 13:57:02 ] [3] BitcoinPool responded.
[ 19.06.2011 13:57:02 ] [3] Processing work for BitcoinPool (09bde84558a701a39f07224b3bc9c83c)
-------------------------------------------------------------------------
[ 19.06.2011 13:57:53 ] [3] Polling BitcoinPool
[ 19.06.2011 13:57:54 ] [3] BitcoinPool responded.
[ 19.06.2011 13:57:54 ] [3] Processing work for BitcoinPool (5e779c1f2a8227810ccc1785f5835cd5)
-------------------------------------------------------------------------

Here you can see the first work request.  Soon two solutions are found and returned for that work. After 51 seconds, new work is requested. After another 52 seconds, again, new work is requested and no result has been found in the meanwhile., efficiency goes down. *rinse-repeat*

Thank you for reading and for clearing things up for me!
krom

All working "quite" well with 1 miner and 1 pool.

Some things i've noticed:

• I have a lot of "Listener for "Proxy": 15/06/2011 00:23:30, Unexpected error:" lines on GUIMiner's console, using poclbm and the proxy.
• Long polls seem to get through sometimes, but not all the time - i get a lot more of these when connecting to the pool directly, but maybe this was random.
• Fall back to other pools does not work for me, nor will the miner work on any other pool than the first one i created, even if i disable that pool overall or remove it from the worker's list.
• A second worker i added is able to get work (only from the first pool i defined as well), but the returned shares never show up anywhere - not on the dashboard nor the pool's stats page. "Last accepted submission" is "Never" for that worker all the time as well.

I'll dig into the problem further, but have no time to do so yet.
Besides that: Good work and keep it up! When i'll have more than some fractions of BC, i'll donate to you.

Update:
Long poll seem to be okay.
Problem 3 was solved by adding 'http://' to the pool's url. Won't work without.

Maybe this is a stupid question, but where can i look up the total sum of shares i've processed for the current block?
On my personal stats i can see a 3h and 15min average, but where are the totals? And can i look up the stales and rejected blocks somewhere as well?
Besides that, keep up the good work!

Edit:
On a side note, i get tons of RPC errors today ("Problems communicating with bitcoin RPC", "upstream RPC error") when mining with your pool. I have BTCGuild running on low priority as a backup and this is running quite smoothly.

Thanks for your explanation. If you are able to adjust prices regulary and (quickly) convert them to real cash automagically, this should work. I didn't think about that (and i should have *blush*).

OPs question is what i'm asking myself for a couple of days now and i've found no reasonable explanation yet, besides "BC is teh future!".

Exchange rate is fluctuating extremely and is too easily influenced by lots of factors right now, which makes it a pure gamble to accept bitcoins for goods that you've payed real money for, imho.

Bitcoin exchange rate needs to be somewhat stable, before i'd personaly would accept them as a payment option. You never know what they will be worth the next hour/day.
Playing around with the money on the exchanges is something for banksters, not merchants. At the end, as a merchant, you've payed real money for the goods you sell and you have real bills to pay.

What am i missing?

Maybe this helps a bit:
https://en.bitcoin.it/wiki/Transaction_fees

But: According to that, it shouldn't have charged you a transaction fee, since the transaction is above 0.01 bc:

On the wiki there's another part when you will be charged a fee, based on the kb size of the transaction - but i still don't get that part, so can't explain.

0.2225 € per kWh in germany. (roughly 0.15 USD)

Could have been much cheaper with nucular power (0.08 € at least), but i opted for green electricity and on top i do pay an additional 0.0125 € per kWh to support development of solar/water/wind power plants even further. Makes it a little bit hard to get profits out of bitcoin, but i'm not going to support a third tschernobyl/fukushima.

edit: fixed decimal points

There's a problem with the most recent version of Bitcoin (0.3.22-beta), which results in the problem you describe. Use bitcoin 0.3.21-beta (link) and it should work.

@DiabloD3:
Maybe you should put that info on the first post as long as the problem persists. Although it's not a problem with your miner, ppl might think that.


edit: maybe i should add that i do use Win7 64bit and a HD 4870, accompanied by a AMD X2 @3Ghz. No clue if this problem exists in other OS versions / constellations.

I had the same problem when setting up the miner. There seems to be a problem with the most recent version of bitcoin (0.3.22-beta). Try version 0.3.21-beta and it should work - given that the rest of your setup is okay.