[RC5] Request for FIFO

Mikus Grinbergs mikus at bga.com
Tue Jan 9 13:10:05 EST 2001

The machine on which I run OGR is off-line, and I have to
"schedule" forming a link for it to access distributed.net.
My "schedule" was derailed when the units of work I was
assigned on a particular download turned out to require only
ONE TENTH the time to process than the units I normally get.

The problem is *timing* the download from distributed.net so
that my machine has not yet run out of work, but does not have
un-processed old work in its input queue when new work refills
that input queue.  [If there *is* old work sitting at the bottom
of the input queue, &deity only knows when it will be processed.]

My problem could be solved if there was a way for the dnetc
program to finish-up the previously-fetched work and only then
start on the newly-fetched work.  Here is a proposal I have made
before; I believe it would be relatively *easy* to implement:

  -  Have TWO input queues !!     (Call them QA and QB)
     And have the dnetc program load the next unit of work
     from whichever queue it loaded the previous unit from

  -  When dnetc attempts to load from QA and there is no
     more work in QA, have dnetc test QB - and switch to
     loading from QB if QB is not empty

  -  When dnetc attempts to load from QB and there is no
     more work in QB, have dnetc unconditionally switch to
     loading from QA

  -  Add a parameter to the 'fetch work' option, so that the
     user can optionally specify whether new work from
     distributed.net should be placed to QB instead of to QA

  -  [There is no need to change the existing LIFO logic in
      the dnetc program, since the user who wants to control
      queueing will allow the *current* queue to be emptied;
      meanwhile he can bring subsequent work into the *other*
      input queue ! ]


To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list