home *** CD-ROM | disk | FTP | other *** search
/ GRIPS 2: Government Rast…rocessing Software & Data / GRIPS_2.cdr / dos / ncsa_tel / digests / v2.23 < prev    next >
Text File  |  1990-12-29  |  9KB  |  239 lines
  1.  
  2. NCSA Telnet Digest     Tuesday, May 9, 1989      Volume 2 : Issue 23
  3. --------------------------------------------------------------------
  4. Subjects:
  5.     new beta
  6.     archive server
  7.     speed, speed, speed, votes are in
  8.  
  9. --------------------------------------------------------------------
  10. Version 2.3b3 is now posted on ftp.ncsa.uiuc.edu (128.174.20.50)
  11.     configurable speeds
  12.     Set Transfer Directory is fixed
  13.  
  14. With the new block=4000 parameter, setting the block size to 4000 will
  15. get an effective throughput of 4200 baud in color on a MacIIx, scrolling
  16. the screen (3200 baud with block=120).  If you are paging through more,
  17. or an editor, without scrolling, throughput goes up to 22000 baud.  In
  18. black and white, this hits 41000 baud without scrolling, 14000 with
  19. scrolling.  The number for this parameter is equal to the number of
  20. characters which will be processed before checking for Ctrl-C or other
  21. keyboard interrupts.  Set to 120 for instant Ctrl-Cs.  Measurements
  22. with MacTCP; NCSA's TCP/IP will be slower under MultiFinder.
  23.  
  24. By the way, some incoming mail for the list got misplaced, so if you
  25. have been waiting to see your message, it may appear sometime over
  26. the next couple of digests.  Sorry about the delay.  We seem to be
  27. jinxed in this regard.
  28.  
  29. Tim Krauskopf
  30. NCSA
  31.  
  32. --------------------------------------------------------------------
  33. Date: Mon, 3 Apr 89 21:17:05  +0100
  34. From: <A0061%DK0RRZK0.BITNET@VMD.CSO.UIUC.EDU>
  35. To: telnet@ncsa.uiuc.edu
  36. Subject: Re:  NCSA Telnet Digest V2.21
  37.  
  38. Ok, the first digest for quite some time arived now-
  39.  How about the proposed and expected archive server for NCSA Telnet ?
  40. ..Claus Kalle...
  41.  
  42. [
  43. Ready and waiting...
  44.  
  45.  
  46. Mail to archive-server@ncsa.uiuc.edu with the subject line:
  47.  
  48. subject: help
  49.  
  50. and in the message, the line:
  51.  
  52. index
  53.  
  54.  
  55. and our archive server will respond with instructions on how to
  56. get software vie electronic mail.  Our anonymous FTP server will
  57. be much faster, but for those who don't have FTP access, the 
  58. archive server will deliver our software to you.
  59.  
  60. Tim K]
  61.  
  62.  
  63. --------------------------------------------------------------------
  64.  
  65. Date: Mon, 24 Apr 89 09:41 +1200
  66. From: "Lawrence D'Oliveiro, Waikato University, Hamilton, NZ"
  67.  <CCC_LDO@waikato.ac.nz>
  68. Subject: Re: Telnet 2.3b2 questions
  69.  
  70. * Scrolling speed versus network chunk size
  71.  
  72. Simple answer: make the chunk size a configurable parameter. Then users
  73. can choose the tradeoff to suit themselves.
  74.  
  75. * malloc fragmentation
  76.  
  77. How about not using malloc? Would it involve too much work to use relocatable
  78. blocks? That way you can resize them to hold more or less text, instead of
  79. having lots of smaller, non-relocatable blocks.
  80.  
  81. Lawrence D'Oliveiro
  82. Computer Services Dept
  83. University of Waikato
  84. Hamilton
  85. New Zealand
  86.  
  87. [
  88. I'm not fond of the idea of major surgery right before a release, so
  89. I can oblige with a network buffer size now settable from 100 to 4000
  90. bytes between Ctrl-C checks.  But malloc is indispensible.
  91. Tim K]
  92.  
  93.  
  94. --------------------------------------------------------------------
  95. Date: Mon, 24 Apr 89 09:05:10 CDT
  96. From: brian@natinst.com (Brian H. Powell)
  97. Subject: Re: RFC
  98.  
  99. >To speed it up again, you give up your
  100. >instant Ctrl-C.  Comments?
  101.  
  102.      Speed, Speed, Speed.  I'd happily give up an instantaneous control-C for
  103. substantial performance gains.  I find myself looking at large amounts of data
  104. (for example, system logs, etc.) fairly often.  It's rare that I want to
  105. control-C or even control-Z out of that.  (That's kind of what "more" is for,
  106. anyway.)  I'd rather be able to just zip through that sort of stuff, rather
  107. than know I could stop on a dime.
  108.  
  109. --------------------------------------------------------------------
  110. Date: Mon, 24 Apr 89 08:47:54 -0700
  111. From: brown@lll-crg.llnl.gov (Peter Brown)
  112.  
  113. Hello,
  114.  
  115. I am not a beta test user, but I would vote for fast scrolling (i.e.,
  116. giving up the instant Ctrl-C).  Fast screen updating is a must for me.
  117.  
  118. Peter Brown
  119. Lawrence Livermore National Laboratory
  120.  
  121. --------------------------------------------------------------------
  122.  
  123. Date: Mon, 24 Apr 89 12:24:58 MDT
  124. From: Barbara J. Dyker <dyker%uswest.com@boulder.Colorado.EDU>
  125.  
  126.     One user timed the scrolling speed and found 2.3b2 to be 50% slower
  127.     at printing large amounts of text on the screen than v2.2.  This is
  128.     due to tuning the network access to smaller chunks.  This helps Ctrl-C
  129.     stop the scrolling instantaneously, rather than 20 or 30 lines 
  130.     after you press the key.  To speed it up again, you give up your
  131.     instant Ctrl-C.  Comments?
  132.     
  133. I vote for scrolling speed.  Yes, having to wait for buffers to empty
  134. after typing Ctrl-C is a pain, but 20-30 lines is a reasonable wait.
  135. I never noticed it as a problem in 2.2.  Paging through text is something 
  136. that is MUCH more frequently done than Ctrl-C.
  137.  
  138.  
  139. --------------------------------------------------------------------
  140. From: Rob Chandhok <Ravinder.Chandhok@cs.cmu.edu>
  141. Date: Tue, 25 Apr 89 07:59:50 EDT
  142.  
  143. Hi Tim!
  144.  
  145. Glad to see someone chugging along on Telnet, it was real nice to use the
  146. MacTCP version!  At some point, I am going to port NTP...
  147.  
  148. >One user timed the scrolling speed and found 2.3b2 to be 50% slower
  149. >at printing large amounts of text on the screen than v2.2.  This is
  150. >due to tuning the network access to smaller chunks.  This helps Ctrl-C
  151. >stop the scrolling instantaneously, rather than 20 or 30 lines 
  152. >after you press the key.  To speed it up again, you give up your
  153. >instant Ctrl-C.  Comments?
  154.  
  155. I'd rather have faster display, myself.  Most of the software I use is
  156. display oriented, and page overflow is a *rare* problem.  I noticed it was
  157. slower, also.
  158.  
  159. >
  160. >When you open and close a lot of sessions under 2.3b2, MPW C's malloc
  161. >function tends to fragment memory with all of the lines of scrollback.
  162. >This can get so bad as to force you to quit the program and restart
  163. >it to get enough memory to open another connection.  Does anyone
  164. >have a malloc for MPW C 2.0 which may work better?  Am I imagining
  165. >this problem?
  166.  
  167. MPW malloc is just a call to newptr, I think.  You would do better to call
  168. one big newptr, and then just manage a free list of lines yourself.  That is
  169. a standard thing to do to avoid malloc, even on Unix.
  170.  
  171. >
  172. >This is the time to speak up if you are dissatisfied with the fixes in
  173. >the current beta version.  The things on my list to fix are:
  174. >Double-click on config.tel doesn't work right.
  175. >Don't try to create Settings file in AppleShare server (bug).
  176. >Commandkeys=no should set the flag in the preferences box correctly.
  177. >Password file can be in the system folder like config.tel.
  178. >Try to fix Set Transfer Directory to work on empty folders.
  179.  
  180.  
  181. Please add:
  182.  
  183. -Don't make ^S and ^Q do control flow by default, it was a surprise to me.
  184. Or make it a preference item.
  185.  
  186. -an explanation of why the application is hardly smaller, even when using
  187. the mactcp driver!
  188.  
  189.  
  190. Thanks!
  191. rob
  192.  
  193. [
  194. The application is only slightly smaller because the client version
  195. of TCP/IP that we support compiles to 10-15K.  The parameter block
  196. setups for MacTCP take 50-80% of that much space.  A lot of the
  197. network overhead, like config.tel processing and background FTP must be
  198. retained even with MacTCP.  We could eventually strip all of the 
  199. name server and background FTP stuff, but I don't like pulling
  200. working code.
  201. Tim K.]
  202.  
  203. --------------------------------------------------------------------
  204. Date: Tue, 25 Apr 89 11:50:00 EDT
  205. From: arm@aqua.whoi.edu
  206.  
  207. Hi,
  208. Thanks for NCSA_Telnet, I think its great.  I have been running the beta
  209. release for the past two days and have some comments.
  210.  
  211. (1)  I like the quick acting ^S ^Q ^C sequeces and am willing to
  212.      accept the slow scrolling.  However, I would be interested in
  213.      not slowing down the Tektronix plots if possible.  People here
  214.      like quick plots.
  215.  
  216. (2)  What is making the smaller chunks.  Is it possible that a per-session
  217.      (or even per program activation) parameter be available to
  218.      set this chunksize?  I would also hope that the smaller chunks
  219.      are not negotiated for FTP sessions as well!
  220.  
  221. (3)  Lots of people here will be interested in the color support,
  222.      particularly if it supports Tek 4100 series capabilities.
  223.  
  224. Again, thanks for NCSA Telnet.  If you have a chance to respond couls
  225. you please define "smaller chunks" for me?  Negotiated TCP window
  226. size, MTU size, ...???  Thanks.
  227.  
  228. --Andy Maffei
  229.   Data Communication Supervisor
  230.   Woods Hole Oceanographic Institution
  231.  
  232. [
  233. FTP is independent.  The block size, set by the new block=120 parameter
  234. in config.tel controls the number of characters to write to the screen
  235. between checks for Ctrl-C and other background operations.
  236. Tim K]
  237.  
  238.  
  239.