Protocol Shootout Results
Chuck Forsberg WA7KGX
submitted to comp.protocols.kermit. Columbia University acknowledged
receipt of this report but has not chosen to release it to the newsgroup
they control, so here it is.
The TRUTH about KERMIT NEWS
- or -
What Columbia University doesn't
know about File Transfers
may surprise you!
Last July Columbia University used its non-profit mail permit to
distribute thousands of copies of Kermit News Number 5. This
issue starts with an announcement that Columbia now accepts
Credit Card orders. Under the heading "Kermit Saves You Money"
Columbia invites businesses to switch from other vendors'
shareware and commercial hardware to their product. Using
a non profit mail permit to distribute this advertising gives
Columbia a crucial advantage over tax paying competitors.
I particularly object to Columbia's publishing incorrect and
misleading information about the performance of file transfer
software. That Columbia does so at public expense is an added
irritant.
In "The Truth about Kermit File Transfer Performance" tenured
Columbia University professor Frank da Cruz proudly announces
that Kermit "outperforms X-, Y-, and ZMODEM protocol transfers
every time." (Kermit News July 1993 p.14) To lend credence to
this incredible assertion, Frank includes results of so-called
"True-Life Benchmarks".
Frank's benchmarks and interpretation leave much to be desired.
It is not my intention to defend a competitor's product. But,
the reported Kermit efficiency of Procomm Plus (93%) and Zstem
(97%) are very close to that of Columbia's own MSKermit (99%).
Frank's 104% figure for MSKermit is misleading because the
reduced control character prefixing responsible for the MSKermit
speedup also works sending to Procomm Plus. Columbia does not
disclose this inconvenient result. In fact, C-Kermit sending to
Procomm Plus transferred some of Columbia's test files in less
time than the C-Kermit-MSKermit combination required.
After shading the truth about competitors' Kermit downloading
performance, Frank's paper proceeds to redefine the YMODEM
protocol I developed in the 1980's. YMODEM is a batch protocol
based on XMODEM that uses 128 or 1024 byte data blocks. The
sz/sx/sb 3.24 Program that Columbia used for its "tests" also
supports YMODEM-g, a high speed streaming version of YMODEM.
All of this is explained in the sz documentation, yet the
protocol experts at Columbia University were clueless as to the
actual performance potential of the sz 3.24 software they used
for their True-Life Benchmarks.
Thanks to Columbia's ignorance of file transfer protocols I
don't know what protocol they actually used for the "XMODEM" and
"YMODEM" tests listed in Columbia's True-Life Benchmarks. But
Columbia's published numbers reveal a seriously slovenly
experimental procedure. XMODEM and ZMODEM in all their forms
transmit file data verbatim, without any prefixing. As a
result, data patterns have no effect on X/YMODEM throughput.
(Insert Chart 1, ys.gif, "Throughput vs File Size")
This is clearly shown the chart above, where true XMODEM/YMODEM
throughput is affected only by the file length. (Start-up time
is less important for longer files.)
(Insert Charts 2a and 2b, ks.gif and ks2.gif)
Compare this with Columbia's data. These variations, which are
not a function of file size, show an experimental error of more
than 20 per cent.
(Insert chart #3 fudge.gif)
In addition, Columbia Kermit programs significantly understate
the time required to perform a file transfer. Kermit reports a
file transfer took 112.98 seconds when in fact the machines were
tied up more than nine seconds longer. Professional-YAM's
ZMODEM self reported transfer time was much more accurate,
understating the actual time by less than .5 second. When this
issue was raised on the Usenet comp.dcom.modems newsgroup, the
frogheads suggested we ignore this Kermit overhead. To avoid
such bias, the actual time should be measured with the Unix
"time" command and verified with a stopwatch.
One set of Columbia's measurements was so preposterous that I
simply couldn't resist having a bit of fun with it. We noticed
that cutting the communications speed from 19200 to 9600
actually increased the speed of a Columbia Kermit file transfer
from 2648 to 2736 characters per second. (p.13, Tables 2 and
5.) This is the moral equivalent of putting a 30 mph governor on
your car only to find highway travel is now quicker than when
you were pushing 60. When I announced the "Columbia Stochastic
Telepathic Kermit Hyperprotocol" to "explain" Columbia's numbers
the Kermit faithful quite lost their sense of humor. The
frogheads have flamed about tis "news release" but they have yet
to explain how Columbia came up with these crazy numbers.
And so we come to the The 1994 Protocol Shoot-out of Jan 6 1994
held at the Omen Technology World Corporate Headquarters.
Unlike Columbia's Kermit News True-Life Benchmarks, the
Shoot-out was held in public. Frank da Cruz was invited to
attend, to verify the honesty and competence of the tests. As
promised, we did not benchmark competitors' software while the
machine was overloaded with other work.
One of the tricks Columbia used to discredit ZMODEM in their
"True-Life Benchmarks" was to carefully select files with
redundant data that responds unusually well to Kermit's run
length compression while at the same time refusing to use ZMODEM
compression.
The most egregious instance of this deception is seen with
Columbia's selection of a Sun Sparc binary of the "uuencode"
program. This is a tiny program stored in a 24576 byte file.
All but a few thousand are nulls. Naturally this does wonders
for Kermit transfer speeds. Had Columbia's protocol boffins
read the sz 3.24 documentation they could have discovered that
ZMODEM compression does even better. Kermit gets 320 per cent
efficiency on this most extraordinary file; ZMODEM compression
gets an even better 363 per cent efficiency. A separate
compression program does even better at 646 per cent, twice as
good as Kermit.
Real world users download mostly compressed files, and here the
winner is YMODEM-g, closely followed by MobyTurbo(Tm) ZMODEM,
regular ZMODEM, with Kermit bringing up the rear.
(Insert Chart # gifspeed.gif)
So why is Kermit not the fastest when it only prefixes a few
control characters? The question is incorrect. Columbia claims
that only 0, 1, and 129 need to be prefixed, but this doesn't
work sending to MSKermit 3.11. The recommendations made by
Frank da Cruz do work:
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 1 13 129 141 ; For sending to MS-DOS Kermit
This makes C-Kermit prefix 8 characters, 0, 1, d, 7e, 81, 8d,
a3, and fe (hex). Knowing this, one can understand why YMODEM-g
is fastest since it does not prefix any control characters.
MobyTurbo(Tm) ZMODEM is next with one control character
prefixed, followed by standard ZMODEM which prefixes 5 control
characters (7 when dialing out). Kermit not only prefixes 8
characters, but suffers from the startup and shutdown delays
mentioned above.
The most impressive demonstration, and the likely reason Frank
da Cruz did not choose to appear at the Shootout, is Kermit's
performance in the noise test. Or, to be more precise, Kermit's
non-performance. In the Kermit News True-Life Benchmarks, Frank
da Cruz specified a window size of 5 and a packet length of
5000. Undoubtedly Frank chose this long packet length to
minimize Kermit's high per packet overhead compared to ZMODEM SUBpackets.
XMODEM, YMODEM and Kermit cannot resend a packet with a
different size. The problem is even worse with Kermit's
selective retransmission protocol. When we attempted to
replicate Columbia's 9600 bps plus noise test (Table 5) Kermit
failed every time. Well, almost every time. The first few
times Kermit worked, but that was only because C-Kermit quietly
refused to send the specified 5000 byte packets because a needed
"set buffer" command was not included. When Kermit actually
uses the specified 5000 byte packets with noise bursts at 2
second intervals, no data packets get through. Why? It takes 5
seconds to send a 5000 byte packet at 9600 bps but the specified
noise bursts come faster than that. Kermit croaks every time unless
the Jim Kirk Kobiashi Maru procedure is used (relax the test).
I made an informal survey of the guests at the shootout. As so
many have noted, line noise today manifests itself mostly in
disconnected calls. When this happens ZMODEM's Crash Recovery
is relevant, allowing the safe resumption of interrupted file
transfers. Since Kermit has no such feature Columbia chose not
to discuss this most vital of ZMODEM's many features.
What Columbia University's Kermit mavens don't know
about file transfer protocols may hurt you.
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304
Genie:CAF 17505-V NW Sauvie IS RD Portland OR 97231
--
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304
Clarence Dold
: Here is the report on the Jan 6 Protoocl Shootout. This report was
: submitted to comp.protocols.kermit. Columbia University acknowledged
: receipt of this report but has not chosen to release it to the newsgroup
: they control, so here it is.
...
I read this very carefully. I was going to respond to line items, but I
lost my place in the file ;-)
My real world tests do not involve the transfer of .GIF files, nor of
uncompressed binaries that are mostly zeroes.
I have seen a drop in serial rate result in an increase in performance, in a
poorly configured environment, just like those that some of us face.
A reduced baud rate yielding better throughput was just suggested by another
poster in this group, in response to a query about 14.4 modem throughput.
Chuck and Frank both live in worlds of their own making. Frank believes
that a product is not robust if it can't talk via 7-bit transport to a 20
year old VAX. Chuck believes that everyone should buy a product that does
well on a clean line between two 486DX-33s with V.32bis.
My _long_ experience with both is that Kermit has always done very well.
ZModem was always annoying to operate. Just how _does_ one abort a transfer?
If Chuck had offerred a Terminal Emulator and File Transfer Program that was
as complete as MSKermit, I might have grown accustomed to it. I despised all
of the early versions of ProComm, which Frank suggests is the most common
place to find ZModem in use on a PC.
How many copies of Pro-Yamm exist? I don't expect that I will ever buy one.
It is the ZModem protocol as it lives in a popular product, that Frank was
suggesting was inferior to MSKermit.
I agree with him.
--
---
Clarence A Dold - do...@rahul.net
- Milpitas (near San Jose) & Napa CA.
Chuck Forsberg WA7KGX
>Chuck Forsberg WA7KGX (c...@omen.UUCP) wrote:
>: submitted to comp.protocols.kermit. Columbia University acknowledged
>: receipt of this report but has not chosen to release it to the newsgroup
>: they control, so here it is.
>
>...
>
>I read this very carefully. I was going to respond to line items, but I
>lost my place in the file ;-)
>
>My real world tests do not involve the transfer of .GIF files, nor of
>uncompressed binaries that are mostly zeroes.
I chose a .gif file because it is representative of most types
of compressed files, including ZOO, ZIP, .Z, TLB, LHA, etc.
with a fairly flat distribution of codes. The file length is
ideal for many protocol tests, and it's a neat picture. It came
in handy when I was challenged to show it was what I claimed it
was - I displayed it on a GIF viewer!
>
>I have seen a drop in serial rate result in an increase in performance, in a
>poorly configured environment, just like those that some of us face.
>A reduced baud rate yielding better throughput was just suggested by another
>poster in this group, in response to a query about 14.4 modem throughput.
Columbia got this boost in throughput when changing from 19200 bps direct
connect (Table 2) to a 9600 bps modem. No errors were reported in either
case.
>
>Chuck and Frank both live in worlds of their own making. Frank believes
>that a product is not robust if it can't talk via 7-bit transport to a 20
>year old VAX. Chuck believes that everyone should buy a product that does
>well on a clean line between two 486DX-33s with V.32bis.
We demonstrated ZMODEM-90(Tm) over a 7-bit connection at the shootout.
It was somewhat faster than Kermit. I didn't mention it in the shootout
report because 1) most people don't know what "7-bit transport" means
(and don't want to know!), 2) I could not get Kermit to provide stable
numbers over the particular path I had available (BSD/386 telnet), and
3) the paper was getting too long anyway.
Note that our bulletin board uses a 4.77 mHz PC (with HD). If Frank wishes,
he can come out here and we will use the PC to receive the files.
>
>My _long_ experience with both is that Kermit has always done very well.
>ZModem was always annoying to operate. Just how _does_ one abort a transfer?
If you need to blow out a ZMODEM transfer just start sending ^X
characters, 5 in a row will always do it. (You may need more if
there is line noise.) Pro-YAM, DSZ et al do this automatically
if there is a fatal error. On the other hand, Kermit is nearly
impossible to abort if the ^C terminate is shut off, which is
necessary to repeat Columbia's tests.
I suggest you try real ZMODEM software before knocking ZMODEM.
>If Chuck had offerred a Terminal Emulator and File Transfer Program that was
>as complete as MSKermit, I might have grown accustomed to it. I despised all
>of the early versions of ProComm, which Frank suggests is the most common
>place to find ZModem in use on a PC.
In many ways DOS Professional-YAM is more complete than Kermit.
MSKermit does not have Compuserve B+, XMODEM, YMODEM, ZMODEM,
X.PC, SCO Console, VP/ix support, Doorway support, etc. etc.
Come to think of it, MSKermit does not have a Kermit that will
work in some of the environments Professional-YAM's Kermit works in.
>
>How many copies of Pro-Yamm exist? I don't expect that I will ever buy one.
There is no such thing as Pro-Yamm. It's Professional-YAM, or Pro-YAM
for short. Only one "m". There is a shareware subset, ZCOMM.
>
>It is the ZModem protocol as it lives in a popular product, that Frank was
>suggesting was inferior to MSKermit.
The Columbia University hit piece dos not distinguish between
ZMODEM implementations. Quite to the contrary, it implies
XMODEM implementations are the same.
If we are to limit our discussion to only the most popular
implementations of a particular protocol, then we would have to
compare Procomm's Kermit with Procomm's ZMODEM. It's a safe bet
that there were more copies of Datastorm product in use than
MSKermit 3.13 at the time the Columbia article was written.
Jianqing Hu
>In article <CJrEo...@rahul.net> do...@rahul.net (Clarence Dold) writes:
>>Chuck Forsberg WA7KGX (c...@omen.UUCP) wrote:
>>: Here is the report on the Jan 6 Protocol Shootout. This report was
>>: submitted to comp.protocols.kermit. Columbia University acknowledged
>>
>>lost my place in the file ;-)
>>
>>My real world tests do not involve the transfer of .GIF files, nor of
>>uncompressed binaries that are mostly zeroes.
>
>I chose a .gif file because it is representative of most types
>of compressed files, including ZOO, ZIP, .Z, TLB, LHA, etc.
>with a fairly flat distribution of codes. The file length is
>ideal for many protocol tests, and it's a neat picture. It came
>in handy when I was challenged to show it was what I claimed it
>was - I displayed it on a GIF viewer!
>
>>
>>I have seen a drop in serial rate result in an increase in performance, in a
>>poorly configured environment, just like those that some of us face.
>
>connect (Table 2) to a 9600 bps modem. No errors were reported in either
>case.
>
>>Chuck and Frank both live in worlds of their own making. Frank believes
>>that a product is not robust if it can't talk via 7-bit transport to a 20
>>year old VAX. Chuck believes that everyone should buy a product that does
>>well on a clean line between two 486DX-33s with V.32bis.
>
>We demonstrated ZMODEM-90(Tm) over a 7-bit connection at the shootout.
>It was somewhat faster than Kermit. I didn't mention it in the shootout
>report because 1) most people don't know what "7-bit transport" means
>(and don't want to know!), 2) I could not get Kermit to provide stable
>numbers over the particular path I had available (BSD/386 telnet), and
>3) the paper was getting too long anyway.
>
>>My _long_ experience with both is that Kermit has always done very well.
>>ZModem was always annoying to operate. Just how _does_ one abort a transfer?
>
Kermit is better if 7 bit path is the only choice. As a student in a
university, we have some hardwired lines stick to 7E1, and there is no way
to use zmodm 90(tm), so the free kermit is valuable, though slower in many
cases.
>If you need to blow out a ZMODEM transfer just start sending ^X
>characters, 5 in a row will always do it. (You may need more if
SOme impelmentation under window have no way to type 5 ^X's
>there is line noise.) Pro-YAM, DSZ et al do this automatically
>if there is a fatal error. On the other hand, Kermit is nearly
>impossible to abort if the ^C terminate is shut off, which is
>necessary to repeat Columbia's tests.
>
>I suggest you try real ZMODEM software before knocking ZMODEM.
>
>>If Chuck had offerred a Terminal Emulator and File Transfer Program that was
>>as complete as MSKermit, I might have grown accustomed to it. I despised all
>>of the early versions of ProComm, which Frank suggests is the most common
>>place to find ZModem in use on a PC.
>
>In many ways DOS Professional-YAM is more complete than Kermit.
>MSKermit does not have Compuserve B+, XMODEM, YMODEM, ZMODEM,
>X.PC, SCO Console, VP/ix support, Doorway support, etc. etc.
>Come to think of it, MSKermit does not have a Kermit that will
>work in some of the environments Professional-YAM's Kermit works in.
But kermit is free in many cases, and also it is easier to use.
>
>>
>>How many copies of Pro-Yamm exist? I don't expect that I will ever buy one.
>
>There is no such thing as Pro-Yamm. It's Professional-YAM, or Pro-YAM
>for short. Only one "m". There is a shareware subset, ZCOMM.
>
>>
>>It is the ZModem protocol as it lives in a popular product, that Frank was
>>suggesting was inferior to MSKermit.
>
>The Columbia University hit piece dos not distinguish between
>ZMODEM implementations. Quite to the contrary, it implies
>XMODEM implementations are the same.
>
>If we are to limit our discussion to only the most popular
>implementations of a particular protocol, then we would have to
>compare Procomm's Kermit with Procomm's ZMODEM. It's a safe bet
>that there were more copies of Datastorm product in use than
>MSKermit 3.13 at the time the Columbia article was written.
>
Why don't you count C-Kermit ?
Clarence Dold
: I suggest you try real ZMODEM software before knocking ZMODEM.
How real is GSZ.EXE 11-27-93?
: >It is the ZModem protocol as it lives in a popular product, that Frank was
: >suggesting was inferior to MSKermit.
: If we are to limit our discussion to only the most popular
: implementations of a particular protocol, then we would have to
: compare Procomm's Kermit with Procomm's ZMODEM. It's a safe bet
: that there were more copies of Datastorm product in use than
: MSKermit 3.13 at the time the Columbia article was written.
This was exactly the intent of Frank's original piece. People in general
were knocking the ProComm implementation of Kermit. Frank was pointing out
that there was a much better implementation available.
Paul Flaherty
>This makes C-Kermit prefix 8 characters, 0, 1, d, 7e, 81, 8d,
>a3, and fe (hex). Knowing this, one can understand why YMODEM-g
>is fastest since it does not prefix any control characters.
Kermit itself doesn't require the prefixing of any characters other than SOH;
the fact that it CAN do so in order to work around escape characters is one of
the strengths of the protocol. In any event, the eight bytes you mention lead
to less than 3% overhead in a well compressed binary. Big deal.
--
-=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make
->pa...@Stanford.EDU | history." -- Jake Grafton
Paul Flaherty
>I chose a .gif file because it is representative of most types
>of compressed files, including ZOO, ZIP, .Z, TLB, LHA, etc.
>with a fairly flat distribution of codes. The file length is
>ideal for many protocol tests, and it's a neat picture. It came
>in handy when I was challenged to show it was what I claimed it
>was - I displayed it on a GIF viewer!
Actually, no, GIF files aren't a very good random byte test; there tend to
be plenty of zero runs. If you really want a good random byte test, simply
generate the files with a good pseudorandom sequence, do a frequency count,
and publish both your files and the frequency count.
Chuck Forsberg WA7KGX
If that were the intent then there would have been mention in the original
Columbia University article that better versions of ZMODEM exist but were
not considered.
Paul Flaherty
>Trust me Paul, I know what I'm talking about. Since Columbia
>University's Kermit wonks are more familiar with the innards of
>C-Kermit and MSKermit I shall leave it to them to explain why
>each character mentioned above is quoted when sending from
>C-Kermit 189 to MSKermit 3.13.
Now, one is led to wonder why only the "Columbia University Kermit wonks"
are capable of explaining why certain control characters are quoted between
5A(189) and 3.13. Especially since, one good read through the protocol
manual will tell anyone who is capable of recitation the purpose of Kermit
quoting, and the only required quoted character is SOH (or whatever the
packet start character is set to).
Kermit per se doesn't require any additional quoting characters; the channel
itself (owing to escape characters) may, and the ability to selectively
quote allows for MAXIMUM binary transfer throughput. Any protocol incapable
of controlled character quoting is either incapable of transfer, or doomed
to a substantial reduction in protocol performance.
The combination you cite [ 5A(189) and 3.13 ] is capable of transfers with
less than 5% overhead, on a regular basis. Chasing that last 5% is of
dubious utility, at best.
Chuck Forsberg WA7KGX
There are some runs in b17mh.gif. This would give Kermit an advantage
over ZMODEM MobyTurbo. If Columbia University asks me to rerun that
test with a random noise file I shall do so.
Come to think of it, msvibm.zip has far more runs than b17mh.gif,
so why don't you ask Columbia University to redo *THEIR* test also???
352650 33 b17mh.gif
hist[3] = 13
hist[4] = 1
hist[5] = 1
hist[7] = 1
hist[33] = 1
325434 9 msvibm.zip
hist[3] = 218
hist[4] = 2
hist[5] = 2
hist[7] = 43
hist[9] = 8
Chuck Forsberg WA7KGX
Trust me Paul, I know what I'm talking about. Since Columbia
University's Kermit wonks are more familiar with the innards of
C-Kermit and MSKermit I shall leave it to them to explain why
each character mentioned above is quoted when sending from
C-Kermit 189 to MSKermit 3.13.
--
Chuck Forsberg WA7KGX
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>Trust me Paul, I know what I'm talking about. Since Columbia
>>University's Kermit wonks are more familiar with the innards of
>>C-Kermit and MSKermit I shall leave it to them to explain why
>>each character mentioned above is quoted when sending from
>>C-Kermit 189 to MSKermit 3.13.
>
>Now, one is led to wonder why only the "Columbia University Kermit wonks"
>are capable of explaining why certain control characters are quoted between
>5A(189) and 3.13. Especially since, one good read through the protocol
>manual will tell anyone who is capable of recitation the purpose of Kermit
>quoting, and the only required quoted character is SOH (or whatever the
>packet start character is set to).
>Kermit per se doesn't require any additional quoting characters
Paul, you don't understand Kermit, much less C-Kermit and MSKermit.
Since Columbia University's Kermit wonks are hiding from this
discussion, I'll have to explain it to you myself, for each of
the characters I've listed:
0 Kermit software uses null terminated strings
01 The start of packet character
0d MSKermit won't work without it being quoted
7e
81 Start of packet with 8th bit set
8d MSKermit won't work without it per FDC
a3
fe
The other three are used internally by Kermit's performance
features (repeat prefix, etc.). It might be possible to
unquote them by disabling Kermit performance features.
Paul is correct in claiming that Kermit itself does not need to
quote all of these characters. A careful rewrite of C-Kermit
and MSKermit could reduce the required quoting set. Perhaps we
will see this with C-Kermit 500 and MSKermit 5.00. Columbia may
fix the Kermit definition to allow programmers get rid of the
fixed delays in C-Kermit and MSKermit. And maybe they will also
fix Kermit's file transfer reporting to truthfully state the
actual times.
None of these enhancements apply to current Columbia University Kermit code.
Paul Flaherty
>Paul, you don't understand Kermit, much less C-Kermit and MSKermit.
I've been using Kermit now for over a decade, on a number of platforms (CP/M,
RT-11, VMS, Unix, Mac, PC, and a few others), and know enough about the
protocol to implement my own extensions (forward error correction).
>Since Columbia University's Kermit wonks are hiding from this
>discussion, I'll have to explain it to you myself, for each of
>the characters I've listed:
>0 Kermit software uses null terminated strings
>01 The start of packet character
>0d MSKermit won't work without it being quoted
>7e
>81 Start of packet with 8th bit set
>8d MSKermit won't work without it per FDC
>a3
>fe
Well, this fails the empirical test. I regularly transfer binary files to
and from Stanford, using C-Kermit 5A(189) and MSKermit 3.13. The only
characters I have quoted are 0 ( for some reason 5A(189) won't let you unquote
it), 1 (SOH, which actually doesn't need to be quoted, but should be to
ensure correct state transition in the event of an error), and 17/19/145/147
(cntl-s/cntl-q, which the Stanford Ethertips require). And that's it. My
transfer rates easily average 95%, so quoting isn't a significant issue in
practice.
In any event, even if we assume you're correct, that's 3.125% overhead for
a true random binary. Certainly not a significant performance degradation.
You've made a number of good points about benchmarking, and in particular the
need for some standard benchmarks in this field that have some meaning to
folks who actually use this stuff. The situation here has a parallel with what
Computer Architecture was going through before SPEC. A meaningful,
standardized benchmark would be a Good Thing. I'd propose the following:
Three categories:
1. True Random (uniform random sequence) binary transfer.
2. Compressed File (zip, gzip, zoo, gif, jpg) binary transfer.
3. Text File (postscript, flat ascii) text transfer.
The main difficultly would be duplicating noise conditions; it should be
possible to build an RS-232 standard noise source, although use of it would
require multiple test runs on each of the bench suites.
Dale C Shuttleworth
: c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
: >I chose a .gif file because it is representative of most types
: >of compressed files, including ZOO, ZIP, .Z, TLB, LHA, etc.
: >with a fairly flat distribution of codes. The file length is
: >ideal for many protocol tests, and it's a neat picture. It came
: >in handy when I was challenged to show it was what I claimed it
: >was - I displayed it on a GIF viewer!
: Actually, no, GIF files aren't a very good random byte test; there tend to
: be plenty of zero runs. If you really want a good random byte test, simply
: generate the files with a good pseudorandom sequence, do a frequency count,
: and publish both your files and the frequency count.
Well, I might be missing something here but all my GIFs have
very few zero runs (except in the header defining the palette
information). The actual image data is pretty well compressed
(and hence random). Whether the uncompressed palette data is
significant depends on the size of the GIF (and number of bits per
pixel). Still, if you are after random data try encrypting the
files before you send them using a decent cipher (DES, RSA. etc)
- that usually defeats any attempts at further compression.
Dale.
--
******************************************************************************
* Dale Shuttleworth *
* Dept of Elec Eng, Brunel University, Uxbridge, UB8 3PH, UK *
* ee9...@brunel.ac.uk *
******************************************************************************
Hans-Joachim Zierke
On 17.01.94, do...@rahul.net (Clarence Dold) writes:
> Chuck and Frank both live in worlds of their own making. Frank believes
> that a product is not robust if it can't talk via 7-bit transport to a 20
> year old VAX. Chuck believes that everyone should buy a product that does
> well on a clean line between two 486DX-33s with V.32bis.
^^^^^^^^^^^^^^^?
At the end of 1989, mailbox systems in West-Berlin got some new users with
plain V22b without any error correction. This was understandable, the new
users did not have a lot of money in the currency needed for buying modems.
These users transferred mail and news with some of the (non-Fido)
"Point"-Systems, that are in wide use here. This is a batch transfer with
one batch per direction. The "Point"-program starts an external protocol
for transfer.
The phone lines to East-Berlin were of a quality that reduced the number of
lines after rainfall.
With the Omen gsz/dsz, these users were able to transfer with something
like 50cps via plain V22b.
Some months later, the Sysop of my local mailbox switched to a new OS/2
mailbox program. (The programmers had to write replacement port drivers,
because the original IBM drivers were <deleted for politeness>.) Since Omen
has product availibility problems with OS/2, he had to use M2ZModem for
the mailbox.
After this switch from dsz to a "normal" ZModem the users in East-Berlin
were no longer able to get News and Mail without an error-correcting modem.
Their connections died regularely.
I think you may call this a "real-world test result", this time not for
speed.
hajo
Gehri Grimaud
> Since Columbia University's Kermit wonks are hiding from this
> discussion, I'll have to explain it to you myself, for each of
> the characters I've listed:
Maybe they are "hiding" because of your childish approach. When you result
to name calling it shows that you are operating on an emotional level.
This insults the people who work on kermit as well as the many people who use
kermit. It also damages your credibility. Perhaps when you start using a
more professional approach more people may be willing to entertain your
arguments.
Healthy discussions about the differences and short commings of Kermit,
X-modem, Y-modem, and Z-modem are what net.news is all about. It is how
products and ideas grow, but we could all do without the bickering and
name calling.
--
===============================================================================
Gehri Grimaud ge...@cc.usu.edu
Utah State University ge...@usu.bitnet
Office of Computer Services tel. (801) 750-2392
UMC 4410
Logan, Utah 84322
"In space every day is a bad hair day!"
===============================================================================
Chuck Forsberg WA7KGX
>In article <1994Jan18....@omen.UUCP>, c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>> Since Columbia University's Kermit wonks are hiding from this
>> discussion, I'll have to explain it to you myself, for each of
>> the characters I've listed:
>
>Maybe they are "hiding" because of your childish approach. When you result
If you think the word "wonk" is childish you haven't been
listening to much political news lately. "Wonk" is an accepted
term in the national media, as in "policy wonks" used by a
liberal columinst to denote amdinistration policy makers the
other day on C-SPAN.
Chuck Forsberg WA7KGX
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>Paul, you don't understand Kermit, much less C-Kermit and MSKermit.
>
>I've been using Kermit now for over a decade, on a number of platforms (CP/M,
>RT-11, VMS, Unix, Mac, PC, and a few others), and know enough about the
>protocol to implement my own extensions (forward error correction).
>
>>Since Columbia University's Kermit wonks are hiding from this
>>discussion, I'll have to explain it to you myself, for each of
>>the characters I've listed:
>
>>0 Kermit software uses null terminated strings
>>01 The start of packet character
>>0d MSKermit won't work without it being quoted
>>7e
>>81 Start of packet with 8th bit set
>>8d MSKermit won't work without it per FDC
>>a3
>>fe
>
>Well, this fails the empirical test. I regularly transfer binary files to
Correct, Paul. I fogot 23h. Here is an actual dump of what C-Kermit sends
to MSKermit as previously discussed:
04b0 2e 64 6d 70 27 0d 0a 53 54 41 52 54 0d 0a 1b 5f .dmp'..START..._
04c0 72 65 63 1b 5c 01 30 20 53 7e 2a 20 40 2d 23 59 rec.\.0 S~* @-#Y
04d0 33 7e 4e 26 54 57 44 0d 01 2c 21 46 32 35 36 2e 3~N&TWD..,!F256.
04e0 44 4d 50 28 4b 56 0d 01 20 22 44 22 6e 36 23 40 DMP(KV.. "D"n6#@
04f0 23 41 02 03 04 05 06 07 08 09 0a 0b 0c 23 4d 0e #A...........#M.
0500 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e ................
0510 1f 20 21 22 23 23 24 25 26 27 28 29 2a 2b 2c 2d . !"##$%&'()*+,-
0520 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d ./0123456789:;<=
0530 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d >?@ABCDEFGHIJKLM
0540 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d NOPQRSTUVWXYZ[\]
0550 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d ^_`abcdefghijklm
0560 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d nopqrstuvwxyz{|}
0570 23 7e 7f 80 23 c1 82 83 84 85 86 87 88 89 8a 8b #~..#...........
0580 8c 23 cd 8e 8f 90 91 92 93 94 95 96 97 98 99 9a .#..............
0590 9b 9c 9d 9e 9f a0 a1 a2 23 a3 a4 a5 a6 a7 a8 a9 ........#.......
05a0 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ................
05b0 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ................
05c0 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 ................
05d0 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ................
05e0 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 ................
05f0 fa fb fc fd 23 fe ff 25 4b 56 0d 01 25 23 5a 2c ....#..%KV..%#Z,
0600 58 22 0d 01 25 24 42 21 5f 23 0d 44 4f 4e 45 0d X"..%$B!_#.DONE.
Read it and weep. Note that none of the flow control characters are
quoted here, just the characters Kermit needs for itself.
Paul Flaherty
>Correct, Paul. I fogot 23h. Here is an actual dump of what C-Kermit sends
>to MSKermit as previously discussed:
[large hex dump deleted for nonrelevancy ]
>Read it and weep. Note that none of the flow control characters are
>quoted here, just the characters Kermit needs for itself.
All this proves is that you've improperly configured Kermit for your benchmark,
and that therefore your results are invalid. Since quoting is controlled on
a character by character basis by user level commands, it stands to reason that
this is a user configuration error, not a flaw in Kermit. I've said it before
and I'll say it again, the only protocol required quoting is for NUL and SOH.
Period. It works.
Leslie Mikesell
Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
>If we are to limit our discussion to only the most popular
>implementations of a particular protocol, then we would have to
>compare Procomm's Kermit with Procomm's ZMODEM. It's a safe bet
>that there were more copies of Datastorm product in use than
>MSKermit 3.13 at the time the Columbia article was written.
How about limiting the discussion to software that is available for
free? We can find glossy sales literature elsewhere. That's kermit,
a version of sz that can't dial out, and umm, err, what else?
Les Mikesell
l...@chinet.com
Chuck Forsberg WA7KGX
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
If you're so correct Paul, go ahead and post .kermrc and mskermit.ini files
for C-Kermit 189 and MSKermit 3.13 that allow one to repeat the file transfer
performance claimed in Columbia University's Kermit News #5 on the files
they used while quoting only the characters you claim.
Hint - the Kermit protocol itself does not require NUL to be quoted,
but C-Kermit does.
Go ahead and post the two configuration files already.
Chuck Forsberg WA7KGX
"It's KermitWare ... it is not in the public domain"
"It's not "freeware""
Columbia University Kermit News #5 page 1
Not much left to talk about is there???
Roger Sheppard
>In article <1994Jan18....@omen.UUCP>, c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>> Since Columbia University's Kermit wonks are hiding from this
>Healthy discussions about the differences and short commings of Kermit,
>X-modem, Y-modem, and Z-modem are what net.news is all about. It is how
>products and ideas grow, but we could all do without the bickering and
>name calling.
One BIG problem with Zmodem is that from 1987 it is no longer Free,
this is not the case with C-Kermit..
Here in New Zealand the Wellington City Council has been running
a Free Public Internet site for some 2 years, mostly on old Vaxes.
they now have over 1800 users..
I tried to get a later Zmodem for the Vax running VMS, but alass
the later Complementary version only supports Omens PC versions of Zmodem...
But we have found great support from Columbia University in useing C-Kermit
and its support for wild cards, and Please note, its FREE, and supported on
most Home computers, not like the later Zmodem...
C-Kermit supports most platforms, and its Free, but I don't think this
is the case with Zmodem..
>Gehri Grimaud ge...@cc.usu.edu
>Utah State University ge...@usu.bitnet
>Office of Computer Services tel. (801) 750-2392
>UMC 4410
>Logan, Utah 84322
Untill Zmodem becomes Free, its no longer in the liege....
Roger W. Sheppard Internet - shepp...@kosmos.wcc.govt.nz
r.she...@genie.geis.com
GEnie - r.sheppard5
Chuck Forsberg WA7KGX
>In article <1994Jan18....@cc.usu.edu>, ge...@cc.usu.edu (Gehri Grimaud) writes:
>>In article <1994Jan18....@omen.UUCP>, c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>> Since Columbia University's Kermit wonks are hiding from this
>
>>Healthy discussions about the differences and short commings of Kermit,
>>X-modem, Y-modem, and Z-modem are what net.news is all about. It is how
>>products and ideas grow, but we could all do without the bickering and
>>name calling.
>
>One BIG problem with Zmodem is that from 1987 it is no longer Free,
>this is not the case with C-Kermit..
>
>Here in New Zealand the Wellington City Council has been running
>a Free Public Internet site for some 2 years, mostly on old Vaxes.
>they now have over 1800 users..
>
>I tried to get a later Zmodem for the Vax running VMS, but alass
>the later Complementary version only supports Omens PC versions of Zmodem...
So what's wrong with complimentary rzsz only supporting Omen's
shareware and commercial programs? According to Columbia
University's Kermit News, only Columbia's Kermit is any good for
use with Unix C-Kermit, and the Kermit books cost more than a
ZCOMM registration.
Anyway, it's rather a bit late to put ZMODEM out of the
discussion since Columbia University put ZMODEM into the
discussion in their Kermit News hit piece on ZMODEM.
Paul Flaherty
>If you're so correct Paul, go ahead and post .kermrc and mskermit.ini files
>for C-Kermit 189 and MSKermit 3.13 that allow one to repeat the file transfer
>performance claimed in Columbia University's Kermit News #5 on the files
>they used while quoting only the characters you claim.
Let's be clear on this. I'm not an apologist for Columbia, so I can neither
confirm nor deny the results that they claim. What I can and will now proceed
to do is to back my own claims that C-Kermit 5A(189) / MS-Kermit 3.13 is
capable of throughputs to 95% of line bandwidth on binary file transfers,
when, and I emphasize WHEN PROPERLY CONFIGURED. The configuration commands
on both ends are similar:
SET FILE TYPE BINARY
SET SEND PACKET 1000
SET RECEIVE PACKET 1000
SET BLOCK 3
SET WINDOW 2
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 0 1 17 19 145 147
Setup: I'm running C-Kermit under Ultrix 4.2 on a DEC 5000 series box, and
MS-Kermit on a Zenith Z286 (8 MHz) with 16450 UARTs, and a V22bis modem.
The connection goes through two COs (415-593 and 415-497) to a CISCO
ethertip; the telnet connection between the ethertip and unix box appears to
require xon/xoff flow control. This connection regularly yields a transfer
rate of 228 cps, out of a possible 240, for 95% efficiency, on ZIP binary
transfers. I've recently changed to a USR Sportster V32bis/V42bis modem, and
I'm currently able to squeeze about 1650 cps out of this combination, even
with V32 error correction enabled, for an efficiency of 92%, on ZIP binary
transfers.
Disclaimers: I am in no way connected with Columbia University. I'm a FSF
contributing author (ECC), and my dissertation work involves, among other
things, predicting the performance of protocols, work for which I was awarded
at SVNC '91.
Paul Flaherty
>So what's wrong with complimentary rzsz only supporting Omen's
>shareware and commercial programs? According to Columbia
>University's Kermit News, only Columbia's Kermit is any good for
>use with Unix C-Kermit, and the Kermit books cost more than a
>ZCOMM registration.
The text of the book (as well as typeset PostScript version) is available via
anonymous ftp from Columbia. So buying the book is largely a vanity purchase.
In addition, the full protocol manual, and several magazine articles are also
freely available.
Chuck Forsberg WA7KGX
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>So what's wrong with complimentary rzsz only supporting Omen's
>>shareware and commercial programs? According to Columbia
>>University's Kermit News, only Columbia's Kermit is any good for
>>use with Unix C-Kermit, and the Kermit books cost more than a
>>ZCOMM registration.
>
>The text of the book (as well as typeset PostScript version) is available via
>anonymous ftp from Columbia. So buying the book is largely a vanity purchase.
>In addition, the full protocol manual, and several magazine articles are also
>freely available.
Paul, could you be so kind as to provide the pathnames for these files?
I don't see any of the three Kermit books in Columbia University's public FTP
area. All I found was a copy of an antique Kermit spec. Please provide
pathnames for:
1. current Kermit protocol spec
2. Using C-Kermit
3. Using MS-DOS Kermit
Chuck Forsberg WA7KGX
Using Paul's parameters:
SET SEND PACKET 1000
SET RECEIVE PACKET 1000
SET BLOCK 3
SET WINDOW 2
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 0 1 17 19 145 147
SET FILE TYPE BINARY
echo Kermit init params from pa...@Stanford.EDU
(I aadded the last line to verify the file's execution)
I transferred a file with 256 codes between C-Kermit 189 (on SCO ODT 3)
and C-Kermit 3.13, and captured the Unix->DOS data stream on a 3rd computer.
Guess what. Ten (10) character codes were prefixed.
But the plot thickens. Using Paul's init file, attempts to send
a binary file back to Unix failed in the midst of the file.
There was no 95% efficiency. Efficiency was 0%.
File transfer was error-free (but slower) after a "set control
prefix all" was given.
Paul's init file doesn't prefix enough control characters.
Paul Flaherty
>Paul, could you be so kind as to provide the pathnames for these files?
>I don't see any of the three Kermit books in Columbia University's public FTP
>area. All I found was a copy of an antique Kermit spec. Please provide
>pathnames for:
> 1. current Kermit protocol spec
~ftp/kermit/e/kproto.ps
> 2. Using C-Kermit
~ftp/kermit/b/ckuker.ps
> 3. Using MS-DOS Kermit
~ftp/kermit/a/mskerm.ps
Those files, plus the most current .bwr text files, AND SOURCE CODE, make up
an outstanding documentation example.
Paul Flaherty
>I transferred a file with 256 codes between C-Kermit 189 (on SCO ODT 3)
>and C-Kermit 3.13, and captured the Unix->DOS data stream on a 3rd computer.
>Guess what. Ten (10) character codes were prefixed.
That's still an overhead of only 3.9%. And that's consistent with my results.
SET CONTROL UNPREF affects *control* character quoting; the quoting character
itself (usually #) and the repeat prefix (usually ~), plus their MSB-set
equivalents, are unaffected. All of which adds up to ten bytes, and
10/256 = 0.039.
>But the plot thickens. Using Paul's init file, attempts to send
>a binary file back to Unix failed in the midst of the file.
>There was no 95% efficiency. Efficiency was 0%.
The configuration I gave you was out of my .kermrc, for the Unix end. For
MSCUSTOM.INI, you need to quote 129 as well, as is mentioned in Kermit News #5.
If you still have problems, I'll email you both my .kermrc and MSCUSTOM.INI.
Jianqing Hu
>In article <1994Jan20.2...@Csli.Stanford.EDU> pa...@Csli.Stanford.EDU (Paul Flaherty) writes:
>>capable of throughputs to 95% of line bandwidth on binary file transfers,
>>when, and I emphasize WHEN PROPERLY CONFIGURED. The configuration commands
>>on both ends are similar:
>>
>>
>>transfers.
>
>Using Paul's parameters:
>
>SET SEND PACKET 1000
>SET RECEIVE PACKET 1000
>SET BLOCK 3
>SET WINDOW 2
>SET CONTROL UNPREFIX ALL
>SET CONTROL PREFIX 0 1 17 19 145 147
>SET FILE TYPE BINARY
>echo Kermit init params from pa...@Stanford.EDU
>
>(I aadded the last line to verify the file's execution)
>
>I transferred a file with 256 codes between C-Kermit 189 (on SCO ODT 3)
>and C-Kermit 3.13, and captured the Unix->DOS data stream on a 3rd computer.
>
>Guess what. Ten (10) character codes were prefixed.
>
What is the result ? CPS, efficiency, compared with those from your setting.
I have tried Paul's init setting transferring both binary and text
files. The Efficiency is usually around 86% to 92% on our school's
Public Unix box. 9600 connection v.42 but no v.42 bis
>But the plot thickens. Using Paul's init file, attempts to send
>a binary file back to Unix failed in the midst of the file.
>There was no 95% efficiency. Efficiency was 0%.
>
This kind of things is site dependent.
When using default setting on our ATT 3b2s, ZMODEM in rzsz could sometimes
crash the system when transferring certain files. (The other end is DSZ
on a 286, if it is important)
In this case, Chuck, how would you calc. the efficiency ?
>File transfer was error-free (but slower) after a "set control
>prefix all" was given.
>
>Paul's init file doesn't prefix enough control characters.
>
>Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
>Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
> Omen Technology Inc "The High Reliability Software"
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
ECE Dept. Illinois Inst. of Tech. |
Chicago, IL 60616 | Office phone: 312-567-6971
Paul Flaherty
>I concur with this. I have been unable to get any kind of performance
>out of kermit on a PEP T2500-T2500 line, which is to say ~1050 cps.
>This is 1050 cps, with 2k packets, 3 windows (Which only one seems to
>get used, according to the full screen monitor), 3 blocks and no
>special unprefixing/prefixing. I've not had any unprefix work properly.
>Therefore, efficiency was 0. Frustation level 100.
A few things come to mind. First of all, a number of the Telebit modems had
a feature known as "kermit spoofing"; if the T2500 has that feature, you
might want to turn it off. Secondly, try dropping to two windows and 1k
packets. Reason being, on some DOS machines, the packet buffer is 2k,
which means that in effect you only have enough room for one slot, with the
packet size you're using. The performance you're reporting (about 1000 cps
for v32bis) is consistent with this pathology. You should also use CTS/RTS
flow control, as this lets the modems run their high water marks much higher.
Also, if your serial ports will handle it, run the modem-serial connection at
57.6kbps. The latter two recommendations are found in the latest mskerm.bwr,
as well as the US Robotics Sportster manual, so they may also help your ZMODEM
and UUCP througput.
Chuck Forsberg WA7KGX
>This kind of things is site dependent.
>When using default setting on our ATT 3b2s, ZMODEM in rzsz could sometimes
>crash the system when transferring certain files. (The other end is DSZ
>on a 286, if it is important)
>
>In this case, Chuck, how would you calc. the efficiency ?
Some systems just are not robust enough to upload files to.
When uploading to a Unix system with MSKermit 3.13 the Unix
C-Kermit sometimes blows out, leaving the shell to deal with
whatever is being sent by MSKermit. I suspect Kermit with
aggressive unprefixing and 5000 byte packets would be at least
as likely to lock up susceptible systems.
--
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
Jianqing Hu
>In article <1994Jan21.2...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>This kind of things is site dependent.
>>When using default setting on our ATT 3b2s, ZMODEM in rzsz could sometimes
>>crash the system when transferring certain files. (The other end is DSZ
>>on a 286, if it is important)
>>
>>In this case, Chuck, how would you calc. the efficiency ?
>
>Some systems just are not robust enough to upload files to.
>
>When uploading to a Unix system with MSKermit 3.13 the Unix
>C-Kermit sometimes blows out, leaving the shell to deal with
>whatever is being sent by MSKermit. I suspect Kermit with
>aggressive unprefixing and 5000 byte packets would be at least
>as likely to lock up susceptible systems.
It is possible. But there is a difference. Kermit takes
a reliable transfer as 1st priority and
ZMODEM expects a robust system for high efficiency.
As a result, people fiddle with Kermit setting for better CPS
and with ZMODEM settings for a possible transfer. (At least
in the none 8,n,1 world)
>--
>Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
>Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
> Omen Technology Inc "The High Reliability Software"
>TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
Chuck Forsberg WA7KGX
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>Paul, could you be so kind as to provide the pathnames for these files?
>>I don't see any of the three Kermit books in Columbia University's public FTP
>>area. All I found was a copy of an antique Kermit spec. Please provide
>>pathnames for:
>> 1. current Kermit protocol spec
>
>~ftp/kermit/e/kproto.ps
No, that's the 1986 spec.
It doesn't describe "Real Kermit" according to Columbia University.
>Those files, plus the most current .bwr text files, AND SOURCE CODE, make up
>an outstanding documentation example.
Paul must think "Kermit" means "free". This is no longer true.
Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New
York. The C-Kermit software may not be, in whole or in part, licensed or
sold for profit as a software product itself, nor may it be included in or
distributed with commercial products or otherwise distributed by commercial
concerns to their clients or customers without written permission of the
Office of Kermit Development and Distribution, Columbia University. This
copyright notice must not be removed, altered, or obscured.
Paul Flaherty
>No, that's the 1986 spec.
>It doesn't describe "Real Kermit" according to Columbia University.
Well, that's the current protocol spec. If by "Real Kermit" you include stuff
like the command interface, that can be had from reading the source code.
The status of the protocol spec is listed in the forward:
#begin kermit.columbia.edu:~ftp/kermit/e/kproto.doc#
PREFACE TO THE SIXTH EDITION
The sixth edition (June 1986) of the Kermit Protocol Manual is being issued for
two major reasons: to correct minor errors in the fifth edition, and to include
new sections on two major protocol extensions: long packets and sliding win-
dows. No attempt has been made to reorganize, rewrite, or otherwise improve
the protocol manual. The Kermit protocol has been presented in an entirely
different -- hopefully more thorough, organized, coherent, and useful (if not
more formal) -- manner in the book, "Kermit, A File Transfer Protocol," by
Frank da Cruz, Digital Press, Bedford MA (1987), ISBN 0-932376-88-6, DEC order
number EY-6705E-DP. If you have the book, you won't need this protocol manual.
On the other hand, if you don't have the book, this manual should still contain
all the necessary information. The Kermit Protocol Manual will continue to be
freely distributed in perpetuity.
#end kermit.columbia.edu:~ftp/kermit/e/kproto.doc#
>Paul must think "Kermit" means "free". This is no longer true.
You're confusing "free" with "public domain". There are all sorts of copyright
arrangements in which the author maintains the copyright, but the product
remains economically free. The purposes behind keeping the copyright include
but are not limited to: preventing other people from exploiting your work for
financial gain, preventing others from introducing bugs into software with
your name on it, granting special conditions to certain user communities, etc.
> Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New
> York. The C-Kermit software may not be, in whole or in part, licensed or
> sold for profit as a software product itself, nor may it be included in or
> distributed with commercial products or otherwise distributed by commercial
> concerns to their clients or customers without written permission of the
> Office of Kermit Development and Distribution, Columbia University. This
> copyright notice must not be removed, altered, or obscured.
Nothing in this notice is inconsistent with economically free availability.
Now, before you bring up your previous argument with respect to Kermit News
Volume 5, let me do it for you:
#begin kermit.columbia.edu:~ftp/kermit/e/newsn5.txt#
It's KermitWare!
While Kermit software is not a commercial product, it is not in the public
domain either, and never has been. It is not "shareware." It's not
"freeware." It is copyright by Columbia University. See page -TERMS for our
terms and conditions.
#end kermit.columbia.edu ~ftp/kermit/e/newsn5.txt#
This is meaningless unless you also quote the TERMS page:
#begin kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc#
TERMS AND CONDITIONS
The Kermit software--including source code--is furnished without warranty of
any kind, and neither Columbia University, nor the individual authors or
publishers, nor any institution that has contributed Kermit material,
acknowledge any liability for any claims arising from the use of Kermit. Since
source code is available, users may fix bugs and make improvements, and are
encouraged to contribute their work back to Columbia for further distribution.
Kermit software may be ordered by private individuals, corporations, academic
or government institutions, and other organizations for their own internal use,
but the software may not be resold or otherwise redistributed to external
clients, customers, or contractors without written permission of the Manager of
Kermit Development and Distribution at Columbia University. Contact us for
further information.
#end kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc#
Again, nothing is inconsistent with economically free availability. Note
especially the phrase "Kermit software is not a commercial product", and the
fact that "The Kermit Protocol Manual will continue to be freely distributed
in perpetuity". Looks pretty free to me.
Chuck Forsberg WA7KGX
>In article <1994Jan22....@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>In article <1994Jan21.2...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>>This kind of things is site dependent.
>>>When using default setting on our ATT 3b2s, ZMODEM in rzsz could sometimes
>>>crash the system when transferring certain files. (The other end is DSZ
>>>on a 286, if it is important)
>>>
>>>In this case, Chuck, how would you calc. the efficiency ?
>>
>>Some systems just are not robust enough to upload files to.
>>
>>When uploading to a Unix system with MSKermit 3.13 the Unix
>>C-Kermit sometimes blows out, leaving the shell to deal with
>>whatever is being sent by MSKermit. I suspect Kermit with
>>aggressive unprefixing and 5000 byte packets would be at least
>>as likely to lock up susceptible systems.
>
>It is possible. But there is a difference. Kermit takes
>a reliable transfer as 1st priority and
>ZMODEM expects a robust system for high efficiency.
Mr. Hu, have you performed tests on this 3b2s system comparing
real ZMODEM software (current Unix rz/sz and Professionlal-YAM
or ZCOMM or DSZ) and real Kermit software using 5000 byte
packets and a window of 5? Same files, same baud rate and modem
configurations??
Jianqing Hu
>ths...@iitmax.iit.edu (Jianqing Hu) writes:
>
>>In article <1994Jan22....@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>>In article <1994Jan21.2...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>>>This kind of things is site dependent.
>>>
>>>
>>>When uploading to a Unix system with MSKermit 3.13 the Unix
>>>C-Kermit sometimes blows out, leaving the shell to deal with
>
>>a reliable transfer as 1st priority and
>>ZMODEM expects a robust system for high efficiency.
>
>do better than any other protocol out there. If ZMODEM expects my systems
>to robust and I get ~1425 cps consistently, why do I have to jump through
>major hoops to get try and get this claim with kermit. I've been using
>kermit for 9 years, from Commodores, Apples II's, IBM PC's, Sun workstations,
>an Altos, AT&T boxes, Vaxen, etc... It has always been a consistent
>protocol. However the current claims really make me wonder whats what.
>
You don't have to. Whenever possible, I use zmodem and I don't
expect a kermit as fast as zmodem or a zmodem as robust as kermit
(when using default settinga !)
>
>>As a result, people fiddle with Kermit setting for better CPS
>>and with ZMODEM settings for a possible transfer. (At least
>>in the none 8,n,1 world)
>
>work manually. Having bothered to read the docmentation, I would have
>figured this out before I even attempted this. And I've not had to fiddle
This is only one case. I have written a software doing communication
and asked some of beta testers for their opinion regarding file transfer
protocols. They are university students outside the world of BBS.
The conclusion is Kermit is slow and zmodem is trouble some. They usually
don't know sliding windows, long packet or pack7.
>with any ZMODEM settings. I sometimes tell it, use verbose mode. If this
>
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
ECE Dept. Illinois Inst. of Tech. |
Chicago, IL 60616 | Office phone: 312-567-6971
>
>Ben Taylor
>Smoke N' Mirrors, Inc.
>s9u...@fnma.com
>be...@snm.com
Jianqing Hu
>In article <1994Jan22....@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>In article <1994Jan22....@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>>In article <1994Jan21.2...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>>>This kind of things is site dependent.
>>>>When using default setting on our ATT 3b2s, ZMODEM in rzsz could sometimes
>>>>crash the system when transferring certain files. (The other end is DSZ
>>>>on a 286, if it is important)
>>>>
>>>>In this case, Chuck, how would you calc. the efficiency ?
>>>
>>>Some systems just are not robust enough to upload files to.
>>>
>>>When uploading to a Unix system with MSKermit 3.13 the Unix
>>>C-Kermit sometimes blows out, leaving the shell to deal with
>>>whatever is being sent by MSKermit. I suspect Kermit with
>>>aggressive unprefixing and 5000 byte packets would be at least
>>>as likely to lock up susceptible systems.
>>
>>It is possible. But there is a difference. Kermit takes
>>a reliable transfer as 1st priority and
>>ZMODEM expects a robust system for high efficiency.
>
>Mr. Hu, have you performed tests on this 3b2s system comparing
>real ZMODEM software (current Unix rz/sz and Professionlal-YAM
>or ZCOMM or DSZ) and real Kermit software using 5000 byte
>packets and a window of 5? Same files, same baud rate and modem
>configurations??
>
kermit and lately migrate to 3.13.
I don't see the reason for 5000 packet and 5 windows. Long packet try
to overcome the ACK overhead and the windows deals with system
latency. If memory serves correctly, C-Kermit 189 default buffer szie
to 9000 some bytes when compiling. If one tells kermit doing 5000/5
I guess the real packet size isn't 5000 or the program have to
manage buffers hardly like a dog.
>--
>Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
>Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
Jianqing Hu
>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>In article <1994Jan21.2...@Csli.Stanford.EDU> pa...@Csli.Stanford.EDU (Paul Flaherty) writes:
>>>c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>>
>>>>Paul, could you be so kind as to provide the pathnames for these files?
>>>>I don't see any of the three Kermit books in Columbia University's public FTP
>>>>area. All I found was a copy of an antique Kermit spec. Please provide
>>>>pathnames for:
>>>> 1. current Kermit protocol spec
>>>
>>>~ftp/kermit/e/kproto.ps
>
>>No, that's the 1986 spec.
>>It doesn't describe "Real Kermit" according to Columbia University.
>
>
>>>Those files, plus the most current .bwr text files, AND SOURCE CODE, make up
>>>an outstanding documentation example.
>
>>Paul must think "Kermit" means "free". This is no longer true.
>
>> Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New
>> York. The C-Kermit software may not be, in whole or in part, licensed or
>> sold for profit as a software product itself, nor may it be included in or
>> distributed with commercial products or otherwise distributed by commercial
>> concerns to their clients or customers without written permission of the
>> Office of Kermit Development and Distribution, Columbia University. This
>> copyright notice must not be removed, altered, or obscured.
>
>in any way shape or form, may not use the latest version of the kermit
>protocol ?
>
At least they don't want a fee to use kermitware with other program
on a per port basis.
>
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
ECE Dept. Illinois Inst. of Tech. |
Chicago, IL 60616 | Office phone: 312-567-6971
Paul Flaherty
>Doesn't look to me like Frank and co want anyone to be able to support the
>new kermit. If this isn't the case, then why isn't the protocol spec up to
>date?
Before you go assigning ulterior motives, what proof do you have that the
protocol manual is "out of date"? Especially given Frank's written commitment
to keep the protocol manual freely available? From what I've read of it,
it seems to completely describe the modern protocol features, including
windowing.
I'd counter that Columbia has a great interest in keeping the protocol public;
after all, Kermit's strength is in the number of implementations (most of which
have been written by other people).
Paul Flaherty
>I hadn't got through the whole manual, but from your comments about having
>to prowse the source code for additional information, I kind of jumpped the
>gun. I've not read the whole thing, nor am I likely too. My comments
>were based from what I read, the "copyright" notice, and your comments.
>I'll retract my comment about the protocol spec.
I should have been more precise. What you get from looking at source is
the "look and feel" of Kermit, which has nothing to do with the protocol
itself. Some sort of distintion needs to be made between "Kermit the
protocol", and "Kermit implementations".
Incidentally, by way of contrast, the TCP and IP specs are circa 1982...
William C Fenner
Jianqing Hu <ths...@iitmax.iit.edu> wrote:
>In article <1994Jan17.1...@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>If you need to blow out a ZMODEM transfer just start sending ^X
>>characters, 5 in a row will always do it. (You may need more if
>
>SOme impelmentation under window have no way to type 5 ^X's
But Kermit, in the way that it was set up for Columbia's test, has no
way to interrupt the transfer *at*all*. Tough luck if something happens
and you don't want to see all the spew on your screen.
Bill
--
Bill Fenner fen...@cmf.nrl.navy.mil
Clarence Dold
: I know about this. The PEP protocol has been turned off for tests I've been
There is PEP protocol, and there is Kermit Spoofing. On my T1500, the
Kermit spoof limits me to 94 byte packets, and the acks are returned
immediately, so I never get over 1 window, regardless of the settings at
either end. This can be observed (if I recall correctly), by looking at
"statistics", or "show protocol", after a transfer, and finding that the
packets are 94, even though both ends were set to some other value.
I think the Telebit register was S111, but you should refer to the manual.
: text files. Bragging that you can get ~2500 cps on a text file that takes
: 20 minutes to download doesn't say a whole lot, when compressing the same
I found that a copy of /etc/termcap took the same real length of time to
transmit whether it was compressed or not. The apparent drop in CPS readout
was exactly offset by the smaller size of the file in .zip form.
This tells me that it makes more sense to transmit /etc/termcap
uncompressed, which is, of course, a daily activity ;-)
--
---
Clarence A Dold - do...@rahul.net
- Milpitas (near San Jose) & Napa CA.
Billy Youdelman
<fen...@cmf.nrl.navy.mil> writes:
> But Kermit, in the way that it was set up for Columbia's test, has no
> way to interrupt the transfer *at*all*. Tough luck if something happens
> and you don't want to see all the spew on your screen.
How about sending it an error packet?
Billy Y..
Leslie Mikesell
Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
>>I tried to get a later Zmodem for the Vax running VMS, but alass
>>the later Complementary version only supports Omens PC versions of Zmodem...
>So what's wrong with complimentary rzsz only supporting Omen's
>shareware and commercial programs? According to Columbia
>University's Kermit News, only Columbia's Kermit is any good for
>use with Unix C-Kermit, and the Kermit books cost more than a
>ZCOMM registration.
Nothing "wrong" with it, but it does put it in a different class from
kermit. There is no obligation to buy the book unless you are
distributing kermit as part of another commecial package. I don't
think the book will tell any secrets that aren't in the source code
that anyone can pick up (or if it does, it wouldn't matter much).
>Anyway, it's rather a bit late to put ZMODEM out of the
>discussion since Columbia University put ZMODEM into the
>discussion in their Kermit News hit piece on ZMODEM.
Unless I missed something the Columbia article referred to the earlier
release and you are the one who brought up the enhancements only
available in the later version. If this is going to turn into a
bang-for-buck discussion we should get the other commercial programs
into the comparison.
Les Mikesell
l...@chinet.com
Chuck Forsberg WA7KGX
Neat idea. Perhaps the next version of C-Kermit and MSKermit will do that.
Of course an error packet may be as effective as stopping the Queen Mary
by dragging an oar if Kermit already has five 5000 byte packets queued up.
--
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Chuck Forsberg WA7KGX
>In article <1994Jan20.1...@omen.uucp>,
>Chuck Forsberg WA7KGX <c...@omen.UUCP> wrote:
>
>>>I tried to get a later Zmodem for the Vax running VMS, but alass
>>>the later Complementary version only supports Omens PC versions of Zmodem...
>
>>So what's wrong with complimentary rzsz only supporting Omen's
>>shareware and commercial programs? According to Columbia
>>University's Kermit News, only Columbia's Kermit is any good for
>>use with Unix C-Kermit, and the Kermit books cost more than a
>>ZCOMM registration.
>
>Nothing "wrong" with it, but it does put it in a different class from
>kermit. There is no obligation to buy the book unless you are
>distributing kermit as part of another commecial package. I don't
>think the book will tell any secrets that aren't in the source code
>that anyone can pick up (or if it does, it wouldn't matter much).
But not anyone can pick up the source code and use it. For
developers, Columbia University Copyright is hopelessly
restrictive. Contrary to Columbia University's claims, it
didn't always use to be that way, but over the years Columbia
University has switched from promoting the advancement of Kermit
software technology throughout the industry to the promotion of
their own product.
Russell Nelson
Since Columbia University's Kermit wonks are hiding from this
discussion,
Or perhaps they're letting you make a fool of yourself *by* yourself.
And, having said that, I must mention that I'm an Omen customer.
-russ <nel...@crynwr.com> ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software | Crynwr Software sells packet driver support.
11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
Joe Doupnik
An error (E) packet is just fine, and it works unless the other
side has become rather hopelessly locked up. As I mentioned offline to
another person I think I've tried ^C^C maybe twice over the past year,
and I tend to use Kermits rather frequently (I wonder why). An Error
packet is available from the keyboard during a file transfer session,
as are less drastic X (skip this file) and Z (skip the rest of the file
group) keyboard interruptions. These features have been in Columbia Kermits
for years and years, are part of the original protocol, are described in
the user's manual books, are on the screens.
Consequently the comment at the top of the inclusion is false.
Joe D.
Chuck Forsberg WA7KGX
Bravely spoken by someone with a commercial link to Columbia
University's Kermit software.
The word "wonk" is used in many segments of the media today
including the highly respected C-SPAN network.
The real "wonk issue" is that Columbia knows my observations are
correct. They have not even attempted to rebut them. Frank da
Cruz declined to appear at the Jan 6 Protocol Shootout knowing
full well the troubling questions about Kermit News he would be
forced to address.
The Kermit people simply wish to change the subject.
Chuck Forsberg WA7KGX
Just for the record I did not make the comment at the top of the
inclusion. That comment was based on someone else's real world
experience.
My comment "Perhaps the next version of C-Kermit and MSKermit
will do that." was meant to underscore the fact that sending an
error packet isn't necessarily sufficient in the real world, as
evidenced by the frustrated user's experience chronicled at the
top of the inclusion.
Mike Durkin
Perhaps some enterprising soul could summarize this thread
from an unbiased point of view. Clearly the maintainers of the
two comm packages are unable to administer a fair comparison of
their tools. This would have value as an addition to the FAQ, but
then again, maybe not. But this current thread is deteriorating
quickly and the original intent is being lost among the noise
of the net. I'd do it, but I don't have ZMODEM and I'm also not
a MS-Kermit pro.
Mike Durkin
Intracorp
1205 Westlakes Drive
Berwyn, PA 19312
(215) 889-2883
Frank da Cruz
c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> Bravely spoken by someone with a commercial link to Columbia
> University's Kermit software.
> The real "wonk issue" is that Columbia knows my observations are
> correct. They have not even attempted to rebut them. Frank da
> Cruz declined to appear at the Jan 6 Protocol Shootout knowing
> full well the troubling questions about Kermit News he would be
> forced to address.
>
believes that by reiterating them on a daily basis, they will
become gospel. However, I will not engage in public bickering with
someone whose primary debating tactic is to always get in the last
word. The Kermit News article speaks for itself -- Chuck can
refute it all he wants to, and you, good readers, can judge for
yourselves. Bear in mind, however, that this is not an all-or-
nothing issue -- use one, use both, use neither.
I am only posting this to dispel the notion that anyone is hiding,
and to point out that Chuck is acting an awful lot like Senator Joe
McCarthy of yore, brandishing his lists, naming names, and assigning
guilt by association. I would not like to think that participants
in this newsgroup hesitate about their postings for fear they will
be publically vilified and ridiculed.
- Frank
Jianqing Hu
Sometimes, the remote end just can't read anything from I/O
port before a long packet is competely sent. In this case,
neither E packet, nor ^X^X will work.
In general, I feel Kermit got a better chance to have the transfer
canceled in a nicer way. With DSZ, if the connection is not first
established, I can't even stop the local DSZ to go back to DOS.
CTRL-X, -C, -Break simply don't work.
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
ECE Dept. Illinois Inst. of Tech. |
Chicago, IL 60616 | Office phone: 312-567-6971
>--
Paul Flaherty
>The Kermit people simply wish to change the subject.
But, in article <1994Jan26....@omen.UUCP> he writes:
>ZMODEM defaults to sending files without translation. Kermit defaults to
>translation. That's why we see so many complaints from users about Kermit
>transferring files without error only to find the file hopelessly corrupted.
Getting a little circular, are we?
Chuck Forsberg WA7KGX
Frank, I didn't get into name calling. I don't understand why
you are.
I have not seen anything from you arguing the points I made in
the Protocol Shootout Report. If you have made such postings
they haven't arrived here. Neither have I seen any comments or
followups to anything you might have said about the Protocol
Shootout Report. You have attacked your competitors' software
in postings since the Shootout, but as far as I can tell you
have not even mentioned the Protocol Shootout, much less
responded to the issues I raised at the Shootout and in its
Report. And, Frank, you did not make yourself available for
questions at the Shootout, despite public and personal
invitations. If you have not been hiding, Frank, you certainly
seem to be avoiding any discussion of the Protocol Shootout
Report.
So unless I've missed some rebuttal you've posted to the
Shootout report, Frank, your comments are out of line.
And then you accuse me of being a Nazi McCarthyite.
Frank, I'm not associating you with anyone. I'm pointing out
your actions. You refuse to discuss the technical points I've
raised in the Shootout Report on your Kermit News Benchmarks,
and then you try to change the subject by calling me a Nazi
McCarthyite.
Jianqing Hu
>In article <1994Jan27.0...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>
>> In general, I feel Kermit got a better chance to have the transfer
>> canceled in a nicer way. With DSZ, if the connection is not first
>> established, I can't even stop the local DSZ to go back to DOS.
>> CTRL-X, -C, -Break simply don't work.
>
>ALT-F to skip the rest of a file.
Well, I am lazy and haven't read .doc other than sz/rz.doc. That is
a problem. I know Kermit's method from its on screen reminder.
I think, and actually have seen, a lot of guys like me, who won't
dig into manuals even if there is a reminder saying so. As such, when
bad things comes out and there is not a "direct" instruction, they
will have a bad impression on the software. The impression might not
be accurate, or even reasonable, but it is real.
As a fact, I did't know crash recovery until I tried a Window's program
which happen to have such an option listed in its setup.
Frank da Cruz
(Chuck Forsberg WA7KGX) writes:
> So unless I've missed some rebuttal you've posted to the
> Shootout report, Frank, your comments are out of line.
> Frank, I'm not associating you with anyone. I'm pointing out
> your actions. You refuse to discuss the technical points I've
>
That's not what I meant -- you've probably used my name 500 times in
public postings (no, I didn't count, feel free to correct the number) in
recent months, often in postings that had nothing to do with me or with
Kermit. Then, when some hapless soul speaks up with a different point
of view, you damn him or her by association with me and/or Columbia
University; your recent comment to Russ Nelson is a perfect example,
since it also accused him of some kind of sinister and hidden
relationship whereby he profits. There is no such relationship. He
simply deposits his packet drivers at Columbia for FTP access, and
advises those who do not have ftp access to order them from us on
diskette by mail, a service we perform approximately at cost, and from
which Russ derives no income at all.
The Kermit News article was not a personal attack on you, Chuck, and I
regret that you're taking it that way. Before the article was
published, the common wisdom went about like this:
Zmodem is the ultimate file transfer protocol. Kermit should never
be used except in the few oddball situations where Zmodem is not
available, because Kermit is sooooooooooo slooooooooow.
I hope that this discussion has served to displace that notion by one
that is a little more reflective of reality:
Zmodem is tuned for speed, Kermit is tuned for reliability.
If Zmodem doesn't work, you have to tune it to make it work.
If Kermit isn't fast, you can tune it to make it fast.
Both protocols work, both can be fast. It's a question of priorites,
defaults, and philosophies. More than that, it's a question of the
people we are addressing when we make these design decisions. I think
it is relatively safe to say that X, Y, and Zmodem protocols appeal to a
certain segment of the computer-using public: those who live in what one
recent poster called the "8N1" world, primarily those dialing up from
PCs to BBSs and transferring ZIP files, and of course it is well suited
to that. Kermit is targeted more towards those who must operate in a
diverse communications and computing environment, and are less apt to
understand the basics of data communications.
Personally, I think that's fine. There is a loyal crowd of Zmodem
users, and a loyal crowed of Kermit users. There is also a much bigger
crowd of people who haven't a clue about any of this, but still need to
engage in file transfer. My goal has been to turn around the almost
universal misconception that Kermit is *intrinsically* slow and should
only be used as a last resort, so that the general public can make
well-informed choices. I think the Kermit News article made some
progress in this direction. If you think the article was unfair in some
respects, bear in mind the unfair treatment Kermit has received all
these years in the newsgroups and popular press.
As to your specific objections, let's make it easy on the poor readers
of this newsgroup. How about if you post a brief but comprehensive,
enumerated list of your points. I will be glad to respond to them. You
will, of course, respond to each of my responses, but I pledge to
refrain from carrying this on any further unless you say something
truly outrageous.
- Frank
Richard Kooijman
>SET CONTROL UNPREFIX ALL
>SET CONTROL PREFIX 0 1 17 19 145 147
I use:
set control unprefixed all
set control prefixed 0 1 3 129 131
on both my PC and and my Unix system between which I transfer
files regularly. Until recently I had to use Kermit because
the hardware flow control on Suns was broken. There is a patch now.
I never had any problems with Kermit.
>Guess what. Ten (10) character codes were prefixed.
>But the plot thickens. Using Paul's init file, attempts to send
>a binary file back to Unix failed in the midst of the file.
>There was no 95% efficiency. Efficiency was 0%.
>File transfer was error-free (but slower) after a "set control
>prefix all" was given.
>Paul's init file doesn't prefix enough control characters.
Try mine.
Richard.
R. Stewart Ellis
>- Frank
This whole exchange has been one of the most unpleasant I have encountered
in 8 years of hanging out. My sympathies are clearly with kermit. No
matter how many times Chuck reiterates his false assertion that kermit is
not free, I nor any other individual has to pay to use it at any kind of
site, which is quite different than the situation with rzsz. Chuck not only
wants money, he restricts the use of the rz and sz programs to use on the
remote end from a licensed implementation of zmodem. He even installed a
rather trivial hack a few years ago to try to prevent people from using it
in a way different from the way he intended it (changed the read and write
strategies from stdio to /dev/tty). In the DOS world there are alternate
implementations (PCSZ?), some of which are free. In the UNIX world there
are not any that I know of. However early versions of rzsz do not carry any
copyright notice or license restriction. Chuck convinced a number of
popular FTP sites or they decided on their own not to keep old versions
around. I succeeded today in finding a readily available site that still
carries one of the old 1988 era versions. Here is the result of a grep of
the source, objects and binaries after a 'make bsd' on SunOS 4.1.3:
zmodem> grep opy * |less
rbsb.c: * updcrc macro derived from article Copyright (C) 1986 Stephen
Satchell.
rbsb.c: * Copyright (C) 1986 Gary S. Brown. You may use this program, or
People who want to use zmodem ought to just put Chuck in their kill file and
use one of the older versions.
One thing else to keep in mind is that protocols of this sort are
increasingly irrelevant as it becomes easier to run network protocols over a
modem connection. More and more sites are using PPP, and lots of people who
are dialing up UNIX to UNIX are using term if their sites do not support
slip or ppp. Maybe this is what has Chuck in such a dither. All I really
use a modem program for is to dial up and negotiate a network like
connection.
--
R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________
Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
Flint, MI 48504 el...@nova.gmi.edu / / / / / /
Gopher,News and modem maintainer, all around hack /________/ / / / /
Chuck Forsberg WA7KGX
>In article <1994Jan22.2...@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>...
>>Mr. Hu, have you performed tests on this 3b2s system comparing
>>real ZMODEM software (current Unix rz/sz and Professionlal-YAM
>>or ZCOMM or DSZ) and real Kermit software using 5000 byte
>>packets and a window of 5? Same files, same baud rate and modem
>>configurations??
>>
>
>To gain optimal throughput with MSKERMIT 3.13 to C-Kermit 5A(189),
>I set send pack 6000 and rec pack 2000 on MSCUSTOM.INI together
>with win 3, block 3, and flow control to rts/cts. On Sparc 10
>host, .kermrc was set to send pack 9024, rec pack 9024, block 3,
>win 4, buffer 30000 30000. I tested upload and download with both
>binary and text files. Upload with text file using kermit won by
>less than half of the time by zmodem. While binary upload and
>download, zmodem won by 20%. I attach the following results from
When benchmarking ZMODEM vs Kermit on compressible files,
fairness demands you try compression on both protocols, or
neither. Since you used Kermit compression please give ZMODEM
compression (sz -Z) a chance.
Chuck Forsberg WA7KGX
> Sometimes, the remote end just can't read anything from I/O
> port before a long packet is competely sent. In this case,
> neither E packet, nor ^X^X will work.
>
> In general, I feel Kermit got a better chance to have the transfer
> canceled in a nicer way. With DSZ, if the connection is not first
> established, I can't even stop the local DSZ to go back to DOS.
> CTRL-X, -C, -Break simply don't work.
How about reading DSZ.DOC?? It recommends ALT-B to cancel a batch,
ALT-F to skip the rest of a file.
--
Chuck Forsberg WA7KGX
>In article <1994Jan28.1...@omen.UUCP> c...@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>>In article <1994Jan27.0...@iitmax.iit.edu> ths...@iitmax.iit.edu (Jianqing Hu) writes:
>>>
>>> In general, I feel Kermit got a better chance to have the transfer
>>> canceled in a nicer way. With DSZ, if the connection is not first
>>> established, I can't even stop the local DSZ to go back to DOS.
>>> CTRL-X, -C, -Break simply don't work.
>>
>>How about reading DSZ.DOC?? It recommends ALT-B to cancel a batch,
>>ALT-F to skip the rest of a file.
>
>Well, I am lazy and haven't read .doc other than sz/rz.doc. That is
>a problem. I know Kermit's method from its on screen reminder.
>
>I think, and actually have seen, a lot of guys like me, who won't
>dig into manuals even if there is a reminder saying so. As such, when
>bad things comes out and there is not a "direct" instruction, they
>will have a bad impression on the software. The impression might not
>be accurate, or even reasonable, but it is real.
>
>As a fact, I did't know crash recovery until I tried a Window's program
>which happen to have such an option listed in its setup.
Mr Hu, The ability to resume an interrupted file transfer is
also documented in sz.doc, so the fact is you didn't even read
sz.doc.
And Columbia University's protocol experts tested sz without
reading the supplied sz.doc file.
What gives??
Jianqing Hu
DUMB user. That is the reason to explain GUI's popularity.
Jianqing Hu | Internet: ths...@iitmax.acc.iit.edu
ECE Dept. Illinois Inst. of Tech. |
Chicago, IL 60616 | Office phone: 312-567-6971
Leonard Erickson
>s9u...@almserv.uucp (Ben Taylor) writes:
>>I concur with this. I have been unable to get any kind of performance
>>out of kermit on a PEP T2500-T2500 line, which is to say ~1050 cps.
>>This is 1050 cps, with 2k packets, 3 windows (Which only one seems to
>>get used, according to the full screen monitor), 3 blocks and no
>>special unprefixing/prefixing. I've not had any unprefix work properly.
>>Therefore, efficiency was 0. Frustation level 100.
>A few things come to mind. First of all, a number of the Telebit modems had
>a feature known as "kermit spoofing"; if the T2500 has that feature, you
>might want to turn it off. Secondly, try dropping to two windows and 1k
>packets. Reason being, on some DOS machines, the packet buffer is 2k,
>which means that in effect you only have enough room for one slot, with the
>packet size you're using. The performance you're reporting (about 1000 cps
>for v32bis) is consistent with this pathology.
He's talking about a PEP connection, *not* a v.32bis. The T2500 only has
v.32 and PEP. With PEP the spoofing is pretty much *required. BTW, the spoofing
only works *with* PEP. It has no effect on non-PEP connections.
>You should also use CTS/RTS
>flow control, as this lets the modems run their high water marks much higher.
>Also, if your serial ports will handle it, run the modem-serial connection at
>57.6kbps. The latter two recommendations are found in the latest mskerm.bwr,
>as well as the US Robotics Sportster manual, so they may also help your ZMODEM
>and UUCP througput.
Except that the *modem* won't lock higher than 19200.
No offense, but you should really refrain from giving advice about how
to tune setting on hardware you aren't familiar with!
>--
>-=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make
>->pa...@Stanford.EDU | history." -- Jake Grafton
--
Leonard Erickson leo...@qiclab.scn.rain.com
FIDO: 1:105/51 Leonard....@f51.n105.z1.fidonet.org (preferred)
Wally Bass
(Chuck Forsberg WA7KGX) writes:
>In article <758917...@crynwr.com> nel...@crynwr.com
(Russell Nelson) writes:
>>In article <1994Jan18....@omen.UUCP> c...@omen.UUCP writes:
>>
>> Since Columbia University's Kermit wonks are hiding from this
>> discussion,
>>
>>Or perhaps they're letting you make a fool of yourself *by* yourself.
>Bravely spoken by someone with a commercial link to Columbia
>University's Kermit software.
Perhaps they're letting you make a fool of yourself *by* yourself.
Now, its been (bravely?) spoken by someone without a commercial link
to Columbia University's Kermit software
Wally Bass
Frank da Cruz
"Protocol Shootout Report". I apologize for prolonging this ridiculous
debate, and I would encourage Chuck to refrain from further gratuitous
snipes at each person who posts a message even remotely supportive of
Kermit or critical of Zmodem, not to mention using innocent questions --
even on unrelated topics -- as an opportunity to fire off another salvo.
I think everybody comes off looking and feeling better if we just answer
users' questions and try our best to solve their problems, and stop
using this forum as a soapbox.
Chuck says:
> For Russ' sake I do hope Crynwr software derives more income as a
> result of their relationship with Columbia Kermit than the cost of a
> single $20 DSZ registration.
>
And for Chuck's sake, I hope he does not make a regular practice of
disclosing business details about his customers in public. This is not
a big confidence builder for potential customers.
Chuck says:
> ...as it was written and as people read it, Kermit News #5 is a
> promotional piece that seeks to enhance Columbia's revenues by
> trumpeting the relative performance of Columbia's product under a
> selected set of conditions and alternatives carefully contrived to
> promote the idea that Kermit is faster than competitive alternatives.
>
Of course it's a promotional piece. However, the test conditions are
fair. Four representitive types of files -- including the ones where
Zmodem's well-known strengths lie -- were transferred over different
types of connections.
Chuck's primary complaint, as I understand it, was that I did not use
ZMODEM-90(TM)-Moby-Turbo(TM) extensions in my tests. Fine, I never said
I did. I used the software that everybody uses and compares Kermit
against, the packages we have heard about constantly over our many years
of help-desk experience, and the article is totally explicit and
detailed about what was tested.
Chuck says:
> So we're back to where we started before Columbia University's Kermit
> News #5 broadside attack on their competition: Use Kermit for
> traditional IBM mainframes and other weird iron, otherwise use ZMODEM
> to get the best in speed, the reliability of 32 bit CRC, and Crash
> Recovery for real world error recovery.
>
That's clearly a skewed opinion. Here is my skewed opinion:
Use Kermit anywhere at all. Use Zmodem on a small subset of "anywhere
at all". You can't use Zmodem on the rest of "anywhere at all" because
it does not work, or it does not exist, in that environment. This
includes at least all 7-bit connections, which are quite common outside
the BBS world, and all of the "oddball" operating systems that one finds
on IBM mainframes, etc, which, one supposes, are only to be sneered at.
I would be very surprised to learn of a connection where Zmodem works
and Kermit does not.
On those connections where "regular" Zmodem protocol works at all, you
can get Kermit to work just as well or better.
Zmodem-90-Moby-Turbo(TM) might well go faster than Kermit if you have it
available to you on both ends, and the connection is cooperative, and if
that is true, then hats off to Chuck.
Chuck says:
> Columbia could have improved on this situation by developing a
> compact, high performance version of the WKERMIT (The Source) Kermit
> driver that could be used by bulletin boards, Telix, ProComm, Qmodem,
> et al. Perhaps it is not too late for Columbia to correct the
> situation.
>
This is absolute nonsense, and a red herring on two counts.
The implementation Chuck is referring to (a) is nine years old, (b) was
a quick hack that hardly ever worked, and (c) depended, in the PC
version, on proprietary libraries for communications functions. The
"WKERMIT" Chuck is referring to did not allow long packets, had horrible
error recovery characteristics, and because of the communications
strategies used, would get hopelessly hung if there were any confusion
about modem signals, to the point that you'd have to reboot your PC, and
it did not support any kind of flow control. Furthermore, it had no
terminal emulator, no script language, no convenience features like key
mapping, and none of the server-related Kermit protocol functions are
supported. Anybody who wants to check out this "compact, high
performance version" of Kermit for themselves, feel free:
host kermit.columbia.edu, directory kermit/extra, files wkermit.*.
Note: wkermit.exe is binary, the rest are text.
In short, it is a primitive package and its Kermit protocol
implementation is limited and fragile. It was a stopgap commissioned by
The Source, cobbled together in a hurry by a contract programmer from
even-then obsolete C-Kermit source code, to be used until the real
thing came along. Although it was some time in coming, the real thing
did, indeed, come along, and WKERMIT was promptly retired.
> Columbia could have improved on this situation by developing a
> compact, high performance version of the WKERMIT (The Source)
> Kermit driver that could be used by bulletin boards, Telix,
> ProComm, Qmodem, et al. Perhaps it is not too late for Columbia
> to correct the situation.
>
Red Herring #2 -- Suppose we rephrase this as: "Omen Technology could
have improved on this situation by developing a compact, high
performance version of the Zmodem-90(TM)-Moby(TM)-Turbo(TM) driver that
could be used by bulletin boards, Telix, ProComm, Qmodem, et al.
Perhaps it is not too late for Omen Technology to correct the
situation."
SHOOTOUT RESULTS
Chuck says:
> Last July Columbia University used its non-profit mail permit to
> distribute thousands of copies of Kermit News Number 5.
>
Point for Chuck. Yes, as a nonprofit institution, we do indeed get a
break on bulk 3rd-class mailings. So what?
> In "The Truth about Kermit File Transfer Performance" tenured
> Columbia University professor...
>
That I'm not.
> ...Frank da Cruz proudly announces that Kermit "outperforms X-, Y-,
> and ZMODEM protocol transfers every time."
>
Out of context. Anybody who reads the article knows that that
"ZMODEM protocol transfers" refers to the ones that were performed in
the suite of tests, using the specified software (Procomm, Telix), and
"every time" refers to each test that was performed. Again, I invite
anybody who is interested, and especially anyone who feels compelled
to take sides on this issue, to actually read the article. I will be
glad to send you printed copy if you send me your postal address. You
can also ftp it from kermit.columbia.edu, directory kermit/e, files:
newsn5.txt (ASCII)
newsn5.ps (PostScript)
> It is not my intention to defend a competitor's product. But,
> the reported Kermit efficiency of Procomm Plus (93%) and Zstem
> (97%) are very close to that of Columbia's own MSKermit (99%).
>
Right; I did not want to imply that all non-Columbia PC Kermit
implementations are lousy, but I did want to show that MS-DOS Kermit
is equal to or better than the best of them. I also left out some
others that were ridiculously bad.
> Frank's 104% figure for MSKermit is misleading because the reduced
> control character prefixing responsible for the MSKermit speedup also
> works sending to Procomm Plus. Columbia does not disclose this
> inconvenient result. In fact, C-Kermit sending to Procomm Plus
> transferred some of Columbia's test files in less time than the
> C-Kermit-MSKermit combination required.
>
Score half a point for Chuck. It's true, I did not know that Procomm
could handle unprefixed control characters. In fact, it can handle
*some* unprefixed control characters. But carriage return (Ctrl-M) is
not among them, so all we gain in text file transfers in this case is
the ability to send linefeed bare. When I repeated the test downloading
the same text file to Procomm under the same conditions as the original
test, except with all possible control characters unprefixed, Procomm's
score went up from 93% to 94%.
> After shading the truth about competitors' Kermit downloading
> performance, Frank's paper proceeds to redefine the YMODEM protocol
> I developed in the 1980's.
>
Sorry if I misrepresented YMODEM -- Nevertheless, the YMODEM protocol
used in the tests was as stated: sb on the host, and YMODEM protocol
in the PC software. Whatever it is!
> Thanks to Columbia's ignorance of file transfer protocols I don't know
> what protocol they actually used for the "XMODEM" and "YMODEM" tests
> listed in Columbia's True-Life Benchmarks.
>
It's clearly stated in the article: sx and sb on the host, XMODEM or
YMODEM protocol in the PC software.
> But Columbia's published numbers reveal a seriously slovenly
> experimental procedure. XMODEM and ZMODEM in all their forms transmit
> file data verbatim, without any prefixing. As a result, data patterns
> have no effect on X/YMODEM throughput.
>
The results given in the article are exactly as reported by the
software, and each trial was run three or more times. Theory is fine,
but in the real world all sorts of factors can cause variations. We
have been through this time and again.
> In addition, Columbia Kermit programs significantly understate the
> time required to perform a file transfer. Kermit reports a file
> transfer took 112.98 seconds when in fact the machines were tied up
> more than nine seconds longer.
>
Here's what actually happens: if you install C-Kermit according to
instructions, it comes with an initialization file that reads in your
dialing and services directories and defines all sorts of macros.
Obviously, this can take some time, especially on slow computers. These
are convenience features that have nothing to do with file transfer,
that can be skipped. sz does not have features like script programming,
dialing directories (let alone dialing), and so starts up faster.
If you want Kermit to start up as fast as sz, you can tell it to skip
the initialization file and give the file-sending and parameter-setting
commands on the command line, for example:
kermit -Y -v 5 -e 5000 -s foo.zip
For real speed, you can even build a nonstandard version of Kermit that
excludes all sorts of time-and-space-consuming features: the interactive
command parser, the built-in debugger, the character-set translator,
etc, and reduce the startup time to practically nil AND make it run
faster too. I did not do that, because it would not be representative
of the C-Kermit software that people actually use.
Second, there is a deliberate default delay of 5 seconds after you give
a SEND command to a remote-mode C-Kermit, to give the user time to
"escape back" to the local Kermit and give a RECEIVE command. This is
purely a convenience feature and has nothing to do with the protocol --
it gives the user time to read an instructional message and then to
escape back without seeing the first packet on the screen. Of course
you can set the delay to be any length of time you want, including zero,
and you can disable this feature altogether. (AND you can also use the
autodownload feature to obviate the need for escaping back altogether --
yes: Kermit has autodownload too, *and* autoupload).
For the record, Kermit's timers start ticking when the first packet is
sent or received, and stop when the last packet is sent or received.
> One set of Columbia's measurements was so preposterous that I
> simply couldn't resist having a bit of fun with it. We noticed
> that cutting the communications speed from 19200 to 9600
> actually increased the speed of a Columbia Kermit file transfer
> from 2648 to 2736 characters per second. (p.13, Tables 2 and 5.)
>
This is indeed what happened. Explain it any way you like.
> One of the tricks Columbia used to discredit ZMODEM in their
> "True-Life Benchmarks" was to carefully select files with
> redundant data that responds unusually well to Kermit's run
> length compression while at the same time refusing to use ZMODEM
> compression.
>
In fact, we chose four types of files:
1. A typical text file (the IBM Mainframe Kermit manual).
2. A UNIX binary file, which, admittedly, had big runs of zeros.
3. An MS-DOS binary (.EXE) file (MS-DOS Kermit itself).
4. A ZIP file (the MS-DOS Kermit distribution file set).
Each of these files illustrates properties of the two file transfer
protocols. Nothing is rigged or pre-engineered here -- these are
perfectly normal files. We could easily have left out (for example) the
ZIP file, which would have skewed the results far more in favor of
Kermit, or picked a text file that could have been compressed a lot more.
> The most egregious instance of this deception is seen with Columbia's
> selection of a Sun Sparc binary of the "uuencode" program. This is a
> tiny program stored in a 24576 byte file. All but a few thousand are
> nulls. Naturally this does wonders for Kermit transfer speeds. Had
> Columbia's protocol boffins read the sz 3.24 documentation they could
> have discovered that ZMODEM compression does even better.
>
But only if you use it with PC software that includes ZMODEM-90(TM)-etc
extensions. I actually did use the compression option (-Z) on sz, but
it had no effect since, apparently, Procomm and Telix don't do anything
with it. And yes, the "uuencode" file was chosen deliberately to
illustrate the dramatic effects of Kermit compression on this type of
file. So what? People actually do transfer this type of file from
time to time.
> Real world users download mostly compressed files,...
>
This is debatable. As I pointed out yesterday, the readers of this
newsgroup are are not typical of the world's computer users at large.
> ... and here the winner is YMODEM-g, closely followed by MobyTurbo(Tm)
> ZMODEM, regular ZMODEM, with Kermit bringing up the rear.
>
YMODEM-g has not much more resemblence to a file transfer protocol than
Kermit's TRANSMIT command, or "copy foo.zip com1". If it works, of
course it's fast, because it doesn't do anything other than blast the
data at the other end, all in one piece, with a filename on the front
and checksum on the end (I'm sure Chuck will correct me if this is a gross
misrepresentation of YMODEM-g technology). Recovery from transmission
errors is, to use Chuck's words, "by sudden death".
> So why is Kermit not the fastest when it only prefixes a few control
> characters? The question is incorrect. Columbia claims that only 0,
> 1, and 129 need to be prefixed, but this doesn't work sending to
> MSKermit 3.11.
>
Of course it doesn't, we never said it did. We were using MS-DOS Kermit
version 3.13, which is the first release to support this feature. Also,
our advice about which characters need to be prefixed goes into a lot
more detail -- there are no simple formulas. Today, for example, I
found that when using a local Annex terminal server, the following
characters must be prefixed in addition to whatever might be required by
the Kermit programs themselves: 15 18 21 23 29 127 143 146 149 151 157
255. Not all connections in the world are totally transparent, the way
BBS users are accustomed to.
> The most impressive demonstration, and the likely reason Frank da Cruz
> did not choose to appear at the Shootout is Kermit's performance in
> the noise test. Or, to be more precise, Kermit's non-performance. In
> the Kermit News True-Life Benchmarks, Frank da Cruz specified a window
> size of 5 and a packet length of 5000. Undoubtedly Frank chose this
> long packet length to minimize Kermit's high per packet overhead
> compared to ZMODEM SUBpackets.
>
8-10 bytes out of 5000 = 0.18 percent. Who is going to quibble about
that? Of course I chose long packets to improve performance -- that's
what they're for. This is all explained in the article.
> XMODEM, YMODEM and Kermit cannot resend a packet with a different
> size. The problem is even worse with Kermit's selective
> retransmission protocol. When we attempted to replicate Columbia's
> 9600 bps plus noise test (Table 5) Kermit failed every time. Well,
> almost every time. The first few times Kermit worked, but that was
> only because C-Kermit quietly refused to send the specified 5000 byte
> packets because a needed "set buffer" command was not included. When
> Kermit actually uses the specified 5000 byte packets with noise bursts
> at 2 second intervals, no data packets get through. Why? It takes 5
> seconds to send a 5000 byte packet at 9600 bps but the specified noise
> bursts come faster than that. Kermit croaks every time unless the Jim
> Kirk Kobiashi Maru procedure is used (relax the test).
>
Chuck makes a good point here. He's right: if the noise bursts came
at precise 2-second intervals, the first data packet would never have
gotten through. But the noise bursts were being generated on a UNIX
system, whose actions are governed by a scheduler, and are therefore
not precise. Once the first data packet got through, the remaining
packets were shortened automatically.
I deliberately chose the worst possible conditions under which Kermit
could function at all with the same settings that I was using in the
preceding tests. I could have sweetened the results considerably by
tailoring Kermit's settings *in advance* for noise resistence, and
increasing the noise level. For example, noise every 1/2 second, and
short, 94-byte packets (which are, by the way, Kermit's default) rather
than 5K packets. Kermit would have come out even further ahead than it
did in the article.
> I made an informal survey of the guests at the shootout. As so
> many have noted, line noise today manifests itself mostly in
> disconnected calls.
>
We've been through this before too. Just because this is 1994, you
can't assume that all telephone connections are clean (here in the New
York City area, T1 clock slippage is still a frequent occurrence). Ask
residents of other countries -- especially in Eastern Europe, the former
Soviet Union, China, Africa, and South America, about their telephone
systems. We also cannot assume that everybody in the world is using
error-correcting modems.
Even assuming all that were true -- no more noise, no more errors -- we
still have other sources of error, overlooked all too often: improperly
(or un-) implemented flow control, data overruns on PCs that do not have
buffered UARTs, interrupt conflicts, etc.
> When this happens ZMODEM's Crash Recovery is relevant, allowing the
> safe resumption of interrupted file transfers. Since Kermit has no
> such feature Columbia chose not to discuss this most vital of ZMODEM's
> many features.
>
ZMODEM's crash recovery is indeed a useful feature, but...
(a) It only works for binary-mode transfers.
(b) It only works when the file sender has a stream-oriented file
system that supports an "fseek()" operation.
It doesn't work for text-mode transfers because files can change size
during text-mode transfer because of record-format conversion. It
doesn't work on record-oriented file systems, or with record-oriented
file formats.
A fully capable "crash recovery" feature would work for both text and
binary mode transfers, and it would not make any assumptions about the
features of the file system. It would be built into the protocol at
the session layer. It would involve checkpoints, commitments, and
protocol messages that would allow resumption not only of an interrupted
file transfer, but even of the connection itself.
These are complicated issues requiring a lot more thought than "hmmm,
how long is the file? n bytes? OK, fseek(n) and start blasting away".
This kind of "crash recovery" could be added to Kermit software with
about five minutes' programming time, but it would be useful only in the
circumscribed world where Zmodem's method is also useful, and Kermit
caters to a more diverse audience. When crash recovery appears in
Kermit protocol and software, it will be generally useful.
Later, Chuck says:
> This historical dissertation overlooks one critical fact. If a
> desired text translation is not performed by the file transfer
> protocol, the translation can be made later. No information lost.
>
> But when Kermit modifies files with spurious text translations
> that file is destroyed.
>
> In the real world one cannot equate the two situations.
>
No matter whether the default transfer mode is text or binary, somebody
will transfer files in the wrong mode; it can't be avoided. Chuck is
right, transferring a binary file in text mode results in garbage. But:
"If a desired text translation is not performed by the file transfer
protocol, the translation can be made later. No information lost."
Is it? Maybe this is true in the English (ASCII) speaking world. Do
any readers of this newsgroup transfer textual data written in Albanian,
Bulgarian, Byelorussian, Czech, Danish, Dutch, Faeroese, Finnish,
French, German, Hebrew, Hungarian, Icelandic, Irish, Italian, Japanese,
Macedonian, Norwegian, Polish, Portuguese, Romanian, Russian,
Serbocroatian, Slovak, Slovene, Spanish, Swedish, or Ukrainian? Between
unlike systems that use totally different encodings for the "special
characters" of your language? Did you know that Kermit handles the
character sets for all these languages, and more?
Let's look at just (say) German. Here are a few of the common *and*
*totally* *different* encodings I can think of for German: German ISO
646, ISO 8859-1 (and -2), IBM PC code pages 437, 850, and numerous
others; IBM Mainframe (EBCDIC) code pages 037, 500, and numerous others;
DEC Multinational, Data General International, Macintosh, Atari, HP
Roman8, NeXTSTEP. Is it the responsibility of every German-speaking
computer user to know all of these character sets and have translation
utilities that work between every pair of them on every kind of computer?
OK, so everybody should speak English and then everything works. But
then what about record formats? Suppose I transfer a text file from a
record-oriented system in binary mode by mistake. I lose the record
boundaries. Suppose it's a BASIC or FORTRAN program, or a poem. Vital
information is lost -- the program won't compile, the poem won't scan.
In an ideal world, computers would have been designed from the beginning
with considerations like this in mind. Imagine how easy all our lives
would be if file systems and organizations and character sets were all
compatible? Then we would have one and only one transfer mode, and it
would always work, and always produce useful results. But this is the
real world, in which nobody can agree on anything, and everyone
proclaims their own way of doing things a "standard".
- Frank
Christian Weisgerber
> It's tempting to conclude that modem data compression renders offline
> compression obsolete. After all, why dedicate CPU time to it if the modem
> will do it just as well?
> There are reasons. [...]
Modems have to do with general purpose compression algorithms. However,
for best compression results you want algorithms adapted to the specific
kind of data an application uses.
I'd rather say:
It's tempting to conclude that offline compression renders modem data
compression obsolete.
--
Christian 'naddy' Weisgerber, Germany na...@mips.ruessel.sub.org
"1. Trust no one. 2. Do it yourself. 3. No excuses."
Bennett Todd
Jim Graham <j...@n5ial.mythical.com> wrote:
>[ 3B2s can't compress as fast as DTE rates ]
Well, 3B2s might be dead, but people still use other toy computers; I've got
a Kaypro II, and TRS-80 model 4P, and an HP-95LX, and a Toshiba T1000XE;
none of these are anywhere near as powerful a computer as my ZyXEL. So yeah,
when your modem has more MIPs than your ``computer'', offload the
compression onto the machine with spare cycles.
On the other hand, I would expect most any Linux system to be able to shove
bytes cross the phone grid faster by compressing with gzip. Maybe it isn't
so clear with a 386SX-16, but these days the minimum PC is a 386DX-40. Of
course, my ZyXEL also has more cycles than my 386DX-40, and my Sun 3/50, but
the ZyXEL is also studiously packing bits down the analog line; I suspect
either of these machines are capable of generating gzipped data faster than
you can push it over a phone line. I oughta test, rather than suspect.
Maybe....
-Bennett
b...@sbi.com
Anthony Rumble
: In article <1994Feb6.1...@n5ial.mythical.com>,
Also.. I think you would find that v.42bis would compress somewhat
better than GZIP on typical text data.
Cetainly CPU cycles/Compression Ratio.. v.42bis comes way out on top.
--
aru...@netcomm.pronet.com NetComm R&D
Anthony Rumble Voice x358 (02) 878-7358 Fax (02) 887-4649