NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/sgi/18394

Internet Message Format | 1992-12-31 | 5.4 KB

Path: sparky!uunet!spool.mu.edu!olivea!charnel!sifon!CC.UMontreal.CA!basque
From: [e-mail] (Basque Guy)
Newsgroups: comp.sys.sgi
Subject: Re: ZModem
Message-ID: <[e-mail]>
Date: 31 Dec 92 07:39:41 GMT
References: <[e-mail]>
Sender: [e-mail] (Administration de Cnews)
Organization: Universite de Montreal
Lines: 102

[e-mail] (Soubyran Richard) writes:

| Hello sgiers!
|
| I have avery weird problem... When I am using zmodem (sz) to
| transfer files between my Mac and the Indigo, the transfer hangs
| and quit when there is only 6 seconds left in the transfer. This
| problem exist only since we have changed the OS last summer. We
| were running version 3 of IRIX back then. a few weeks ago, we
| changed to IRIX 4.0.5 and now the transfer hangs just at 3 seconds
| from the end... That's VERY strange...
|
| Before upgrading to IRIX 3 something, everything was fine! When I
| use Kermit, no problems at all... The tech support at our
| university is no good at all...
|
|     "We don't know what's wrong."
|     "We do not have that problem here in the office"
|     etc
|
| is all they can say.
|
| One more thing... this problem occurs only if the file is big
| enough to make the transfer go over 60 seconds. Any file less than
| that... no problems...
|
| Please help!
|
| Richard Soubyran
| [e-mail]


I'm sorry to have to waste network bandwidth to straighten out the facts,
but your message has been published in four different "comp.sys.sgi"
groups and it brings prejudice to my colleagues, to the Universite de
Montreal, and to a certain extent to SGI also.  I'm not here to air
my grievances but to bring factual information about the ZModem
problem and to help other users to better understand the situation.

This problem is well known, it has been described many times in the
different news groups, and it affects all the file transfers that are
made through a terminal server or across high speed modems.  The reason
is very simple, the ZModem protocol is a streaming protocol and its
design is based on the assumption that there is no buffering of information
between the transmitter and the receiver.  Now, this is no longer
true when there is terminal server, or a pair of error correcting modems
in the transmission path.

What happens is this.  The computer throw information at very high speed
into the terminal server which has a high buffering capacity, and a lot
of information will accumulate there because the telephone line is very
slow compared to the network.  In a relatively short time, the receiving
end of the protocol will find itself many thousands bytes behind the
transmitting part of the protocol, and the problem is compounded when
error correcting modems are being used since they also have some buffer
capacity.

If there is no transmission error, or if the file is small, everything
will run OK.  But if there is an error, the receiving end of the protocol
will ask for a retransmission.  And the ansmer can come only after the
receiving end will have swallow all the information that has accumulated
in the transmission path.  If there is too much information to swallow,
the receiving end will declare a time out depending on its internal
settings.  The same problem will happen at the end of the transmission
if there were no error since an acknowledge has to be given there.

Do we have this problem only on the SGI?  Obviously NO!  It can happen
on any epuipment made by any supplier: we've experienced the problem
on SUN, APOLLO equipement, you name it!  Does the problem prevent our users
from using ZModem?  Again the answer is NO!  We've documented the problem
a year ago and a lot of our users still prefer this protocol because it's
faster, even though, from time to time, they may have to start over again,
but that's their choice because they can also use XModem, YModem or KERMIT.

What is the solution?  Very simple, it's written in the "man sz": they
use the "-w" parameter on the "sz" command.  For those who have modems
running at 2400 bps, we recommend "-w 1024".  Those with V32bis modems
may use a value between 2048 and 8192.  Curiously enough, and this proves
my point, the problem never happens in the other direction.

I may be wrong, but I see nothing that SGI can do to correct this problem.
This is not THEIR problem but a problem created by a conjuncture of
specifications that have not been designed to work together.  The only
proper solution to eliminate the problem would be to install the modems
directly on asynchronous ports on each computer, and probably also to
avoid using error correcting modems, two things that would be almost
impossible these days.  How can we imagine installing modems on over
one thousand workstations when a central pool of 60 modems is adequate
for all.

Next time you post in this group, you should better check with our
people at the Computing Services.  They're not as ignorant as you may
think.  Regarding me personally, I'll let the readers of this group
appreciate by themselves if I'm so ignorant.  As for this article,
I have chosen to publish it only once in this group, I want to spare
the readers having to read it three more times. One is enough, and
I had more useful things to speak about than you.

--
Guy Basque  Directeur technique __ | INTERNET: [e-mail]
_/_/_/_/_/  Services informatiques | BITNET:__ basque@umtlvr  _/_/_/_/
_/_/_/_/_/  UNIVERSITE de MONTREAL | TEL: ____ [phone] _/_/_/_/