Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!GATEWAY.MITRE.ORG!rcoltun
From: rcoltun@GATEWAY.MITRE.ORG (Robert Coltun)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PSN 7 End-to-End question.
Message-ID: <8802052018.AA28112@gateway.mitre.org>
Date: 5 Feb 88 20:18:28 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30


   We have a version of ping that transmits packets based on the ARPANET
1822 interface considerations: number of outstanding rfnms for the
destination and the total in the output queue.  Ping (in its original
form) is excellent for looking at IP delays but it is difficult to get
to actual throughput using it. With the interface scanner, which is based
on netstat -h, we can send packets out as fast as the net can take them;
the transmitter can be throttled by a rfnm high-water mark and a high-water
mark of total packets in the output queue. 
	 Our definition of throughput is:
	   total # bits sent/(time of last received - time of first received)

   Our previous delay tests showed delay and variance of delays increasing
as the number of PSN hops increase. We tried the new tests for 3, 4, and
5 (minimum) PSN hops sending bursts of 30 512 byte packets out.

   The results of these test are preliminary and much work is still
need to draw any real conclusions. The results of the 3 hop case ranged
from 35Kb to 16Kb averaging around 23Kb. A rfnm high-water mark of <= 2
seemed to give us the best throughput values as well as the lowest rtt 
delays for this case. The 4 hop case worked well with a 2 rfnm high-water
mark (best throughput was around 28Kb); 5 PSN hop case worked well with a
5 rfnm high-water mark (best throughput was around 22KB).

    I too have seen low FTP transmission times. If these tests are
an indication of subnet throughput, where has all the throughput gone? 

--- Rob Coltun
    The MITRE Corporation
    rcoltun@gateway.mitre.org