On Sun, Mar 20, 2011 at 03:57:45PM -0400, Wietse Venema wrote:
> Below is the manpage entry for long queue ID support. Let me know
> if there's anything missing.
With the first few characters of the new long queue-id encoding the
epoch-seconds time and not the micro-seconds time, it seems to me that
the current scheme for "hashing" the "deferred" and "defer" (and perhaps
other) sub-queues needs adjustment.
Also, just switching the position of the microseconds and epoch seconds
in the new long queue-id is perhaps not quite enough, the first character
of the new microseconds has only 8 possible values (0-7), previously
the range was 16 values (more effective hashing).
Use of base 32 encoding, would give a much better result, since 32^4 is
10^20 or just over a million, so the microseconds can be encoded just
as efficiently in base 32 as in base 51, but the distribution of the
first character is much more uniform (32 possible values).
So my proposed update for the long queue id is:
- 4 octets of base 32 encoded tv_usec
- 6+ octets of base 51 encoded tv_sec epoch time
- one non base 51 octet separator
- inode number in base 52.
--
Viktor.
