[Sis-SCPS-INTEREST] New SCPS RI Release on Open Channel Software...

[Eric Travis]

On Thurs, Mar 16, 2006 at 04:54:PM -0500, Otto Solares wrote:

>Hmmm, the problem I see is that the process never block, I am not
>familiar with the source, but if you think we could make the process
>block by using blocking I/O I'll take a look and probably generate
>a patch.  Is there any reason why SPCP_RI doesn't use blocking I/O?
>My biggest gripe will be the rate control using blocking I/O.
>
The historical reason the RI doesn't use blocking I/O was
it was just much harder to implement than it was worth
(at least at that particular time).  The non-blocking I/O
is an unfortunate consequence of the overall design
constraints on the code from which the RI emerged.

But:

     The way to provide non-blocking I/O in the RI code
     is to split out the I/O operations (at the very least
     the input) into a separate execution thread from
     the rest of the proxy processing.

     This will allow for blocking reads in servicing arriving
     segments while not interfering with the heartbeat
     timer that supports both the per connection timers
     and token buckets.

If the core timer support code hasn't changed terribly much, 
the above is necessary but not sufficient for measurably
reducing the proxy's CPU utilization.  

You will still have a tight spin loop checking for expired
timers to service.

To realize a significant drop in CPU utilization what
you *really* want to change is the way the RI timer
mechanisms work.   There are a number of different
(but not necessarily portable) approachs once could
take.

The transition to non-blocking I/O could be performed
in serial or parallel with replacing the RI timer mechanism.


It's a bit late in the current academic term, but
refactoring the RI code could be an excellent learning
experience for anyone seeking a challenging coding
project.


Eric