MikeH
01-12-2003, 01:38 PM
Question: Do we take any consideration of client processor speed when distributing k/n pairs to SB clients?
I assume at the moment you are taking the smallest sieved n from the database of untested k/n pairs. Thus all k values have their n's slowly increasing (with the possible exception of k=54767 which seems to have slipped behind, but irrelevant to this discussion).
I also think I would be correct in saying that it is important to the project to try to keep the "n upper bound" values moving forwards as quickly as possible, and to not let the gap between the "n upper bound" and the "max n tested" grow too large.
If you made an allowance for the client processor speed, then in theory at least, it should be possible that when each SB client completes a k/n pair, at that instant it is both the "n upper bound" and the "max n tested".
This would be achieved by giving the lowest n value available to the fastest clients, but for slower clients giving an n value slightly higher up the key space. If the offset into the key-space is perfect, when the client completes the k/n pair, it will be both the "n upper bound" and the "max n tested".
From back of envelope math, if we call a PC faster than 2.0GHz 'fast' (i.e. it would get the lowest n), then for a PC one quarter its speed (500MHz), we need to allocate an n value which is
(number of completed tests expected returned in time taken for 2.0GHz PC to complete) * ((fast PC speed / target PC speed) - 1)
A 2.0GHz PC will take about 17 hours to complete a unit in current n range (n=2.2M), thus from current stats (885 proth tests completed today), for 500MHz PC,
(885*(17/24)) * ((2000/500) - 1) = 627 * 3 = 1881
Which means for this example, today a 2.0GHz PC should be given the smallest available n, while the 500MHz PC should be given the 1881st smallest available n.
Yes, you will still get users that give up with SB, leading to the k/n pair being recycled, but this method would guarantee that recycled k/n pairs are always allocated to fast PCs, pulling back the "n upper bound" as quickly as possible.
If we had a configuration item in the client, that allowed the user to indicate the expected number of hours the PC will be on, then the accuracy improves.
Obviously this adds complication to the key-space server s/w (and a little to the client), and whether this is worth the effort at the moment depends upon how slow the slowest PC currently being used is. But as n increases some sort of optimisation will be better than none at all.
Of course, if you're already doing something like this, then please ignore my ramblings.
I assume at the moment you are taking the smallest sieved n from the database of untested k/n pairs. Thus all k values have their n's slowly increasing (with the possible exception of k=54767 which seems to have slipped behind, but irrelevant to this discussion).
I also think I would be correct in saying that it is important to the project to try to keep the "n upper bound" values moving forwards as quickly as possible, and to not let the gap between the "n upper bound" and the "max n tested" grow too large.
If you made an allowance for the client processor speed, then in theory at least, it should be possible that when each SB client completes a k/n pair, at that instant it is both the "n upper bound" and the "max n tested".
This would be achieved by giving the lowest n value available to the fastest clients, but for slower clients giving an n value slightly higher up the key space. If the offset into the key-space is perfect, when the client completes the k/n pair, it will be both the "n upper bound" and the "max n tested".
From back of envelope math, if we call a PC faster than 2.0GHz 'fast' (i.e. it would get the lowest n), then for a PC one quarter its speed (500MHz), we need to allocate an n value which is
(number of completed tests expected returned in time taken for 2.0GHz PC to complete) * ((fast PC speed / target PC speed) - 1)
A 2.0GHz PC will take about 17 hours to complete a unit in current n range (n=2.2M), thus from current stats (885 proth tests completed today), for 500MHz PC,
(885*(17/24)) * ((2000/500) - 1) = 627 * 3 = 1881
Which means for this example, today a 2.0GHz PC should be given the smallest available n, while the 500MHz PC should be given the 1881st smallest available n.
Yes, you will still get users that give up with SB, leading to the k/n pair being recycled, but this method would guarantee that recycled k/n pairs are always allocated to fast PCs, pulling back the "n upper bound" as quickly as possible.
If we had a configuration item in the client, that allowed the user to indicate the expected number of hours the PC will be on, then the accuracy improves.
Obviously this adds complication to the key-space server s/w (and a little to the client), and whether this is worth the effort at the moment depends upon how slow the slowest PC currently being used is. But as n increases some sort of optimisation will be better than none at all.
Of course, if you're already doing something like this, then please ignore my ramblings.