[Sis-SCPS-INTEREST] SCPS Gateway - Memory usage

Eric Travis travis at globalprotocols.com
Thu Dec 1 13:00:12 EST 2005


Walid,

My response is from a historic perspective based upon the code that fed into
the SCPS-TP Reference Implementation (this goes back more than a decade 
old)
so the specifics have likely been overtaken by development/improvements on
the SCPS-TP Reference Imp that have happened in the years since...

>Can any of you SCPS gurus shed some light as to why it might be using this much memory, just for running the Gateway with no connections being established?
>Furthermore, the CPU usage is also very high using up 99.6% of the CPU.
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 3548 root      25   0  4136 2840  616 S 99.6  1.2   3:47.13 gateway
>
>Would the CPU problem be due to some polling, running the gateway in user space mode or any other ideas?
>We're thinking that the memory usage and/or the CPU may be specific to your implementation and not to the SCPS algorithms.
>

Both of the above are design artifacts stemming from the need of the
original SCPS-TP/NP/SP implementations (the basis of the current
Reference Imp) to self-host on the target spacecraft platform.  A very
rudimentary operating system in a very short time and chunks of it
never went away.

  o  The high CPU utilization is the result of the polling mechanism the
     TCP implementation used for servicing its virtual clock (timers) and
     network interfaces.  The polling mechanisms are always running - even
     if there is no traffic or timers to service.

The CPU utilization is actually fairly plastic, while it does soaks up
any otherwise unused cycles on the processor, it doesn't prevent you
from doing meaningful things with the host system while the SCPS-TP
implementation is operating. 

You can reduce the CPU load to virtually nothing (even under heavy load)
by converting the code to an event driven architecture, but it probably
isn't worth the effort for your purposes.


  o  The memory utilization is likely due to a preallocation of *all* data
     structures into resource pools during system initialization.  This
     was to avoid the need to call malloc/free (both expensive operations)
     during periods of high-activity and to avoid memory fragmentation
     from the same.

You can likely reduce the memory requirements simply by reducing
the size of the resource pools in the source. Grep in the source for
mallocs that reference things in ALL CAPITAL LETTERS referring to
things like "maximum sockets", "maximum mbuffs" and "maximum clusters"


The memory and CPU utilization (of just about any transport protocol)
are artifacts of the implementation rather than the algorithms themselves. 
The only thing that makes a SCPS-TP implementation slightly more 
"interesting"
than any other TCP implementation is dealing with the rate-pacing 
capability.

Hope this helps,

Regards,

Eric





More information about the Sis-SCPS-INTEREST mailing list