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

[Feighery, Patrick D.]

Some quick comments.

As Eric indicated, there are certainly many ways to do it right.
Initially, I was trying to figure out a way for SCPS to not consume all
of the CPU resources during an 'idle' state.  I was looking at the
"least amount of effort for the great bang" approach.  For those who
are really interested, you can diff the two source code versions to see
what I did...

Essentially there are three things that can cause the SCPS Gateway to
do things.

1) Receiving a packet from a physical interface obviously needs to be
processed as soon as possible.

2) Processing of this received packet, may result in something else
that needs to occur.  For example, opening up window space on the WAN
connection allows the corresponding LAN connection to perform some
functionality.
 	 
3) Finally, processing an expired timer as soon an reasonably possible.
Note that there are two types of timers.  Those that must be processed
immediately and those that can be processed at the next convenient
moment. Timers and timing functionality is based on SIGALRM firing off
every 10 msec..

I'm sure there are different ways to make sure the cpu is not tasked
until one of these events occur.

Hope this clarifies/helps explain what I did and why I did it.

Best Regards

	Pat




>>-----Original Message-----
>>From: sis-scps-interest-bounces at mailman.ccsds.org 
>>[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On 
>>Behalf Of Eric Travis
>>Sent: Thursday, March 16, 2006 10:01 PM
>>To: sis-scps-interest at mailman.ccsds.org
>>Subject: [Sis-SCPS-INTEREST] New SCPS RI Release on Open 
>>Channel Software...
>>
>>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
>>
>>
>>
>>_______________________________________________
>>Sis-SCPS-INTEREST mailing list
>>Sis-SCPS-INTEREST at mailman.ccsds.org
>>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest
>>