Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!mimsy!nocusuhs!nmrdc1!minixug!arrakis!bert From: bert@arrakis.nl.mugnet.org (Bert Laverman) Newsgroups: comp.os.minix Subject: Re: What's wrong with kermit? (ST minix 1.5) Message-ID: <9104021411@arrakis.nl.mugnet.org> Date: 2 Apr 91 08:23:57 GMT References: <2982@krafla.rhi.hi.is> Organization: Alphasoft Nederland Lines: 83 In article <2982@krafla.rhi.hi.is>, adamd@rhi.hi.is (Adam David) wrote: > Howdy all, > So I've joined the minix community and hope I'll not regret it. > Can anyone explain why the kermit in the 1.5 distribution for > Atari ST is so ..s..l..o..w.. as to make it unusable as an online > terminal? Granted, it is slow. But I dare say not entirely unusable! > As I type the characters come back to me after around 2 seconds. > I am connected at 1200 baud full duplex and it behaves like 300 baud > half duplex. The only background job I have running is 'update'. > What's going on here? Well, this is the big 68k blessing called "shadowing". When you give the "connect" command, ckermit does a fork(). And then one of the twin bro's takes input, and the other output. Both processes use the same code segment _and_ the same data segment. Since the data segment is going to be the only difference between the two, this asks for copying back and forth two data segments each time they switch. For this reason, Minix-68k has a second term(1) (on the st called st_term), which - instead of just forking - executes read_tty(1) and write_tty(1). These will be new - separate - images, and therefore need no swapping. This problem could be repaired using non-blocking I/O, which minix doesn't have. :-( :-( (allthough fixes have been posted way back) > It is possible to display files to the screen at full speed but the > response time from sending AT to the modem is ridiculously slow. Don't worry about it. If you look at your modem-leds (if you have those), you'll notice that often data get's sent (or received) a few milliseconds after (before) it was typed (appears on screen). _To my exprience, _nothing_get's_lost!!!_ I have to say though, that kermit's major advantage is with file transfer, not it's terminal capabilities. Since kermit is brought up, let me say something about Frank (da Cruz)'s latest: C-Kermit 5A. The A means Alpha-test version... ;-) C-Kermit 5A incorporates all the new things the book describes[1]. Among these are: - Dynamic packet lengths (depending on line quality) - Advanced server functions - Selective disabling of server functions - Remote printing - Remote mailing - long packets (>>> 96 bytes :-) :-)) - Sliding windows - UUCP style scripts - An extensive macro programming language Etceteraa, etceteraa, etceteraa... Especially those long packets make it - at last - possible for C-Kermit to compete with X/Y/Z-modem protocol programs in throughput. As with all those other wunderful programs that_can_do_a_lot_more (Let's not create bashful reactions by naming examples ;-)) there is a price with the size. A full C-Kermit 5 (ACK compiled) tops 300Kb. Frank is working like hell to find things to throw out in order to let us small system users use kermit, but it's difficult. His first attempt (throw out the interactive part of kermit) _did_ reduce the size, but also the usefullness. :-( His most recent attempt (throw out the programming language, but keep the interactive part) resulted in a text segment of ca. 100Kb (c68 compiled). This sounds hopeful for iNTEL folks. Minix ST Is quite capable of handling a bigger kermit, but the compiler ain't. :-( Anyway, leaving out the Macro programming, C-Kermit 5A seems to work. I'll let y'all know when Frank decides to drop the A (probably to put a B in, but anyway :-)). Greetings, Bert [1]: "KERMIT, A file transfer protocol", Frank da Cruz, Digital Press '87 ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org Molukkenstraat 148 work: laverman@cs.rug.nl 9715 NZ Groningen The Netherlands tel.: +31 50 - 733587 From "How to catch a lion in the desert": The Peano method: In the usual way construct a curve containing every point in the desert. It has been proven that such a curve can be traversed in arbitrarily short time. Now we traverse the curve, carrying a spear, in a time less than what it takes the lion to move a distance equal to it's own length. =====================================================================