GRIPS 2: Government Rast…rocessing Software & Data/GRIPS_2.cdr/dos/ncsa_tel/digests/v2.23

Text File | 1990-12-29 | 8.6 KB | 239 lines

NCSA Telnet Digest     Tuesday, May 9, 1989      Volume 2 : Issue 23
--------------------------------------------------------------------
Subjects:
    new beta
    archive server
    speed, speed, speed, votes are in

--------------------------------------------------------------------
Version 2.3b3 is now posted on ftp.ncsa.uiuc.edu (128.174.20.50)
    configurable speeds
    Set Transfer Directory is fixed

With the new block=4000 parameter, setting the block size to 4000 will
get an effective throughput of 4200 baud in color on a MacIIx, scrolling
the screen (3200 baud with block=120).  If you are paging through more,
or an editor, without scrolling, throughput goes up to 22000 baud.  In
black and white, this hits 41000 baud without scrolling, 14000 with
scrolling.  The number for this parameter is equal to the number of
characters which will be processed before checking for Ctrl-C or other
keyboard interrupts.  Set to 120 for instant Ctrl-Cs.  Measurements
with MacTCP; NCSA's TCP/IP will be slower under MultiFinder.

By the way, some incoming mail for the list got misplaced, so if you
have been waiting to see your message, it may appear sometime over
the next couple of digests.  Sorry about the delay.  We seem to be
jinxed in this regard.

Tim Krauskopf
NCSA

--------------------------------------------------------------------
Date: Mon, 3 Apr 89 21:17:05  +0100
From: <[e-mail]>
To: [e-mail]
Subject: Re:  NCSA Telnet Digest V2.21

Ok, the first digest for quite some time arived now-
 How about the proposed and expected archive server for NCSA Telnet ?
..Claus Kalle...

[
Ready and waiting...


Mail to [e-mail] with the subject line:

subject: help

and in the message, the line:

index


and our archive server will respond with instructions on how to
get software vie electronic mail.  Our anonymous FTP server will
be much faster, but for those who don't have FTP access, the
archive server will deliver our software to you.

Tim K]


--------------------------------------------------------------------

Date: Mon, 24 Apr 89 09:41 +1200
From: "Lawrence D'Oliveiro, Waikato University, Hamilton, NZ"
 <[e-mail]>
Subject: Re: Telnet 2.3b2 questions

* Scrolling speed versus network chunk size

Simple answer: make the chunk size a configurable parameter. Then users
can choose the tradeoff to suit themselves.

* malloc fragmentation

How about not using malloc? Would it involve too much work to use relocatable
blocks? That way you can resize them to hold more or less text, instead of
having lots of smaller, non-relocatable blocks.

Lawrence D'Oliveiro
Computer Services Dept
University of Waikato
Hamilton
New Zealand

[
I'm not fond of the idea of major surgery right before a release, so
I can oblige with a network buffer size now settable from 100 to 4000
bytes between Ctrl-C checks.  But malloc is indispensible.
Tim K]


--------------------------------------------------------------------
Date: Mon, 24 Apr 89 09:05:10 CDT
From: [e-mail] (Brian H. Powell)
Subject: Re: RFC

>To speed it up again, you give up your
>instant Ctrl-C.  Comments?

     Speed, Speed, Speed.  I'd happily give up an instantaneous control-C for
substantial performance gains.  I find myself looking at large amounts of data
(for example, system logs, etc.) fairly often.  It's rare that I want to
control-C or even control-Z out of that.  (That's kind of what "more" is for,
anyway.)  I'd rather be able to just zip through that sort of stuff, rather
than know I could stop on a dime.

--------------------------------------------------------------------
Date: Mon, 24 Apr 89 08:47:54 -0700
From: [e-mail] (Peter Brown)

Hello,

I am not a beta test user, but I would vote for fast scrolling (i.e.,
giving up the instant Ctrl-C).  Fast screen updating is a must for me.

Peter Brown
Lawrence Livermore National Laboratory

--------------------------------------------------------------------

