SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (01/24/86)
Info-Kermit Digest Fri, 24 Jan 1986 Volume 4 : Number 6
Today's Topics:
Windows over Telenet
TIMINGS
Frogs in Space
Problems/suggestions with/for M24-Kermit
Workaround for VMS V3.7 vs. LAT-11 vs. MSKERMIT V2.28jrd ...
More on Tandem's running Guardian
Is anyone running HP3000 Kermit?
MODEM7/MEX/KERMIT for UTS-30?
Ti kermit H19 Question
----------------------------------------------------------------------
Date: Fri 24 Jan 86 13:46:21-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Windows over Telenet
Below are the results of a test done using WKERMIT.EXE (C-Kermit with windows
for MS-DOS). Both an .EXE and a .TXT file were transferred. The speed in all
cases was 1200 baud and mark parity was used, which in turn causes 8th-bit
prefixing in the .EXE file. The packet size was 90. This was done at 5:30PM
on a weekday. The typical network delay was 1-2 seconds (strictly a guess
based on watching modem lights). Columns A and B show file transfers between
an IBM AT and 'The SOURCE', using a Hayes modem over Telenet; Column A is from
the IBM AT to 'The SOURCE' and Column B is the other direction. Column C shows
the time it took to send those files from 1 IBM AT to another. The first time
shown in each column is the result without windowing; the second time shown (in
parenthesis) is the result using a window size of 16. This test shows a 2-3
fold improvement in speed when windowing is used over Telenet.
File File Elapsed time to transfer at 1200b, in mins:secs;
Name Length
A B C
MSKERMIT.HLP 9371 4:15(1:35) 3:04(1:35) 1:45*(1:30)
SHARE.EXE 8896 7:50(2:30) 7:00(2:40) 1:45*(1:30)
* No matter how hard we tried we could not make WKERMIT work between 2
directly conncted PC/ATs. These numbers are estimates.
------------------------------
DATE: 24-JAN-1986
FROM: BRIAN@UOFT02
SUBJECT: TIMINGS
Some sample timings for Kermit-11 and long packet support. The packet
size in the RSTS/E to P/OS was 500 bytes, the size from RSTS/E to
RSTS/E was 700 bytes. These sizes are somewhat arbitrary, they depend
more on the system's buffering capabilities than anything else.
Host buffering capabilities:
P/OS 500 (estimated)
RSTS/E 9.0 or later up to 7000, given sufficient system pool
RSX11M+ 255 (I/D space CPU only)
RSX11M 34
RT11 134 (could be larger with simple mod to XC/XL)
As it can be seen, large packets make sense only for RSTS/E, P/OS and
RSX11M+ if one wishes to avoid XON/XOFF overhead at high speeds. It
should be possible to run larger packets on M+ and RT11 at lower
speeds.
File transfered: K11POS.TSK, size 102,400 bytes (200 disk blocks)
Actual data packet characters AFTER prefixing was 120,857
Time Speed Data rate Comments
seconds baud
1436 1200 84/sec 11/44 to PRO/350, 'Classic' Kermit
local phone call
1237 1200 97/sec 11/44 to PRO/350, 500 Char packets
local phone call
2915 1200 41/sen 11/44 to PRO/350, 'Classic' Kermit
local call, 1 second ACK delay.
1492 1200 81/sec 11/44 to PRO/350, 500 Char packets
local call, 1 second ACK delay.
304 9600 397/sec 11/44 to 11/44, 'Classic' Kermit,
connected locally via Gandalf switch.
245 9600 493/sec 11/44 to 11/44, 700 char packets,
connected locally via Gandalf switch.
The last two timings are much lower than the line speed due to the
fact the the PDP 11/44 is running 100% busy trying to keep up with
character interupts using a normal terminal driver. A special purpose
driver, such as the XK driver found on P/OS, would have lower overhead
and allow somewhat faster data rates.
Long packets were chosen for Kermit-11 due to the lack of suitable
interupt driven i/o (at this time) under one of the operating systems,
RSTS/E. The Sliding windows would likely function better in those
situations where the circuit delay is much higher, or when the circuit
can not accomodate large packet sizes.
brian nelson
[Ed. - The long packet specification is in KER:KPROTO.UPD]
------------------------------
Date: 23 January 1986, 16:38:18 SET
From: Richard J Waite (06151) 886488 C0 at DDAESA10
VM/CMS S.P.O.D
European Space Operations Centre
Robert Bosch Str 5
6100 DARMSTADT, West Germany.
Subject: Frogs in Space
Good Day,
For interest only, the little green chap is now helping in
the joint USA - European - USSR "Giotto" project. The data from the
USSR satellite's is being sent from Moscow to us here at Darmstadt
by means of "Kermit". This data is being used by us and also a USA
university. We are using the Turbo pascal Kermit over there on an
IBM clone at 4800. He is doing very well.
Regards.
------------------------------
Date: January 24, 1986, 12:40 CET
FROM: <#D15%DDATHD21.BITNET@WISCVM.WISC.EDU>
Subject: Problems/suggestions with/for M24-Kermit
Hi,
I've build M24-Kermit from the assembler sources and I've
got some problems:
1.) In module MSYM24.ASM the symbol LNWRAP is defined. This
symbol is also defined in MSDEFS.H. To compile MSYM24 I've
commented out the definition line for LNWRAP in MSYM24.ASM.
(the definitions in the two files are different).
2.) The delete key (<--) does not work in kermits' command mode.
When I type DEL nothing happens. When I repeat typing DEL the
whole line disappears. In terminal emulation mode the DEL key
works perfect.
3.) I can reproduce the scrolling problem in VMS/Phone reported
earlier this week.
4.) I would prefer to have the ALT/CTRL/F2 active at initalization
time (see also 5.). Is it possible to do the keyboard mapping
on a dynamic basis. In this case you can have your standard
keyboard driver outside of Kermit and a VT100-like driver
when using Kermit.
5.) This is a suggestion rather than an problem. We have the
german keybord (type 2) and it would be great to have the
modified keyboard driver for this type of kb.
a.) I would be happy to patch the standard KEYBGR.COM
if someone could tell me what exaxtely is to do.
b.) I would send a hexified version to KERMSRV.
c.) Is there anywhere a description (with sources) of
a keyboard driver (I know it's the wrong list, but...)?
Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: #D15 at DDATHD21 (the number sign is really
part of my UID)
------------------------------
Date: 21-Jan-1986 2320
From: g_hafner%wookie.DEC@decwrl.DEC.COM (SKIN THE BEARS!!!)
Subject: Workaround for VMS V3.7 vs. LAT-11 vs. MSKERMIT V2.28jrd ...
After poking/playing around with all kinds of parameters on both our LAT-11
terminal and our VMS V3.7 system from a Rainbow running MSKERMIT V2.28jrd, and
trying all the suggestions that Frank sent to me (thanx, by the way), the only
solution to all those LAT terminal overruns is to turn down the baud rate on
the Rainbow's comm port, and subsequently the LAT terminal speed as well, to
4800 baud (I had been receiving lots of re-xmit's and buffer overruns on the
LAT line at 9600, more often than not causing the transfer to fail, or else get
roughly one re-transmit for every packet sent- yuucchhhh!!). However, this
behavior does NOT appear when using the same Rainbow, MSKERMIT, LAT port, and a
VMS V4.2 system. THAT works just fine. I have a feeling that VMS V4.2 has a
lot more intelligence built into its handling of the LAT than VMS V3.7 does.
Please note, for all those that sent possible fixes, that the LAT
involved here is not a DECSA (or Pluto box as it's sometimes called), nor
is it a DECserver-100; it's "LAT-11", which runs on a Unibus-based -11
with DZ11's, a DEUNA, and 128KW of memory. In this software, you cannot
modify or change flow control; you're stuck with it (maybe to make writing
the application easier?). Turning HOSTSYNC off had helped a bit for a while
on the VMS V3.7 machine, until the machine being used had its LTDRIVER up-
graded to the proper level. Once that happened, turning off HOSTSYNC was
FATAL (i.e., 2 packets get sent, then a timeout occurs), but leaving it on
displayed the same behavior as it did before the LTDRIVER was upgraded.
Hope this helps anyone getting bitten by this combination.
Gerry Hafner, DEC LTN (Littleton, MA)
UUCP: {decvax|ihnp4|allegra|ucbvax|...}
!decwrl!dec-rhea!dec-wookie!hafner
ARPA: hafner%wookie.DEC@DECWRL.DEC.COM
------------------------------
Subject: More on Tandem's running Guardian
Date: 23 Jan 86 14:43:43 CST (Thu)
From: ...decvax!pur-ee!isrnix!pugsly
...ihnp4!inuxc!isrnix!pugsly
Since I have sent that to you I have talked to the local Tandem sales office
and from what there salesman tells me... "If it was written in TAL for a
non-stop then it will run on the EXT Tandem under Guardian". He was in sales
though :-) .
Thanks again!
David A. Roth
------------------------------
Date: Thu, 23 Jan 86 15:55:42 pst
From: amdcad!amdimage!cmoore@ucbvax.berkeley.edu (chris moore)
Subject: Is anyone running HP3000 Kermit?
I have been trying to get HP3000 Kermit running, and so far
haven't had any luck. In the Connect mode, kermit will
accept a line of input, send it out, and then do a read
to get the response back from the other system. The read
always either timesout with nothing read, or it never returns
at all and kermit hangs. Is anyone running this version of
Kermit that could give some pointers as to what I may be doing
wrong? Thanks.
Chris Moore
amdimage!cmoore
------------------------------
Date: Thu, 23 Jan 1986 23:54 MST
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject: MODEM7/MEX/KERMIT for UTS-30?
I have a number of users in need of a MODEM7/MEX/KERMIT already
configured on a floppy disk for use on a UTS-30 system running CP/M
3.0. For one user, the need is urgent. He has been trying in vain to
upload a file for the last month using Sperry's TTY program, and that
file is a report that is growing daily!
Please contact me directly via net mail, or call my office and leave
your name and number and I will return your call.
Thanks,
Frank
AV: 258-6257
FTS:898-6257
505-678-6257
------------------------------
From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV
Date: Wed Jan 22 11:23:45 EST 1986
Subject: Ti kermit H19 Question
I am running my TI PRO to access my UN*X sys III system and am
having trouble with the h19 emulation. All works well execpt
for the reverse video. When my screen should go into
reverse video, nothing changes. Here is the /etc/termcap
entry I use:
# entry for h19 emulation under TI kermit version 2.28 Revision 5
kb|h19|heath|h19-b|heathkit|heath-19|z19|zenith|heathkit h19:\
:cr=^M:do=^J:nl=^J:bl=^G:\
:al=1*\EL:am:le=^H:bs:cd=\EJ:ce=\EK:cl=\EE:cm=\EY%+ %+ :co#80:dc=\EN:\
:dl=1*\EM:do=\EB:ei=\EO:ho=\EH:im=\E@:li#25:mi:nd=\EC:as=\EF:ae=\EG:\
:ms:ta=^I:pt:sr=\EI:se=\Eq:so=\Ep:up=\EA:vs=\Ex4:ve=\Ey4:\
:kb=^h:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\EH:kn#8:\
:k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:\
:l6=blue:l7=red:l8=white:k6=\EP:k7=\EQ:k8=\ER:
Anyone see any faults with this? I DO have heath 19 on (Just
eliminating the obvious question -:). Or does kermit h19
not support reverse video? Thanks to all who helped me with
my last TI problem. Please mail replies to uucp(1) and+or the
digest.
UUCP: (1) seismo!dolqci!irsdcp!scsnet!sunder (202) 634-2529
(2) decvax!philabs!ubbs!sund (voice)
CIS: 74026,3235
Mail: IRS 1111 Constitution Ave. NW PM:S:D:NO
Washington, DC 20224 Atten: Mark E. Sunderlin
------------------------------
End of Info-Kermit Digest
*************************
-------