[Sis-SCPS-INTEREST] Re: SCPS data rate anomalies: WOOPS!!

[Dan Miller]

I'll be *happy* to try this out for you (well, for ALL of us, actually).

I was just preparing a follow-up post on my research here; when I 
stopped my carrier-acquisition process (by putting a signal into the 
idle receivers), I *did* in fact start getting full throughput on the 
system, so clearly the competition between my sweep function and scps 
was causing the problem.  This would cause a major problem for us 
because one of our normal modes of operation has several channels 
unlocked, so sweep is always running on them.

I will rebuild with -low_idle=yes and see what happens; I'll report back 
here in a day or so...

Dan

Feighery, Patrick D. wrote:
> Dan admittedly I have not gone through your traces, however if you
> think you are CPU bound then the latest version of the gateway has a
> compile time option that __may__ help you out.  The following is an
> except from a previous posting on the list.
>
> If you have a moment can you try them.  I'm was looking for a poster
> child and well...  I may have found one.
>
> 	Pat
>
>
> ===========
> 	2)  While we are on the subject of rate control and CPU
> resources.  As I'm sure you all are aware of, the SCPS process tends to
> be a CPU hog - to put it mildly...  This was intentional, because the
> SCPS RI constantly polls the internal sockets to read packets from the
> kernel as soon as possible. This unfortunately means the SCPS reference
> implementation will consume all available CPU resources that it can.
> This can have some adverse interactions with other processes trying to
> consume the CPU's resources.  Now given this, I have added two
> compilation flags that can be used to alleviate this issue.  The
> configuration option -low_idle=yes will keep the RI from consuming CPU
> resources during periods of idle traffic.  The configuration option
> -low_cpu=yes can also be included to further reduce CPU resources when
> traffic is being processed.  If the -low_cpu option is included then
> the -low_idle option must also be include.  The next big question is
> "Does this affect performance?"  The real answer is.. maybe and it
> depends on the horsepower of the CPU and the data rates involved.  If
> data rates are under 10 Mbps, you should be completely safe.  Try it
> and see what happens.  Let me know if there are any issues.
> ===========
>
>
>   
>>> -----Original Message-----
>>> From: sis-scps-interest-bounces at mailman.ccsds.org 
>>> [mailto:sis-scps-interest-bounces at mailman.ccsds.org] On 
>>> Behalf Of Dan Miller
>>> Sent: Monday, May 08, 2006 1:21 PM
>>> To: Eric Travis
>>> Cc: sis-scps-interest at mailman.ccsds.org
>>> Subject: Re: [Sis-SCPS-INTEREST] Re: SCPS data rate anomalies:
>>>       
> WOOPS!!
>   
>>> Hi Eric, and everyone else!!
>>>
>>> I suspect that this is what my problem is (other processes competing 
>>> with the ri for CPU cycles)...  We have another process running 
>>> (actually, two different threads of the same task) on our 
>>> system; this 
>>> process runs in user space (unfortunately) and interacts with 
>>> our driver 
>>> to make sure the cards are in lock; it performs carrier 
>>> acquisition and 
>>> tracking, and contains alot of floating-point computations 
>>> (which is why 
>>> it's not in the kernel).  The process is mostly idle if the receivers
>>>       
>
>   
>>> are all locked, but in my current system I have a second, unused 
>>> receiver which is *not* locked, so its thread is continually running,
>>>       
>
>   
>>> sweeping the appropriate frequency range looking for a 
>>> carrier that it 
>>> won't find.
>>>
>>> I'm going to do some hacking today to see if I can get my processes 
>>> idle, and see how scps runs... I'll post status later once I know 
>>> something more.
>>>
>>> Dan
>>>
>>> P.S.
>>> I apologize for the occasional html message posted here... I 
>>> intentionally use html for my email usually, this list is the 
>>> only place 
>>> where I need to kill it, so I have to do so on a message-by-message 
>>> basis, and I occasionally forget!!  I'll try to be more dilligent...
>>>
>>> Eric Travis wrote:
>>>       
>>>> Dan Miller wrote:
>>>>   
>>>>         
>>>>> One thing I noticed on the real eth1 remote dump is that the time
>>>>> between outgoing packets is varying between <1 msec to as 
>>>>>           
>>> much as 10.8
>>>       
>>>>> msec... I would have thought packets would be metered out more
>>>>> consistently than that; Is this something I should expect to see??
>>>>>     
>>>>>           
>>>> I think what you are seeing is the granularity of the RIs 
>>>>         
>>> token bucket
>>>       
>>>> mechanism.  If I recall correctly,
>>>> the credit is refreshed approximately every 10ms.  So if you are
>>>> targeting a 3Mbps rate, you get credit for
>>>> 3750 bytes (2.5 full sized ethernet frames) every 10ms.  
>>>>         
>>> This leads to
>>>       
>>>> the pattern  you see:
>>>>     2 full sized frames, ~10ms gap, 3 full sized frames, 
>>>>         
>>> ~10ms gap, etc.
>>>       
>>>> Regarding the inconsistent performance results you are seeing:
>>>>
>>>> In an earlier message you related:
>>>>   
>>>>         
>>>>> However, we run these gateways in runmode 3 (no X 
>>>>>           
>>> interface) because
>>>       
>>>>> are machines are rather slow (850Mhz Celeron), and a busy
>>>>>           
> satellite
>   
>>>>> gateway uses alot of memory.
>>>>>     
>>>>>           
>>>> Is the hosted SCPS RI code competing with something else 
>>>>         
>>> for CPU cycles? 
>>>       
>>>> The polling behavior makes the RI a sponge for otherwise 
>>>>         
>>> idle CPU cycles
>>>       
>>>> - and
>>>> therefore a huge target for being bumped from a busy run 
>>>>         
>>> queue.  If you are
>>>       
>>>> attempting to embed the RI on a system already hosting 
>>>>         
>>> something that
>>>       
>>>> may be
>>>> resource intensive, you may have the root cause of the inconsistent
>>>> performance
>>>> you see.
>>>>
>>>> Left on its own, the RI code can run very fast, but from my 
>>>>         
>>> memory it
>>>       
>>>> could get
>>>> pretty unhappy if it had to compete with another processor/resource
>>>> intensive
>>>> application.
>>>>
>>>> Eric
>>>>
>>>>  
>>>>
>>>>   
>>>>         
>>> _______________________________________________
>>> Sis-SCPS-INTEREST mailing list
>>> Sis-SCPS-INTEREST at mailman.ccsds.org
>>> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest
>>>
>>>       
>
>