Date: Mon, 24 Apr 89 12:24:58 MDT
From: Barbara J. Dyker <[e-mail]>

    One user timed the scrolling speed and found 2.3b2 to be 50% slower
    at printing large amounts of text on the screen than v2.2.  This is
    due to tuning the network access to smaller chunks.  This helps Ctrl-C
    stop the scrolling instantaneously, rather than 20 or 30 lines
    after you press the key.  To speed it up again, you give up your
    instant Ctrl-C.  Comments?

I vote for scrolling speed.  Yes, having to wait for buffers to empty
after typing Ctrl-C is a pain, but 20-30 lines is a reasonable wait.
I never noticed it as a problem in 2.2.  Paging through text is something
that is MUCH more frequently done than Ctrl-C.


--------------------------------------------------------------------
From: Rob Chandhok <[e-mail]>
Date: Tue, 25 Apr 89 07:59:50 EDT

Hi Tim!

Glad to see someone chugging along on Telnet, it was real nice to use the
MacTCP version!  At some point, I am going to port NTP...

>One user timed the scrolling speed and found 2.3b2 to be 50% slower
>at printing large amounts of text on the screen than v2.2.  This is
>due to tuning the network access to smaller chunks.  This helps Ctrl-C
>stop the scrolling instantaneously, rather than 20 or 30 lines
>after you press the key.  To speed it up again, you give up your
>instant Ctrl-C.  Comments?

I'd rather have faster display, myself.  Most of the software I use is
display oriented, and page overflow is a *rare* problem.  I noticed it was
slower, also.

>
>When you open and close a lot of sessions under 2.3b2, MPW C's malloc
>function tends to fragment memory with all of the lines of scrollback.
>This can get so bad as to force you to quit the program and restart
>it to get enough memory to open another connection.  Does anyone
>have a malloc for MPW C 2.0 which may work better?  Am I imagining
>this problem?

MPW malloc is just a call to newptr, I think.  You would do better to call
one big newptr, and then just manage a free list of lines yourself.  That is
a standard thing to do to avoid malloc, even on Unix.

>
>This is the time to speak up if you are dissatisfied with the fixes in
>the current beta version.  The things on my list to fix are:
>Double-click on config.tel doesn't work right.
>Don't try to create Settings file in AppleShare server (bug).
>Commandkeys=no should set the flag in the preferences box correctly.
>Password file can be in the system folder like config.tel.
>Try to fix Set Transfer Directory to work on empty folders.


Please add:

-Don't make ^S and ^Q do control flow by default, it was a surprise to me.
Or make it a preference item.

-an explanation of why the application is hardly smaller, even when using
the mactcp driver!


Thanks!
rob

[
The application is only slightly smaller because the client version
of TCP/IP that we support compiles to 10-15K.  The parameter block
setups for MacTCP take 50-80% of that much space.  A lot of the
network overhead, like config.tel processing and background FTP must be
retained even with MacTCP.  We could eventually strip all of the
name server and background FTP stuff, but I don't like pulling
working code.
Tim K.]

--------------------------------------------------------------------
Date: Tue, 25 Apr 89 11:50:00 EDT
From: [e-mail]

Hi,
Thanks for NCSA_Telnet, I think its great.  I have been running the beta
release for the past two days and have some comments.

(1)  I like the quick acting ^S ^Q ^C sequeces and am willing to
     accept the slow scrolling.  However, I would be interested in
     not slowing down the Tektronix plots if possible.  People here
     like quick plots.

(2)  What is making the smaller chunks.  Is it possible that a per-session
     (or even per program activation) parameter be available to
     set this chunksize?  I would also hope that the smaller chunks
     are not negotiated for FTP sessions as well!

(3)  Lots of people here will be interested in the color support,
     particularly if it supports Tek 4100 series capabilities.

Again, thanks for NCSA Telnet.  If you have a chance to respond couls
you please define "smaller chunks" for me?  Negotiated TCP window
size, MTU size, ...???  Thanks.

--Andy Maffei
  Data Communication Supervisor
  Woods Hole Oceanographic Institution

[
FTP is independent.  The block size, set by the new block=120 parameter
in config.tel controls the number of characters to write to the screen
between checks for Ctrl-C and other background operations.
Tim K]