bill@carpet.WLK.COM (Bill Kennedy) (07/15/88)
Some time ago I posted an inquiry regarding why the send and receive
times were so different between my 12MHz '286 V/AT system and 16MHz
'386 AT&T 386 UNIX system. First off let me thank everyone who
replied. The best suggestions (get a smart serial card) I couldn't
use because I have the internal version of the Trailblazer but I still
might get one of those new fangled National chips with the FIFO's in
it. Here is a summary of the replies.
-----------------------------------------------------------------------
From: uunet!tis.llnl.gov!ames!telebit!rls
Date: Fri Jul 8 08:36:37 1988
Yes you may want to turn off compression. It can cost up to 10-20% in terms of
throughput. Another reason for the speed asymmetry that you're seeing may be
the disk write time of the luggable (carpet?) machine. I would suggest trying
a direct link between the machines (a hardwired RS-232 link) running at 9600
to see what the limiting factor is. You can also investigate this by watching
the modem SD/RD lights and the disk access lights on each machine. It may
give you some clues.
Good luck!
Regards,
=============================================================================
Richard Siegel Phone: (415) 969-3800
Product Manager UUCP: {sun,uunet,ames,hoptoad}!telebit!rls
Telebit Corporation ARPA: telebit!rls@ames.ARPA
"We are, after all, professionals"...HST
=============================================================================
[ I defeated compression and it helped a lot! ]
------------------------------------------------------------------------------
From uucp Fri Jul 8 19:30 CDT 1988
Date: Fri, 8 Jul 88 10:07:34 PDT
From: ames!vsi1!lmb (Larry Blair)
Your problems here are twofold. First, xmit figures are worthless,
particularly for small files. The reason is that the time stats from
uucp for xmit run from start-of-xmit to end-of-xmit of the last block,
not waiting for the receiving system's "CY". Given the buffering in
the 'blazer, the time is not real. For receive, the buffering doesn't
reduce the time, so those figures are fairly accurate. I would strongly
suspect that the low speed is related to slow disks and a large amount
of overhead in creating files. I didn't notice what version of Unix you
are running on your portable, but if it's an older SYS V, and the size
of your core isn't very big, the overhead can be very large.
Btw, the 'blazer's compression is only 12 bits. You can certainly increase
your effective throughput by compressing before transmission. Even if
your PCs can only do 12 bit, studies have shown that compressing on the
host is a win.
* * * O Larry Blair altnet----\
* * * O VICOM Systems Inc. pyramid!---\
* * * O 2520 Junction Ave. uunet!ubvax!vsi1!lmb
* * * O San Jose, CA 95134 ames!------/
* * * O +1-408-432-8660 sun!------/
------------------------------------------------------------------------
Date: Fri, 8 Jul 88 18:10:54 CDT
From: james@bigtex.UUCP (James Van Artsdalen)
Your TB+ buffers something like 30K of data internally. When you send
a file, you start talking to the TB+ full speed, whatever the speed of
the underlying link. When your uucico has "finished" sending out the
file, it's really only finished sending to your TB+: the file hasn't
necessarily all been sent to the remote machine, and not even
necessarily from the remote TB+ to the remote uucico (there is a large
receive buffer also).
uucico has a very large overhead per transaction, and there are two
transactions per mail message. Indeed these delays are quite a bit
bigger than the time required to send many smaller mail messages. I
would just plain ignore any claimed uucico statistics for anything
less than 50K, but not only is uucico very inaccurate (1 sec accuracy,
which could be 1K of data!), but the buffering makes hash of analysis
too.
--
James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
-----------------------------------------------------------------------------
Date: 9 Jul 88 00:30:17 EDT (Sat)
From: charles@c3engr.UUCP (Charles Green)
Have you noticed the modem throughput via the TD/RD lights as you send and
receive? Offhand, I'd guess your 286 box just can't eat characters coming
in that fast, and that you're seeing your RD light flicker off and on as
the handshaking at your end slows things down.
----------------------------------------------------------------------------
Date: Fri Jul 8 21:27:18 1988
From: karl@ddsw1.UUCP (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
In article <115@carpet.WLK.COM> you write:
[ my stuff deleted ]
Well, the '286 systems don't do so good -- we have a Usenet neighbor with
one and can never hit more than about 6kbaud with him (this is Microport
more than anything else)...
On the other hand, I regularly receive and transmit at 1100cps with other
sites (!).
First, turn off the compress, especially if you're using compressed news
batches. It doesn't help, and frequently hurts.
Next, if you have a dumb sio board in the Uport/286 box, get a smart card.
Third, find out how fast/slow your disk drives are. If they're really slow,
you're gonna be sitting while the machine finds (stores) the next file....
and throughput drops.
Your differences should greatly diminish....
--
Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc. "Quality solutions at a fair price"
---------------------------------------------------------------------------
Going through the file of responses I see that I had some things in there
that weren't responses (which I omitted from the summary) and I see that
all of the responses didn't get into the file, so apologies to those I
missed and many many thanks to all who replied.
--
Bill Kennedy Internet: bill@ssbn.WLK.COM
Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill