home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,310 of 4,255   
   antispam@math.uni.wroc.pl to muta...@gmail.com   
   Re: ATDE   
   18 Jun 21 03:35:05   
   
   muta...@gmail.com  wrote:   
   > On Friday, June 18, 2021 at 10:14:22 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > connector. He also said that transmissin was   
   > > via interrupts and that "IBM does not like   
   > > interrupts". I take this to mean that each   
   > > character triggered a separate interrupt.   
   > > My guess is that the guy connected "external   
   > > interrupt" line (which IIUC is standard thing   
   > > for IBM processors) to parallel-port style   
   > > connector so that modem could interrupt the   
   > > mainframe. Concerning "IBM does not like   
   > > interrupts": transmiting one character per   
   > > interrupt was horribly inefficient by IBM   
   > > standards. Since this was single line, there   
   > > was no problem. But the machine had probably   
   > > about 80 terminals connected using standard   
   > > IBM interfaces. Running 80 terminals in   
   > > async mode probably would not work (I mean   
   > > running in hacky way without something   
   > > like 3705).   
   >   
   > I would hope that after 30 years (or whenever you were   
   > doing this) of technology improvement that mainframes   
   > can now cope with 80 terminals where previously they   
   > could only do 1. I wonder what percentage of a modern   
   > z/Arch CPU would be consumed coping with 80 monkeys   
   > banging away on keyboards as fast as they can, with   
   > each keystroke causing an interrupt.   
      
   Note that I wrote "character", not a keystroke.  Most   
   people can not type faster than 10 cps and most of   
   the time will type slower.  So 80 persons will   
   generate on average probably less than 200-300 keystrokes per   
   second.  But characters include system answers, which   
   typically are much larger.  And file transfers   
   where as fast as link would allow (something like   
   480 cps or 960 cps).  Some of terminals were PC with   
   3270 interface, they could tranfer files rather   
   fast.   
      
   To put this differently, on 386 with its standard dumb   
   serial port it was quite possible to lose charaters   
   at higher transmission speeds because CPU was too slow   
   to handle interrups on time.  Certainly such machine   
   would be overlowded by 30 standard dumb serial ports.   
   OTOH 386 machine generously equipped with memory (which   
   probably meant 16MB) was able to handle about 30-40   
   students connected via telnet and editing/compiling C   
   programs.  Telnet transmits each keystroke separately   
   (in separate network packet) and normally keystrokes   
   were echoed by application (shell or editor) running on   
   386.  So you got process switch and packet with echo.   
   Each packet were acknowledged so there were 2   
   acknowledgments.  Normally one acknowledgment was   
   carried by echo packet, so there were 3 packets   
   per keystroke.  Looks like a lot of activity, but   
   machine could handle it.  However, opening file in editor   
   or paging trough file would cause screen redraw which   
   probably went in two packets.  With dumb async link   
   screen redraw means 2000 interrupts.   
      
   Coming back to mainframes, 3705 (maybe 2 or 3 for faster lines)   
   could easily handle 80 async lines.  I pretty sure that   
   limitation of line or 3270 mode was mostly software one.   
   That is hardware had enough CPU power enough to handle   
   input in character mode.   Tricky thing is memory, in   
   3270 mode mainframe discs were fast enough to swap in/   
   swap out user VMs when needed.  In line mode there   
   are more context switches, so more disc trafic.   
   Character-by-character is worse, probably 50-100   
   times as many context switches as in 3270 mode.   
   100 times as many context switches means more/faster   
   discs or enough real memory to keep all active code   
   and data in RAM.   
      
   Of course, with modern machines 80 users should be no   
   problem.  But if you pay for z/Arch machine you   
   probably want more from it.  Several years ago   
   IBM reported that is z/Arch machine handled 100000   
   web server hits pers second.  For traditional   
   mainframe app that would mean generating 100000   
   screens per second.  Typical expectation is that   
   user will want new screen on average once per 30   
   seconds.  That means that this machine could   
   handle 3000000 users simultaneously.  If you have   
   smaller number of simultaneous users, say 10000   
   than PC class machine will do.  But you need to   
   program your system in efficient way.  Allow   
   waste and you may have trouble with 50 users.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca