Re: [NETSIG:385] Re: Subnet networking

[Klarsen <k5di@kazak.nmsu.edu>]

On Thu, 1 Dec 1994 fuseki!mtewe!vodall@hprwp.fc.hp.com wrote:

> > 
> > 	we have run tests of the path through a single simplex 
> > netrom node and then through the same node using the X1J TCP system. We 
> > tested it using the ftp of a large file. The average data transfer rate 
> > for the netrom was 14 byte/sec. The average rate using tcp was 32 
> > byte/sec.
> 
> Finally....   Real numbers and real data to compare with.  It's something
> we seldom see in packet work.  Must be because it's normally too
> depressing.
> 
> A big question here is: 
> 
>      Can the two systems exchanging data hear each other directly????

	No, in fact the path length was 150 miles total airline distance.


> 
> If not, then have you ever had trouble with the IP collisions between
> packets once the CWINDOW gets larger than MSS.  In my situation, the
> returning IP ACK from the receiving system collides with the second
> data packet from the transmitting system causing both systems to time out
> and retry - thus killing throughput in a big way.

	We had collisions or something, and nos would just quit. For like 
15-30 minutes before the ftp would again start. Bill I think found that 
problem which was the "tcp timeout" command. We looked it up and it 
defaults to NO timeout!! So we made this function 30 seconds and that 
solved most of the problem! Then we found another function I forget which 
that we changed and got better performance. We learned you need to make 
these changes BEFORE you do any attach statement or nos will still use 
defaults! This I am sure has driven me and other hams up the wall!

	It DOES matter when you make changes to nos...



  The current HACK is
> to force CWINDOW to never exceed one packet.  Slows the transfers down
> on longer hops but keeps the local traffic going a little faster.
> 
> When the 145.010 node is quiet and not desensing us - we sometimes get
> peaks in the 15 c.p.s. range.  Usually it's around 7.  :-(
> 

	Before we fixed things 3-5 were "GOOD"   :-(


> Part of our slow speed comes from using a MTU of 168 instead of 256.
> That's another hack to reduce the long packets which are a little
> more prone to dropping bits and a lot more prone to collisions.

	We use mtu=230 when working thru netrom and I think now that we 
use 1024 when using tcp and the X1J (I think 1024 is the biggest you can 
set) Also, I have NEVER dropped a bit due to a collision...it just slows 
down things a lot!

  Some
> day we'll get the backbone free of hidden transmitters and be able to
> take advantage of the 1024 mtu limit of X1J's...
> 
> Due to the hidden transmitters and desense we use Virtual Circuit
> mode on the uplink and Datagram on the downlink.
> 
	We are sticking with Data Gram or DG. No good reason.

> Other longer paths I have experience with using a combination of
> IP on X1J's, UHF non-dedicated links and 145.010 "zoo" channels
> give throughput in the 1 to 3 c.p.s. range.
> 
> I've never had the opportunity to see what the best possible is with
> 1200 baud packet on a clear channel.  Or with 1K or bigger MTU packets?
> Does anybody have some numbers to share?
> 
	That is what I reported on, 1200 baud clear channel.


> I do know that after watching the performance of Calgary's Digital
> Packet repeater for hours at a time - I want one...  I'm expecting
> it would be a 10x improvement.

	So I will send this both to the tcp-digest and this sig Bill 
since the subject is nos and X1J stuff.

73, karl k5di