Quote from: jedi95 on January 07, 2012, 08:48:39 PM

Quote from: Diapolo on January 07, 2012, 03:22:18 PM

I'm using 1.7.2 with an own kernel version and 1/3 of the shares for my 6550D (A8-3850 APU) are rejected with:

Code:

[07/01/2012 16:15:34] Reject reason: unknown-work
[07/01/2012 16:15:34] Result 00000000ab246f85... rejected

What does this mean? Agression to high? Is the valid nonce invalid, because processing took too long?
My command line is:

Code:

-a 50 -k phatk AGGRESSION=12 DEVICE=1 FASTLOOP=false VECTORS2 WORKSIZE=64

Code:

[65.86 Mhash/sec] [103 Accepted] [33 Rejected] [RPC (+LP)]

Thanks,
Dia

Btw.: Anyone here, who is able to debug why I can't seem to get 3-component vectors working (see: http://www.mediafire.com/?r3n2m5s2y2b32d9 and use VECTORS3).

It looks like you have run into the same fundamental problem I am trying to address before I can implement rollntime.

Essentially the server is rejecting your work because it is too old, not because kernel processing took too long. At 65 Mhash/sec, it will take just over a minute to process an entire WorkUnit of 2^32 nonces. Now, this work is not necessarily "stale" because it's from the current block and it meets the target specified by the server. This is made worse by the fact that Phoenix maintains a second WorkUnit in the queue by default. On a 5870 that can check the entire 2^32 space in 10-11 seconds, this is beneficial because it allows the miner to continue running during momentary connection disruptions or server load spikes. However, on hardware that takes over a minute to process 2^32 nonces, this can cause shares to be submitted from WorkUnits that are over 2 minutes old. This won't cause problems when the block changes because all work from previous block will be discarded immediately.

Rollntime introduces the same problems, since even very fast miners can now function for 30-60+ seconds on a single WorkUnit. The queue behavior needs to be adjusted to account for this. Most likely the solution will involve monitoring how much time is left until the miner runs out of work, and fetching more work when it falls below some value.

The message you are getting is sent by the pool server using x-reject-reason. I'm going to guess that the pool you are connecting to "forgets" about work it has assigned after some amount of time. (probably to save resources) I recommend trying other pools to see if you get the same behavior.

That said, aggression 12 on hardware doing only 65 Mhash/sec is probably not a good idea. Your kernel execution times are going to be something like ~4 seconds. This is problematic because you can't reasonably interrupt kernel executions to switch work. (eg: when the block changes) On average this is going to mean 2 seconds of wasted time per block (which amounts to a 0.33% loss) Try aggression 10 or so, which should limit this effect without much of a hashrate drop.

You can also use -q 0 to disable the queue entirely. This cuts your work age in half compared to the default of 1, but you might see the miner idling once per minute when it needs new work. At aggression 10 (kernel execution time 1 second) this shouldn't be a problem under normal cases. This allows for enough time to fetch new work before the miner runs out completely. However, this doesn't work at low aggression where the kernel execution time is a small fraction of a second.

Thanks for this explanation, so I was on the right track. Are you trying to implement a solution for this currently or is there anything we / I can do to assist you there? Have you got an idea for the vec3 stuff not working?

I'm now trying AGRESSION=10, will report back after Phoenix ran a bit with that setting.

Edit 1: That's another error and has nothing to do with the discussed problem, right?

Code:

[08/01/2012 12:45:35] TypeError in RPC sendResult callback
[08/01/2012 12:45:35] Result 000000001fa9ed72... rejected

Thanks,
Dia