j-zbiciak1 at ti.com
Mon Jul 20 11:00:38 EDT 1998
'David Taylor' said previously:
| I may be missing something here, but I honestly don't get the point of
| having a preferedblocksize entry...
Agreed, it doesn't seem that useful if you implement buffers that
are gauged on total workload buffered, *and* implement a mode where
the client splits larger blocks into smaller blocks on request.
Here are some reasons, though, why the preferred blocksize might still
-- Older machines (386, 486 class) take a looong time to crack a block.
So, it makes sense to feed these machines work in smaller pieces.
-- Some networked machines cannot run with checkpoint files because the
continual, miniscule updates create too much network traffic. These
machines should work on smaller blocks to minimize the amount of work
potentially lost if the machine/network crashes.
I too would vote for always issuing and buffering the largest-available
blocks, and then allowing the client to break up larger blocks into
smaller blocks if it so desires. In addition, I would recommend
setting the buffer thresholds in terms of the smallest granularity of
work for a given project. The combination of these two features would
combine the best elements of both larger and smaller blocksizes, IMHO.
+------- Joseph Zbiciak ------+
|- - - j-zbiciak1 at ti.com - - -| "The truth of a proposition has nothing
| -Texas Instruments, Dallas- | to do with its credibility.
|- - #include <disclaim.h> - -| And vice versa." -- Lazarus Long
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5