The pool targets each worker submitting 16 shares per minute, or one every ~4 seconds.  Whatever difficulty it takes to do this at your hash rate (higher difficulty, less shares/min) the pool tries to use.  Higher target difficulty shares are worth more, but found less frequently.  Likewise lower target difficulty shares are found more often, but worth proportionally less. (I specifically say target difficulty because the achieved difficulty is meaningless.)

This is to make sure you submit enough shares to make stats usable and at the same time limit the amount needed to send to the pool.  16 shares per minute is pretty aggressive.  Some people want far fewer shares/min (higher difficulty) for some reason, which makes no sense and just adds unnecessary variance.

With the pool setting the difficulty appropriately, the pool can determine what works best for the pool load, also.

I do appreciate you taking the time to explain this.
I kept assuming because my units can do 1024 very quick on majority of pools that I was some how missing out on shares/work done by doing smaller shares at a more "aggressive" rate. I'll be quite honest, I see them buzz through 1024 so when I seen the speed of 256 it just felt as if it was slowed down. Maybe just my perception.

Thank you for explaining I will continue to give a run on your pool. You have very good feedback and people backing you up.

Let's find blocks now!

Your joy was before the current round, hmmm? :-p

I just tought that it might help people undestand how this pool works by making a summary of the pool operations in list form.

A) The pool maintains the following:
1. A share log.
2. A payout queue.
3. For each user, a record indicating their own personnal balance, their payout threshold, the date of their last payout and the date of their of their last account activity.
4. An offline wallet.

B) Initialization
1. The share log and the payout queue begin empty.
2. The personal balance of each miner is initialized at 0; and the date of their last payout and their last activity is initialized at the date they begun mining.
3. The payout threshold is chosen by each miner, if none is given, it defaults to 0.04194304 BTC.
4. The offline wallet begins empty.

C) Unit of accounting
1. The basic unit of accounting in Eligius is a "share". A share is 'worth' block_reward/bitcoin_difficulty. (At the time of writing this: 25 BTC/17 336 316 979 = 0.000 000 001 442 BTC)
2. The value of bitcoin_difficulty for a given share is the difficulty at the time the share was awarded. It does not change later when the bitcoin difficulty increases.
3. The value of block_reward, however, is always taken as the current block reward. So when the block reward will be cut in half in 2017, the 'value' of all the shares still in the share log will be halved.

D) When a user submits a miner share (a valid proof-of-work meeting the difficulty requirement of the pool, pdiff):
1. The pool adds to the top of the share log pdiff shares. These shares are identified as belonging to the miner who submitted them.

E) When the pool finds a block:
1. 25 BTC+Transaction fees worth of shares are removed from the top of the share log, and credited to their respective miners' record. Each miners who was credited at least one share has it's date of last activity updated to the time the block was found.
2. If a miner was payed out with the generation transaction of that block, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the moment the block was found.
3. The pool refreshes the payout queue, see below.

G) How the payout queue is built:
1. Each user records are checked. Miners whose personnal balance is above their payout threshold are put in the payout queue. Miners whose date of last activity is older that a month are also put in the payout queue.
2. The queued miners are sorted by the time of their last payout, the oldest first.
3. The pool then goes down the list and finds the last queued miner such as the total of the balance of all the miners above him (including him) stays below 25 BTC. All those miners are put in the generation transaction to be put in the next block the pool finds, to be payed the full amount of their balance.
4. If the payout queue does not contain 25 BTC worth of queued miners's balance, the exceeding amount is sent to the pool's offline address.
5. While the pool computes 1, 2 and 3 (it takes time), it makes the miner work on a simple block that would send all the generated amount to the pool's offline address, to not waste miner's work.

H) When the payout queue grows longer that a few hundred BTC:
1. The pool operator initiates a transaction with the bitcoins in the offline wallet, paying everybody in the payout queue (except those in the first block, so that miners still have something to work on) the full amount of their balance.
2. If a miner was payed out with the manual payout transaction, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the date the transaction was submitted.
3. The pool refreshes the payout queue.

I) When the Bitcoin network orphans a block found by Eligius.
1. Everything that was done when the pool found the block (see E) is completely reversed.
2. Safe mode is triggered, see below.

J) When the pool is in safe mode:
1. The pool works mostly as normal, meaning submitted share are recorded as belonging to their respective miners, and when a block is found, those shares are credited to the miners' balance.
2. However, the automatic payout by generation transaction are disabled: The pool will always mine to the offline wallet until the situation is checked by the pool operator, who'll do some sanity check to ensure everybody is receiving their due amount. If everything is OK, the pool will resume normal operation.
3. During safe mode, the payout queue and the stats displayed on the main site may of may not be correct.
4. Safe mode may be triggered by an orphaned block, but it may also be triggered when a checks built into the pool software fails for whatever reason, it is however usually benign, but better be safe that sorry.

Assuming his sentence is the first quote, and your proposed change is the second, his is far clearer.  If anything needs to be added at all, perhaps the second sentence could read, "The 'worth' of the previously found share does not change when the bitcoin difficulty changes."

The new point you added about what will happen when the block reward goes from 25 to 12.5 is very interesting and I hadn't thought about that previously, but it bears consideration especially if you bring it to its logical conclusion: a share becomes worthless when the block reward becomes 0.  The payout logic remains the same, (block reward + transaction fees) worth of shares are paid out, but the intrinsic "value" of the share, which previously was always some positive value in BTC, becomes zero.

According to The Bitcoin Wiki, the block reward of block # 6930000 and all subsequent blocks will be 0.

The ideal mathematical case is that it takes infinitely many steps, so you never reach 0, but Bitcoin cannot be subdivided smaller than 0.00000001 BTC. In 2140, the reward will round down to 0 and no new bitcoins will be created. However, that is very far in the futures, and many things will change from here. (One probable thing that might happen is that the protocol might be modified to make bitcoin divisible to smaller unit)

Anyway, the point is moot, as it is know that the current algorythm of Eligius is unsustainable in the long term. It is built as if transaction fees do not exist; and indeed at first it didn't even pay them to the miners. The fact that the transaction fees are put toward paying the share log is a relatively new thing (a few months), but the shares are still 'created' as if the the transactions fees were not paid to the miners.

That problem is not really significant currently, because the transaction fees are insignificant, but I'm pretty sure the pool operator will address this when the transaction fees will become significant. It is just difficult to devise a "fair" way of paying the transaction fees to the miners, because contrarily to the block reward, their value is unpredictable and varies a lot.

nice manual payout 

THX