adamd@rhi.hi.is (Adam David) (03/28/91)
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? 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? 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. -- Adam David. (adamd@rhi.hi.is)
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/01/91)
The ST shadowing mechanism runs into performance problems when a process does a fork() and keeps running parallel to its child -- the typical application is a terminal emulator. The stterm program uses the 'OS-9 approach', as I would call it: it forks off two children, which exec the reader and the writer. Kermit does it in the standard unix fashion, so it is slow on the ST. C.v.W.
bert@arrakis.nl.mugnet.org (Bert Laverman) (04/02/91)
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. =====================================================================
david@doe.utoronto.ca (David Megginson) (04/04/91)
I have just purchased ST Minix 1.5, and I find both stterm and kermit slooow. There seems to be some kind of serious buffering going on for the RS232 port, so characters do not appear immediately when I have typed them, even though listings, etc. from the host seem to scroll by fast enough. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
ralf@ptavv.ka.sub.org (Ralf Wenk) (04/04/91)
In article <9104021411@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: > ... [Stuff deleted] ... > 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. I have changed the 1.5.10 term(1) and talk(1) to do it the same way on MINIX ST. No special compile option is needed because the changes are triggered only if CHIP is defined as M68000 in <minix/config.h>. If there is enough interest I am willing to post both. -- -- Ralf Wenk -- ralf@ptavv.ka.sub.org
ralf@ptavv.ka.sub.org (Ralf Wenk) (04/05/91)
In article <1991Apr3.203102.24856@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: > I have just purchased ST Minix 1.5, and I find both stterm and kermit > slooow. There seems to be some kind of serious buffering going on > for the RS232 port, so characters do not appear immediately when I have > typed them, even though listings, etc. from the host seem to scroll by > fast enough. With MINIX ST 1.5 you got the MINIX PC 1.3 tty driver. Try to get the patches for MINIX ST 1.5.10.[1-3] from an archive. With 1.5.10.2 you will get the faster MINIX PC 1.5 tty driver and a faster stwini.c too. -- -- Ralf Wenk -- ralf@ptavv.ka.sub.org
wilker@gauss.math.purdue.edu (Clarence Wilkerson) (04/06/91)
I still have the problem with PC 1.5 kermit that it compiles but won't link...I get the asld out of memory error. I have chmem'ed asld to its max of about 50222 bytes. This is with 2 meg ram disk as /tmp, etc. Clarence
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (04/07/91)
In article <9104021411@arrakis.nl.mugnet.org>, bert@arrakis.nl.mugnet.org (Bert Laverman) writes: > In article <2982@krafla.rhi.hi.is>, adamd@rhi.hi.is (Adam David) wrote: (Discussion about kermit deleted) > 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. :-( > > > Greetings, Bert > I don't understand this. Why isn't the ST compiler capable of handling big programs ? Mine seems to .... Andy Michael -- Andy Michael "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton - `House of Cards' Middlesex email: eesrajm@brunel.ac.uk UB7 9PA or Andrew.Michael@brunel.ac.uk
bert@arrakis.nl.mugnet.org (Bert Laverman) (04/08/91)
Ralf Wenk wrote: > I have changed the 1.5.10 term(1) and talk(1) to do it the same way > on MINIX ST. No special compile option is needed because the changes > are triggered only if CHIP is defined as M68000 in <minix/config.h>. > If there is enough interest I am willing to post both. Yoh! Send them around by all means! With any luck Andy might use it for the "standard". :-) Anything to reduce the number of separate versions is a big win!! Greetings, Bert ===================================================================== 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 thermodynamics method: We construct a semi-permeable membrane which lets everything but Lions pass through. This we drag across the desert... =====================================================================
bert@arrakis.nl.mugnet.org (Bert Laverman) (04/10/91)
eesrajm@cc.brunel.ac.uk (Andrew J Michael) wrote: > bert@arrakis.nl.mugnet.org (Bert Laverman) writes: >> Is quite capable of handling a bigger kermit, but the compiler ain't. :-( > > I don't understand this. Why isn't the ST compiler capable of handling big > programs ? Mine seems to .... Ordinarily, this should be the case, but... I guesss you've never actually _looked_ at what Frank produces :-/ His previous attempts for ckermit 5A (say edits 157 to 166) (See part of what I mean? :-() include a truly gigantic switch statement. c68 couldn't handle this even with 300Kb of chmemory, and I couldn't give it any more (just a 1Mb ST :-(). ACK could, so all modules but that one went with c68. However, a full-blown ckermit (meaning: nothing left out) caused ACK to choke on the first file I gave it... Perhaps a 2-Mb ST could solve some of this. I am currently trying to get kermit through your port of gcc (on a sun), which produced a new set of errors for Frank to fix ;-). Greetings, Bert ===================================================================== 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 thermodynamics method: We construct a semi-permeable membrane which lets everything but Lions pass through. This we drag across the desert... =====================================================================
klamer@mi.eltn.utwente.nl (Klamer Schutte) (04/15/91)
In <9104106445@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: >(say edits 157 to 166) (See part of what I mean? :-() include a truly >gigantic switch statement. c68 couldn't handle this even with 300Kb of >chmemory, and I couldn't give it any more (just a 1Mb ST :-(). ACK could, >so all modules but that one went with c68. Wrong! With a 1Meg ST you can run c68 chmem'ed to approx 625 kb. The solution is to throw your ramdisk out (see /usr/include/minix/config.h && /usr/include/minix/boot.h, from memory), don't run anything from the other virtual console (if you have them), and run c68 right from the shell (No make, no cc). You can win another few kb by execing a very small program from /bin/sh, which runs the compiler... I had to do this to compile gnudiff's regexp.c, which is a 32bit-needing very big switch statement. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
bert@arrakis.nl.mugnet.org (Bert Laverman) (04/17/91)
klamer@mi.eltn.utwente.nl (Klamer Schutte) wrote: > bert@arrakis.nl.mugnet.org (Bert Laverman) writes: >>(say edits 157 to 166) (See part of what I mean? :-() include a truly >>gigantic switch statement. c68 couldn't handle this even with 300Kb of >>chmemory, and I couldn't give it any more (just a 1Mb ST :-(). ACK could, >>so all modules but that one went with c68. > Wrong! With a 1Meg ST you can run c68 chmem'ed to approx 625 kb. > [ explanation about how to win memory by throwing out programs deleted ] > I had to do this to compile gnudiff's regexp.c, which is a 32bit-needing > very big switch statement. RAM disk? Let me think... Ah yes, that thing from the floppy version of Minix. ;-) I threw it out ages ago. I currently have an all-minix harddisk, made bootable with that handy program stpart. But anyway, let's not quibble about how to gain a few bytes by throwing out programs. I want programs to compile by running make(1). Call it simplistic, but if you're having trouble getting a program to compile, it's a bother to have to reduce your system to what effectively is a single-user single-task machine in order to get enough memory. Programs running under Minix can count on there not being endless amounts of memory (not couting those versions that use paging/swapping), so I think they ought to have provisions for memory shortage problems. If c68 runs out of memory, it must be because something is deemed worthy of remebering, while there isn't room for it. The usual approach is then to use a temporary file, or use overlays. And don't whine about those solutions! People like the gnu-guys - who write excellent software from time to time - spoil a lot of the fun by simply supposing what amounts to infinite amounts of memory (as compared to my bank account anyway :-(). gnu-as doesn't use temp files anymore (they even threw out the switch that made it a selectable option!), gcc-cc1 needs 2,5 Mb of chmemory (not counting the 500Kb executable) to compile itself, and bash.... well, after loading a shell of 300Kb, the second console is worthless on a 1Mb ST. And if you have something else running (eg in the background), where's the space to do a fork() for the next process???? My trusty ol' TRS-80 Model 4 (4MHz Z80, 128Kb) has an overlayed OS, truly magnificent software (including an ANSI compliant C compiler!), and I usually get amazed remarks from MS-DOS users about it's speed. (ok, ok, up until they started selling 10MHz ATs for half of what I paid for my first TRS ;-)) By the by, back to CKermit: Frank da Cruz promised to cut up that switch, so let's see if we get something that approaches compilableness. Greetings, Bert ===================================================================== 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 thermodynamics method: We construct a semi-permeable membrane which lets everything but Lions pass through. This we drag across the desert... =====================================================================