Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!amdcad!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: net.news,net.unix
Subject: Re: Network differences
Message-ID: <7018@amdcad.UUCP>
Date: Sun, 1-Dec-85 16:50:55 EST
Article-I.D.: amdcad.7018
Posted: Sun Dec  1 16:50:55 1985
Date-Received: Mon, 2-Dec-85 03:45:30 EST
References: <2301@sdcc6.UUCP> <9079@ritcv.UUCP> <817@ecsvax.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Distribution: net
Organization: AMD, Sunnyvale, California
Lines: 26
Xref: watmath net.news:4454 net.unix:6480

In article <817@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes:
>> BITNET uses leased lines, but I don't know what hardware is neccesary.
>> Because it has leased lines, communication between any two nodes is
>> (nearly) instantaneous, or more accurately, you seldom have to wait more
>
>  A comment on performance - it certainly can be this good when there is
>little traffic.  However the delay can be *much* more than seconds-minutes
>for a file transfer when there are many other files ahead of you.  (I think
>that short e-mail messages are given priority over large files, so that
>message transfer does work very well in practice.)

If BITNET uses the RSCS stuff, I believe it has the characteristic of
transfering only one file over one physical link at a time so that if
your e-mail message gets stuck behind a huge 20 Mb file transfer in
progress the short msg has to wait for the long file to finish.

Transferring short msgs before long msgs are one reason USENET
articles can arrive out of sequence. (totally unrelated to the
previous paragraph, just something I thought I'd toss in)

-- 
 There's nothing I hate more than sorting socks.

 Phil Ngai +1 408 749-5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com