eli@spdcc.COM (Steve Elias) (08/16/88)
i'm finding it impossible to download files from a xenix system with a trailblazer to my lowly PC running procomm with a 2400 baud hayes clone. when i just try to capture files that i 'cat' from xenix, things get horribly jumbled after a screenful or so -- and the rest of the file never gets to my screen or log file. also -- i can't get kermit on xenix to send anything to the kermit inside procomm. any clues would be appreciated. as of now, i have no way to download data at all... (sorry about that anti-DOS tirade a few days ago. sometimes DOS just gets to me. crutches aren't fun, but they can be necessary.)
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/16/88)
In article <1668@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: >also -- i can't get kermit on xenix to send anything to the kermit >inside procomm. any clues would be appreciated. as of now, i have Try mark or space parity.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/17/88)
In article <1668@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes:
:i'm finding it impossible to download files from a xenix system
:with a trailblazer to my lowly PC running procomm with a 2400 baud
:hayes clone.
:
:when i just try to capture files that i 'cat' from xenix, things
:get horribly jumbled after a screenful or so -- and the rest of
:the file never gets to my screen or log file.
:
:also -- i can't get kermit on xenix to send anything to the kermit
:inside procomm. any clues would be appreciated. as of now, i have
:no way to download data at all...
If you can't download files from Unix/Xenix Kermit to Procomm, either
the TrailBlazer is too fast for Procomm or you have a mismatch of Kermit
dialects. ZCOMM and Pro-YAM resolve this automatically when commencing
automatic downloads with Kermit, but you'll have to experiment with
other programs to find the magic combination that works.
If you do get Kermit working between Xenix and Procomm, you may still
want for the speed and flexibility of ZMODEM, supported by the
P.D. Unix/Xenix rz/sz programs and DSZ, ZCOMM, or Pro-YAM on the DOS side.james@bigtex.uucp (James Van Artsdalen) (08/23/88)
In article <11744@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) wrote: > >Kermit is VERY slow on binary files and many versions are > >incompatible. (also the 'super' implementations) > This is just plain wrong as far as I know. The main "incompatability" > problem I know of is different default parity. (Parity is easily > settable in most implementations, and usually can go into an > initialization file.) All versions of kermit are able to transfer > files to each other. Not true. Consider kermit implemented on the "Fido" BBSs. It may work now, but for a long time it did not. > (Unlike XMODEM, YMODEM, ZMODEM, WXMODEM, etc.) This statement makes no sense. If you can find an incompatible version of Zmodem, let's hear about it. The primary problem with Xmodem (and to a lesser extent with Ymodem) is naming: people have a habit of adding features to the protocol and continuing to call it Xmodem. Some people outright used the name Ymodem for protocols that aren't really Ymodem but simply extensions to Xmodem. > A few backward implementations are not able to handle binary files > over 7-bit communications lines. Ah! "All versions of kermit are able to transfer files to each other."? > [..] Kermit does have more overhead than > XMODEM on binary files, about 27% on random binary, less than that on > most real files. This does not seem "VERY" slow in comparison to me. Kermit has more overhead no matter how you measure it. The packets have high overhead, and the implementations have high resource requirements on the host processor. Windowing Kermit tends to have very high overhead. > [...] I have yet to see a > comparison of ZMODEM to windowing kermit from a non-biased source, I > would expect windowing kermit to be about 5% slower on a typical file > mixture. Well, Chuck Forsberg has implemented both - his Pro-YAM does support windowing Kermit. His numbers are likely as accurate if not more so than anyone else's. The 5% range seems a little low to me, but the real price is paid if there are network delays. Doing Kermit over Telenet is an exercise in futility - 25cps or so, whereas Zmodem does 116cps+, just like it would on a local call (no comparison using windowing Kermit, because I don't know anyone who supports it)... -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
richard@neabbs.UUCP (RICHARD RONTELTAP) (08/23/88)
[ Kermit is not so slow and not so incompatible ] Well I've had several kermit's which really wouldn't talk to each other. Maybe just bad implementations. Thay were from old CP/M machines. The VERY slow occures with Kermit's that INSIST on 8th bit qouting. On compressed file that means: ever character with the high bit set (50%) is expanded to '&'+stripped character. Ofcourse every control character need's a '#' PLUS the '&' quoting. PLUS the blok overhead. I've tried it for fun. I used a direct serial connection at 2400 baud, a standard Columbia kermit (nothing sliding, NO 8th bit quoting), some recent DSZ module for ZMODEM. I sent several ARC files and ZMODEM was consistently 2.4 times faster. Imagine the horror with 8th bit quoting.... Richard
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/23/88)
>Kermit has more overhead no matter how you measure it. The packets >have high overhead, and the implementations have high resource >requirements on the host processor. Windowing Kermit tends to have >very high overhead. This is my experience. I do many file transfers from a VAX 11/750. Tests at 9600 baud (nominal) with the same file and same loading conditions show kermit resulting a approximately four times the billed time (cpu time + sys time) of xmodem. Effective transfer rates (measured at the receiving end) are typically about 260 chars/sec with kermit. Ascii file transfers run at 560 chars/sec under the same conditions. I've found kermit so slow and so expensive (plus being so cranky) over my leased line that I can get better and less expensive results by running ascii transfers (base 85 encoded if the source is weird or binary) twice and comparing each transmission or simply compressing the file(s) to be transfferred with zoo or compress and relying on the decompression process to catch munged files which are then retransmitted. By the way, I'm not a programmer, and perhaps should not comment, but the code of ckermit impresses me as one holy rat's nest.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/23/88)
In article <11744@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: :In article <20302@neabbs.UUCP> richard@neabbs.UUCP (RICHARD RONTELTAP) writes: :>I suggest you get the rzsz modules. : :This isn't a horrible idea, but you should be warned that XMODEM based :protocols are sometimes will corrupt the data on a single noise :character, and are picky about the types of systems and communications :equipment they run on. The main point of the rz/sz programs is to support ZMODEM, and ZMODEM does not have any single character failure modes `ala XMODEM, YMODEM, Megalink, Telink, WXMODEM, etc. : :>Kermit is VERY slow on binary files and many versions are :>incompatible. (also the 'super' implementations) : :This is just plain wrong as far as I know. The main "incompatability" :problem I know of is different default parity. (Parity is easily :settable in most implementations, and usually can go into an :initialization file.) All versions of kermit are able to transfer :files to each other. (Unlike XMODEM, YMODEM, ZMODEM, WXMODEM, etc.) Considering all the rewriting I've had to do to the C-Kermit routines to get them to work with various Kermit implementations, I don't think it's accurate to say that all Kermits are compatible. I'd like to know which versions of ZMODEM programs are unable to transfer files with each other, other than those that came out in the first few weeks of ZMODEM's initial launching. :A few backward implementations are not able to handle binary files :over 7-bit communications lines. (XMODEM has no hope of working at :all under these circumstances.) Kermit does have more overhead than :XMODEM on binary files, about 27% on random binary, less than that on :most real files. This does not seem "VERY" slow in comparison to me. :(ZMODEM or WXMODEM is faster than non-windowing kermit, but windowing :kermit is faster than XMODEM or YMODEM.) I have yet to see a On BIX accessed via Telenet, the download speeds of 1K XMODEM and SuperKermit are about the same; SuperKermit's streaming advantage over 1K XMODEM almost makes up for the higher overhead. One may peruse the appropriate "conferences" on BIX to read comments about how ZMODEM performs. :comparison of ZMODEM to windowing kermit from a non-biased source, I :would expect windowing kermit to be about 5% slower on a typical file :mixture. Rather that attacking other's tests, why not run some tests of your own? Be sure to specify the types of files used and other relevant conditions, as is done in the test results shown in ZMODEM.DOC (part of YZMODEM.ARC). :-- :Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu :Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson :Prime mailing list: info-prime-request%ais1@ecla.usc.edu : oberon!ais1!info-prime-request Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" 17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406 TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAF
les@chinet.UUCP (Leslie Mikesell) (08/23/88)
In article <2877@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: >>Kermit has more overhead no matter how you measure it. The packets >>have high overhead, and the implementations have high resource >>requirements on the host processor. Windowing Kermit tends to have >>very high overhead. > >This is my experience. I do many file transfers from a VAX >11/750. Tests at 9600 baud (nominal) with the same file and same >loading conditions show kermit resulting a approximately four >times the billed time (cpu time + sys time) of xmodem. Effective >transfer rates (measured at the receiving end) are typically >about 260 chars/sec with kermit. Ascii file transfers run at 560 >chars/sec under the same conditions. > This is mostly an implementation problem and has been somwhat improved in the current version for at least some flavors of unix. The handling of parity and timeouts is generally inefficient because it is written to work on machines where the efficient modes do not work. The inherint problems of the protocol are: small packet size This is fixed in many current versions but both ends must support it and the user must explicitly request long packets. indeterminate packet size This is the real killer for efficiency on unix. Actual packet sizes are not exactly the agreed-upon size but generally slightly smaller to allow for the quoting mechanism for control characters. This makes it impossible to get a packet in a single system call (or to set the SysV termio parameters to return exactly when the last character is received. At least one version does a signal(), alarm(), setjmp(), and read() for *every* character when parity is set. eighth-bit quoting This can be disabled in most versions but the user must do it explicitly at both ends, except for some versions (unix, at least) where it is tied to the parity setting. >By the way, I'm not a programmer, and perhaps should not comment, >but the code of ckermit impresses me as one holy rat's nest. I have to agree here. Re-writing the tty-specific code so that there were separate versions of ckutio.c for at least three unix variations (v7, BSD & SysIII/V) would help clear up the mass of #ifdefs. Les Mikesell
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/23/88)
alphacm BBS has a copy of a kermit version for xenix which includes the
sliding windows protocol. This makes it run at about 90-92% of max line
speed, with overhead bytes accounting for the rest, I believe.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejohn@jetson.UPMA.MD.US (John Owens) (08/24/88)
In article <2877@ucdavis.ucdavis.edu>, cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: > I've found kermit so slow and so expensive (plus being so cranky) > over my leased line that I can get better and less expensive > results by running ascii transfers (base 85 encoded if the source Well, the key words here are "leased line". This is not where Kermit's strengths lie; Kermit is excellent at transferring files in wierd environments (through cranky data switches, protocol converters, IBM mainframes that speak EBCDIC, satellite links, and combinations of the above). That's why the protocol overhead is so high. I'd still not recommend that you do raw transfers. ZMODEM should be able to approach the maximum speed of your line. -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/24/88)
In article <11949@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >alphacm BBS has a copy of a kermit version for xenix which includes the Access information please.
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (08/24/88)
In article <115@jetson.UPMA.MD.US> john@jetson.UPMA.MD.US (John Owens) writes: >In article <2877@ucdavis.ucdavis.edu>, cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: >Well, the key words here are "leased line". This is not where >Kermit's strengths lie; Kermit is excellent at transferring files in >wierd environments (through cranky data switches, protocol converters, >IBM mainframes that speak EBCDIC, satellite links, and combinations of >the above). That's why the protocol overhead is so high. Unfortunately kermit can't hack my current connection at all. I have a 9600 baud leased line from my ATT 6310 running Xenix (or MSDOS). This goes to the UCD data switch (Develecon) which connects to a variety of machines through Develnet software (Northern Telecom?). This system USED to work until the Develnet software was introduced and the speed of the connection between computing center machines was raised to 38400 baud. Part of the problem may be that kermit on the remote machine sees a baud rate of -1 (no provision of 38.4k). Another problem may be that Develnet makes everything mark parity (or at least the high bit is always on for incoming data to my machine). I have tried (for hours) various combinations of parity and baud rates on both the remote and local kermits. Nothing works. File transfers and remote commands time out. Sometimes the local kermit crashes with a "protocol error." xmodem is broken under this arrangement as well. two versions of MSDOS kermit fail too. Both MSDOS and Xenix Ckermit will work on 1200 baud dialups to the same machines. 9600 baud connections to Berkeley through the same data switch but NOT through the Develnet connection do work although the overhead is VERY high. Any ideas would be deeply appreciated. Also, if kermit does 8-th bit quoting on a need basis it would seem that for transfers over 7-bit paths, base-85 coding (25% expansion) of binary files should result in faster transmission since kermit will always see an ascii input. E H. Kinmonth Hist. Dept. Univ. of Ca., Davis Davis, Ca. 95616 916-752-1636/0776 Disclaimer: What do I know about programming? I teach Japanese history! Internet: ehkinmonth@ucdavis.edu cck@deneb.ucdavis.edu BITNET: ehkinmonth@ucdavis UUCP: {ucbvax, lll-crg}!ucdavis!ehkinmonth {ucbvax, lll-crg}!ucdavis!deneb!cck
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/25/88)
His number changed recently, and information at the old one just says
"no longer connected." I have a message which suggests 714-898-8634 as
the new number, but I have gotten either busy or no answer there, so I
can't swear that it's correct.
If people would like I'll put it on the *IX BBS and set up a uucp
access. Currently non-users have bbs only, and I don't *think* it's in
the UNIX section, although it could be there, too.
If this would be useful, send mail to sysop@sixhub.uucp
(uunet!steinmetz!sixhub!sysop) and say so. I'll post info here.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -meles@chinet.UUCP (Leslie Mikesell) (08/25/88)
In article <2906@ucdavis.ucdavis.edu> cck@deneb.ucdavis.edu.UUCP (Earl H. Kinmonth) writes: >Unfortunately kermit can't hack my current connection at all. I >have a 9600 baud leased line from my ATT 6310 running Xenix (or >MSDOS). This goes to the UCD data switch (Develecon) which >connects to a variety of machines through Develnet software >(Northern Telecom?). This system USED to work until the Develnet >software was introduced and the speed of the connection between >computing center machines was raised to 38400 baud. > >Part of the problem may be that kermit on the remote machine sees >a baud rate of -1 (no provision of 38.4k). Another problem may >be that Develnet makes everything mark parity (or at least the >high bit is always on for incoming data to my machine). > You would have to manually set parity to mark (or do so in the initialization file). Kermits do not automatically agree on the parity setting and will fail if both ends do not match. You must also be able to get a start-of-packet character through the connection (default is CTL-A or SOH). Otherwise everything is forced into the printable character range. >Any ideas would be deeply appreciated. Try turning on the debug and packet logs to see if the SOH is making it through and the parity is being stripped properly. It is also possible that the machine is unable to accept data at 38.4K without losing characters. Mux designers tend to have optimistic theories about incomming data arriving at a typist's speed... >Also, if kermit does 8-th bit quoting on a need basis it would >seem that for transfers over 7-bit paths, base-85 coding (25% >expansion) of binary files should result in faster transmission >since kermit will always see an ascii input. This probably would help if you had matching programs at both ends. Kermit always quotes all control characters except SOH and a terminating CR. If you design something especially for kermit, you should avoid the # and & characters also since they are used for quoting, they must be doubled to act as a normal character. Les Mikesell
kre@munnari.oz (Robert Elz) (08/25/88)
In article <2906@ucdavis.ucdavis.edu>, cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: | Also, if kermit does 8-th bit quoting on a need basis it would | seem that for transfers over 7-bit paths, base-85 coding (25% | expansion) of binary files should result in faster transmission | since kermit will always see an ascii input. If you really want effeciency, the news "encode" and "decode" programs give close to optimal ascii encoding (more or less base 90, about 23% expansion .. that is, they put 13 bits of data in 16 bits transmitted), provided that you don't need newlines, etc, which kermit doesn't. These things are a part of all modern news distributions, they're used with the -c7 sendbatch option. What's more they're totally free, take them and use them anywhere you like (they're simple filters, written in C, and using essentially no OS dependant facilities, they should easily move to anywhere there's a C compiler). kre
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/26/88)
In regard to the performance of several file transfer programs, I
measured the performance on a number of those discussed, and here are
the results. The machines were both unloaded (l.a. < .2) and timing
info was from the accounting file. Note that they are not at all the
same speed machine, so don't compare the sending and receiving CPU
times with each other.
All files were sent from the slow machine to the fast machine, if
anyone can argue that this makes a difference. Since the two kermit
sends were in one process which did a bunch of other stuff on the
sender, no results for the CPU were available.
protocol cps S-cpu R-cpu line%
________________________________________________
kermit 110 n.a. 0.24 45.8 std kermit
swkermit 164 n.a. 0.62 68.3 window kermit
Zmodem 222 3.9 0.12 92.5 rzsz (feb 88?)
uucp7 221 5.0 1.48 92.1 uucp, 7 windows
The uucp figures include the other stuff that uucp does, and CPU may be
way high. I forgot to try X and Y modem, etc.
These are figures for August from uploads and downloads to/from the *IX
BBS during Aug. I make no claims that they are typical, but here they
are. All figures from transfers of 20k or more to reduce the impact of startup.
protocol @2400 @1200 #dnld #upld
________________________________________________________________
Ymodem 200 112 367 48
Zmodem 229 115(a) 45 0
Kermit 140 79 120(b) (b)
(a) there was only ONE use of Zmodem at 1200 baud, this figure may not
be very accurate.
(b) 120 total transfers. I don't lok upload and download for kermit.
(c) not a single use of Xmodem this month!
Anyone is welcome to quote these figures in context, and to draw any
conclusions they want. Since uucp is acceptably fast, and both machines
are usually lightly loaded, and uucp is a nice quick to use command, I
usually use it. If I were using a slow and/or noisy line I would use
zmodem, because it allows me to restart the transfer.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -medavidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/27/88)
In article <2315@munnari.oz> kre@munnari.oz (Robert Elz) writes: | If you really want effeciency, the news "encode" and "decode" programs | give close to optimal ascii encoding (more or less base 90, about 23% | expansion .. that is, they put 13 bits of data in 16 bits transmitted), | provided that you don't need newlines, etc, which kermit doesn't. I'm not sure what you're suggesting here. Why would I want to put a binary file into ASCII when I can move it in binary with kermit? And why not use atob which comes with the compress program (in most archives)? It produces output files about 10% smaller than uuencode. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ttims@watdcsu.waterloo.edu (Tracy Tims) (08/27/88)
I have an encoder/decoder that encodes to base 80, and manages to get a 1:1 compression ratio (or slightly better!) for text. On a stripped binary for vi on a Sun, it expands the file by 10%. It's worse on LZ output, but compress works very well on its output, since my encoder doesn't mangle substrings much. It's based on a previous encoder designed here at Waterloo. It is the heart of a network transmission archiver/format I am designing. It's possible to encode to printable characters much more efficiently than the bit-shifting and stuffing algorithms can. Tracy Tims
kre@munnari.oz (Robert Elz) (08/27/88)
In article <11996@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > I'm not sure what you're suggesting here. Why would I want to put a > binary file into ASCII when I can move it in binary with kermit? If you have an 8 bit data path, you don't. If you have a 7 bit data path (kermit with partiy defined as something other than none) then you win y keeping the data as 7 bit, rather than 8 (kermit's 8 bit quoting isn't optimized for transferring arbitrary binary files). > And why not use atob which comes with the compress program (in most archives)? > It produces output files about 10% smaller than uuencode. I said "encode" not "uuencode". The sole advantage to uuencode is that it is universal, everyone has it. Apart from that it's trash. "Btoa" inserts newlines at regular intervals in its output, so the result looks like a regular text file, which can be mailed, edited, or whatever by anyone's standard tools. Btoa also adds a checksum so corrupted files can be detected (which is extremely useful for files sent through mailers). "Encode" produces a 7 bit only file which is one huge line (actually, not even that, as there's no terminating \n) with even smaller expansion than btoa does .. if all you want is to get 7 bits for kermit with parity, or uucp 'f' protocol, or some other reliable 7 bit only, or 7 bit preferred, transport mechanism, encode does a better job than atob. Since encode comes with the news software, it also exists in most archives. kre
Robert_P_Rubendunst@cup.portal.com (08/30/88)
Try setting either (or both) Kermit's BLOCKCHECK setting to 1 byte. Some C sources for Kermit don't handle 2 byte (maybe 3 byte) checksums if no parity is selected. Procomm has a setup menu , the other Kermit should allow SET BLOCKCHECK 1 or SET BLOCK_CHECK 1. That may get the frog sending those files for you. Bob Rubendunst, Soft Machines (217) 351-7199
terry@wsccs.UUCP (Every system needs one) (08/31/88)
In article <705@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > In article <1668@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes: > :i'm finding it impossible to download files from a xenix system > :with a trailblazer to my lowly PC running procomm with a 2400 baud > :hayes clone. First of all you have several problems if the Trailblazer is configured as shipped. Here is a list of things to do to the Trailblazer: 1) Turn off XON/XOFF flow control from the modem to the computer. This is not negotiable. 2) Turn off XON/XOFF flow control from the modem to the phone line. This, also, is not negotiable. 3) Do not lock the modem speed between the modem and the computer. Since you no longer have flow control, you must have the modems the same speed to be guaranteed to not lose characters unless you modem buffers exceed your Xenix buffers (Xenix buffers are 128 bytes). Note that these could also be a problem with any regular modem over 1200 baud. Here is a list of things to do to your Xenix. They fall into two categories: 1) Port settings when using inferior software: If you are using stupid software, it will not set the port to 8 data bits, no parity, and one stopbit. This is a bummer when using ANY 8 bit protocol (Xmodem, TERM, UUCP). You must perform the appropriate stty before running the software, or better yet, put it in a shell script around it, saving the old modes; better still, buy good software. Programs like UUCP, TERM, and Pro-YAM do not have this problem. 2) things to do if you have a multi-port serial board: If you are running Xenix 2.1.3 or below, make sure that you are running the correct drivers for that version of Xenix. The size of the clist structs changes between revision 2.1.3 and 2.2.0 of Xenix. Multiport boards with new drivers running on old Xenix will not work correctly on saturated data-input channels (such as is seen during file transfer) or vice-versa (old driver on new system). If you are running an anvil systems board, you can not turn off XON/XOFF at the board level. Use another port on a different device. If you are using a Computone (old model) you must modify the /atx/attype file. Set the port to 8 BITS NONE. Get rid of XON, FIXPAR, and NOCHANGE. If you are using an Intellicom (Computone, new model), you have to get rid of the stuff for the port you are using for communication in the /etc/iccontrol file. Contrary to the documentation, things set on ttyi0 effect ttym0, ttyi1 effect ttym1, etc. This includes intelliview, intellikeys, etc. The easiest soloution is to simply use a built-in serial port. > : > :when i just try to capture files that i 'cat' from xenix, things > :get horribly jumbled after a screenful or so -- and the rest of > :the file never gets to my screen or log file. > : > :also -- i can't get kermit on xenix to send anything to the kermit > :inside procomm. any clues would be appreciated. as of now, i have > :no way to download data at all... The 'cat' command fails either due to an unlocked baud rate on your telebit or the fact that Procomm has too small a buffer (it uses the bios rather than talking directly to the chip like a reasonable program. > If you can't download files from Unix/Xenix Kermit to Procomm, either > the TrailBlazer is too fast for Procomm or you have a mismatch of Kermit > dialects. Or you have parity set to 7 e 1 (the default on the Xenix system) and Procomm incorrectly sets itself to 8 n 1 for all transfers. The answer is to use the correct parity and a good program on the DOS end. Note also that the Kermit EOL character should be a linefeed, not a carriage return (the DOS default) if the dialect of Kermit you have cares about line turnaround. > ZCOMM and Pro-YAM resolve this automatically when commencing > automatic downloads with Kermit, but you'll have to experiment with > other programs to find the magic combination that works. > > If you do get Kermit working between Xenix and Procomm, you may still > want for the speed and flexibility of ZMODEM, supported by the > P.D. Unix/Xenix rz/sz programs and DSZ, ZCOMM, or Pro-YAM on the DOS side. Well, I guess I should plug us too, huh? Naaaaawwww. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
terry@wsccs.UUCP (Every system needs one) (08/31/88)
In article <11744@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > In article <20302@neabbs.UUCP> richard@neabbs.UUCP (RICHARD RONTELTAP) writes: > >I suggest you get the rzsz modules. > > This isn't a horrible idea, but you should be warned that XMODEM based > protocols are sometimes will corrupt the data on a single noise > character, and are picky about the types of systems and communications > equipment they run on. Not if they are using a CCITT CRC-16! > >Kermit is VERY slow on binary files and many versions are > >incompatible. (also the 'super' implementations) > > This is just plain wrong as far as I know. The main "incompatability" > problem I know of is different default parity. This is right. > All versions of kermit are able to transfer files to each other. Not true. Try try talking to an IBM 4300 with MS-Kermit 1.0! Not only does the mainframe want turnaround characters that DOS can't provide, but a lot of other things are not there as well! (besides, there are numerous weird implementations -- for instance, I have one in LISP). > This does not seem "VERY" slow in comparison to me. > (ZMODEM or WXMODEM is faster than non-windowing kermit, but windowing > kermit is faster than XMODEM or YMODEM.) Windowing protocols require large buffers... Xenix has 128 bytes of buffer. Windowing protocols on most multitasking operating systems have realtively teeny buffers. The only way that'll work is with some sort of flow control -- either rts/cts or xon/xoff, and xon/xoff requires a non-binary protocol. > I have yet to see a > comparison of ZMODEM to windowing kermit from a non-biased source, I > would expect windowing kermit to be about 5% slower on a typical file > mixture. Actually, I think windowed Kermit is faster by about 8% (from several 10 meg transfers on my equipment). The main problem with a windowed 7-bit protocol is that there is no way to get out of a kernal-mode xoff (alarms are queued around kernal-mode code, and they all go off when you get an xon..) short of putting a timer in the driver. This means you have to handle xoff's in user mode code and this puts you in never-never land if you're swapped out. This means no way to gracefully recover. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
blarson@skat.usc.edu (Bob Larson) (09/15/88)
In article <620@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >In article <11744@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: >> This isn't a horrible idea, but you should be warned that XMODEM based >> protocols are sometimes will corrupt the data on a single noise >> character, and are picky about the types of systems and communications >> equipment they run on. >Not if they are using a CCITT CRC-16! How does CRC-16 in one direction get around the problem of a bogus single-character ack packet sent recived from the other direction? A couple of people have assured me that ZMODEM does not have this problem. >> All versions of kermit are able to transfer files to each other. >Not true. Try try talking to an IBM 4300 with MS-Kermit 1.0! I concede. However, none of the other protocols will work in this case. (At least with kermit, you can get or make a version that will work.) >> (ZMODEM or WXMODEM is faster than non-windowing kermit, but windowing >> kermit is faster than XMODEM or YMODEM.) >Windowing protocols require large buffers... Xenix has 128 bytes of >buffer. So do many non-windowing protocols. Note that XMODEM's packet size exceeds the 128 byte limit you mention. >The main problem with a windowed 7-bit protocol is that there is no way >to get out of a kernal-mode xoff Complain to your OS vendor, this is not realy related to kermit. Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
les@chinet.UUCP (Leslie Mikesell) (09/15/88)
In article <620@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >Windowing protocols require large buffers... Xenix has 128 bytes of >buffer. Windowing protocols on most multitasking operating systems >have realtively teeny buffers. The only way that'll work is with >some sort of flow control -- either rts/cts or xon/xoff, and xon/xoff >requires a non-binary protocol. Don't intelligent serial boards solve this problem? >The main problem with a windowed 7-bit protocol is that there is no way >to get out of a kernal-mode xoff (alarms are queued around kernal-mode >code, and they all go off when you get an xon..) short of putting a >timer in the driver. This means you have to handle xoff's in user mode >code and this puts you in never-never land if you're swapped out. This >means no way to gracefully recover. This is not true for SysVr3 on the 3B2, although I believe it was in some earlier releases. Does anyone know specifically when this bug was fixed so that an alarm() around a write() will bail out if you have received an xoff. As I recall from working with a TRS Model 12 running xenix, either the alarm never happened or the ioctl()s or close() on the line would lock so there was no way to even disconnect. Les Mikesell