[Sis-SCPS-INTEREST] SCPS data rate anomalies: please explain??

Fri May 5 15:44:50 EDT 2006

No vice versa, you need to TUN info instead

Comment out all of the TAP references.  Add the following.

AIF_TUN_NAME tun0
BIF_TUN_NAME tun1
C_TUN_NAME    tun2

Also SCPS in tun mode does not make any assumptions on the link layer
used to go over the RF  You need to account for that yourself in the
value of BIF_RATE  In your case can you describe what is actually going
of the RF.

    Pat

________________________________

From: Dan Miller [mailto:dan at anacominc.com] 
Sent: Friday, May 05, 2006 3:28 PM
To: Feighery, Patrick D.
Cc: SCPS mailing list
Subject: Re: [Sis-SCPS-INTEREST] SCPS data rate anomalies: please
explain??

	Ummm... I'm using a TUN scps driver, not TAP... do I still need
the TAP info??

	Dan

	Feighery, Patrick D. wrote: 

		>From your description, obtaining 85+ percent of the
bandwidth, assuming
		all of the bandwidth is dedicated to you, should be
quite possible.

		First let's talk about bandwidth.

		If you are using pure rate control over the WAN
environment (which you
		are) then the rate control parameter BIF_RATE contains
the rate which
		SCPS will try and push out date over the interface.
This assumes it has
		data to be send and buffer sizes do not further
constrains data flow.
		Therefore in each of your examples you are overdriving
the link.  Also
		be aware that SCPS in TAP mode makes the assumption
(good or bad) that
		ethernet frames will be the data link layer.  I've also
make the
		assumption that the pre-amble is not going over the RF.
Therefore we
		can probably set the rate control to 3 Mbps

		Now for buffer sizes.

		In general you need to set the buffer sized to 1 to 2
times the
		bandwidth delay product.  Lets assume bandwidth is 3
Mbps and RTT delay
		is 550 msec, therefore buffer sizes on the WAN side
should be at least
		206250 bytes and probably no more that 412500 bytes.
For a first try
		use 412500 bytes.

		Now I am looking at you rfile and, well that is exactly
what you
		have.... However you have commented out AIF_TAP_NAME
AND BIF_TAP_NAME.
		They are required and used for internal scps
processing. Uncomment-out
		those and you should get what you are expecting.   Let
me know....

			Pat

				-----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: Friday, May 05, 2006 1:53 PM
				To: SCPS mailing list
				Subject: [Sis-SCPS-INTEREST] SCPS data
rate anomalies: please 
				explain??

				Okay, now that I've gotten rid of the
collisions, I can finally start

				evaluating this system.  I'm seeing
several odd things that 
				I'm hoping 
				someone can clarify for me.  I started
out with the rfile that I'll 
				include at the end of this message.

				My satellite connection is 3072000
bits/second in each direction. 
				I have 550 msec RT delay (via an
external hardware satellite 
				simulator).
				Theoretical max thruput thus is
384KB/sec (assuming no data

		overhead).

				My target thruput is roughly 85%
(~330KB/sec) based on past 
				experience 
				with other systems.

				So originally I configured both
gateways as shown below.  However, I 
				wasn't seeing what I expected to see:

				   * My data throughput with these
settings was very low
				   * Consistency is terrible!!  Data
rates not only are low, 
				they vary
				     all over the place

				I base my expectations on two measures:

				1. What do I see with the same
hardware, no tcp acceleration, 
				and no RT 
				delay.  This gives me a measure of the
capabilities of the linux 
				drivers, our drivers, and our hardware.
				2. We previously used a proprietary tcp
acceleration package which we

				are trying to get away from. 

				In both of these cases we see very high
consistency; basically, 
				variations in data rate are in the
third significant digit 
				across many 
				runs.  Case 1 gives over 88% Max, case
2 gives 82% to 88% 
				depending on 
				configuration, but any given
configuration is very consistent.

				Anyway, to try to improve my
throughput, I've been playing 
				with BIF_RATE 
				and BIF_BUF;
				(all thruputs in KBytes/second)

				BIF_RATE      BIF_BUF      min thruput
max thruput
				========      ========      ========
=========
				4096000         422400            170
230
				8000000         600000            270
320
				8000000         800000            290
340

				I had tried some intermediate rates and
buffer sizes that I don't 
				remember numbers for, but they were in
between the results I 
				show here.  
				You can see that with my current
settings I'm getting up to the rates

				that I'm expecting, but the variation
suggests to me that I 
				still have 
				something wrong.  Also, the
rate/buffers that I'm specifying 
				have *no* 
				correlation to real data, which is a
problem if I need to 
				configure for 
				different settings...

				Can anyone shed light on any of this??

				Dan Miller

				# GW Resource File - comments are
allowed, starting with '#'.
				#    Comments can be anywhere EXCEPT
between parameter values.

				# interface A info
				AIF_NAME    eth0
				AIF_RATE    100000000
				AIF_BUF        32768
				AIF_CC        1
				AIF_TCPONLY    1
				AIF_MTU     1500
				#AIF_TAP_NAME    tap0

				# interface B info
				BIF_NAME     eth1
				BIF_RATE     3072000
				BIF_BUF     422400
				BIF_CC         0
				BIF_MINRTO     600000
				#BIF_TAP_NAME    tap1

				# IPFW info
				C_DIVPORT    52000     
				C_TAP_REMOTE_ACCESS 1

_______________________________________________
				Sis-SCPS-INTEREST mailing list
				Sis-SCPS-INTEREST at mailman.ccsds.org

http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-scps-interest/attachments/20060505/2af378a7/attachment.html