[RC5] Unnecessary fragmentation due to dialup mode
enojon at delphi.com
Sat Dec 30 00:22:02 EST 2000
Sounds like a good theory but I've not seen this in "real world" usage.
Start with 32*2^28 and you stay there consistently. Fragments result
from clients' using default setting of 1*2^28 or 2*2^28 [per Jim Nasby
when I asked about a year ago]; the keyservers dole out these partial
keyspaces contiguously up to the buffer-in client limit. The partial
block is then doled to the next connecting client "fetch" which may
be individual with 32*2 and 500 limit settings (which, in theory, provides
max possible 16,000 work units, but is now tempered by the time to complete
a buff-in estimate].
Edwin ten Brink wrote:
> Fragmentation of the keyspace seems to be extremely common when using a dialup detection mode or a frequent
> update mode, since the client will request smaller blocks to keep his buffers almost exactly at at the 'ideal
> level'. Once fragmented, it's nearly impossible to regain a larger packet size, so you'll be stuck with lots
> of packets with 1, 2 or 3 work units.
> If this behavior is intended, then that's okay with me, but if it's not: why shouldn't we try to avoid
> unnessary defragmentation of the keyspace and let the client determine a minimum packet size to request,
> just like there's an algorithm to determine the ideal buffer size? If the ideal buffer size is, say, 24
> units, why not request 8 work units, regardless of the fact if there are 16 or 23 units in the buffers?
> Just a thought. Especially since the FAQ indicates a move towards larger packets to reduce overall workload
> and bandwith. (Refer to "Packets take too long to complete on my computer. They should be smaller!" at the
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5