From Slush's pool's homepage:
Pool now supports Long polling and NTime rolling. Older miners have many problems with those new features, which can negatively affect your rewards. Please update your miners to latest version!
What does NTime rolling and nonce range mean for me as a miner? And what miners support it? (+versions)
NTime is the integer timestamp in seconds. It is one element on the block header. Each second NTime increases by one. "NTime rolling" is a getwork parameter indicating how many seconds forward a miner can still consider this getwork valid (by incrementing NTime locally).
To understand how this is used lets first take a look at Bitcoin Block Header.
For a given set of transactions only two elements in the block header change between hash attempts.
So to construct a valid header a miner must have the current value of these two rapidly changing elements. The other elements of block header are also needed but changes occur much less frequently and trivial for the pool to handle.
The basic (inefficient) method to handle these two variables in a getwork request is for the pool to explicitly provide both values in every single header. The pool will provide one getwork every second. A miner with less than 4.2GH/s however will on average find < 1 nonce per getwork. As an example, a miner which can execute 100MH/s will cover the nonce range (2^32) in 40 seconds. The pool will need to issue 40 getworks per share. The avg # of getworks per share will depend on the speed of individual miners however a significant amount of excess communication is occuring.
Now both nonce range and NTime are highly predictable so a miner could simply be given a starting point and locally change both values. Doing this significantly reduces the number of getwork requests required to cover the same number of hashes.
By allowing the miner to roll the NTime forward for 10 seconds the pool can cut the number of getworks from 40 to 4 seconds.
There is also a benefit for fast miners which are already efficient.
A 2 GH/s miner will find on average one nonce every 2 seconds. With an NTime rolling value of 10 seconds. The same getwork will enable the pool to acheive 4 nonces per getwork.
The NTime rolling value instructs the miner how far it can increment NTime (in seconds) before needing to request new work. So a NTime rolling value of 4 means the miner can use this header for 4 seconds before considering it stale and likewise a value of 40 indicates to the miner it can use same header for next 40 seconds. Pools can use increasingly large NTime values however there are diminishing returns. A block is found on average every 600 seconds, and periodically transactions need to be included.
Still an optimal Ntime rolling value ensures the pool is only updating getworks when work has actually updated in a meaningful way (elements changed other than nonce or time).
An example: A pool provides a 100MH miner a block header containing the current ntime, a nonce range of 0 to 2^32 (full nonce) and an NTime Rolling value of 40. The miner would hash until the local time increments 1 second (roughly 100 million hashes) then it would increment NTime value and continue to hash for another 1 second (roughly 100 million more hashes). Once it has incremented NTime 40 times it must request new getwork.
Proper use of NTime rolling improves pool efficiency by reducing number of getworks per share. In your example I speculate that Slush looked at the pool logs and determined that some miners were requesting work "too often" indicating they were ignoring or incorrectly using NTime Rolling value. Obviously a pool operator would want all miners to use latest protocols such as NTime rolling, and Long Polling as it allows a pool server to handle a higher throughput with same amount of hardware, bandwidth and other resources.
I don't have an exhaustive list but as far as I know any "relatively recent" miner supports NTime rolling (as in released in last 6 months).
