However, it becomes increasingly less efficient for everybody as more and more people get faster machines too. The greater amount of network fetching and flushes translates directly to a greater amount of network bandwidth required by distributed.net's servers. Furthermore, as the number of total people participating in distributed.net grows, the total amount of required bandwidth increases as well. It might also be worthwhile to point out that your individual client actually has an overall reduction in work efficiency with smaller packets, since it must spend a greater amount of time switching between packets and restarting a new packet with different packet information.

Ideally we could distribute packets that are dynamically sized to exactly correspond to the speed of each machine, so that each packet would require exactly 24 hours or so. However, in the non-ideal world this is not quite as doable and so a compromise must be made and a size selected for consistency purposes. Just for illustrative purposes, in RC5/DES/CSC the "work unit" size was 2^28 keys (and packets could be be a multiple number of contiguous "work units"). In OGR-24, the "work unit" was selected to be the 5-stub. For OGR-25, since the total ruler length increased by one mark, the work unit size was also increased by one mark, yielding the 6-stub.

For future projects and contests, it is very likely that the work unit size will be selected such that a "typical" machine will process an "average" work unit will be completed in approximately 24 hours or so. Obviously, there is some amount of variability in the interpretation of "typical" and "average".

In the past, the primary argument for requiring a moderately small packet size was so that the amount of wasted work could be minimized if a computer crashed while processing a given work unit. However, since the original release of the distributed.net clients, the automatic "checkpointing" feature has been introduced, allowing no more than approximately 10 minutes of computational work to be lost. Although checkpointing is not enabled by default, if you feel that your machine might be unstable and wish to accept the minor performance penalty that checkpointing incurs, it can be easily enabled.