[HECnet] Tops-20 Terminal Buffers?

[Thomas DeBellis]

I was doing some more Kermit-20 measurements while I continue to debug 
the NRT code.

Again, the fastest transfer rate that I could get out of a loopback 
pseudo-terminal connection was 129.16 KBps with a packet size of 140 
characters (note previous post was in baud) .  Since this is not going 
outside of the PDP-10, one assumes that it would either be the top speed 
possible or near it as we are just talking shuttling data between buffers.

I did a transfer of the same file to an iMac and was /very/ surprised to 
find that I got 4,000 byte packet size and a transfer rate 151.78 KBps.  
That's right, using the NI resulted in a speed _increase_ of 17%.  I 
instrumented Kermit to report the allocated monitor buffers by line type 
and got the table below from various sign ons, viz:

       TTY line Type:   FE   PTY  NRT  TVT  CTM
       Input Buffers:    1    1    1    1    1
       Output Buffers:   2    1    2    4    2

The abbreviations are as follows:

  *   FE, Front End (RSX-20F) terminal (there is only one, CTY)
  * PTY, Pseudo-terminal
  * NRT, DECnet Network Remote Terminal
  * TVT, Internet Telnet Virtual Terminal
  * CTM, DECnet CTERM (I forget what CTERM abbreviates to)
  * LAT, Local Area Terminal (I don't currently have a working transport
    and client for this)

So what we can see is that a TVT has four _times_ the buffers to play 
with than the PTY.  I don't currently know how large a terminal buffer 
is nor what else this might mean, but it is suggestive.

For what it's worth, I also did comparison with FTP.  A data transfer in 
the RFC959 paradigm is acknowledged on the control channel with return 
code of 226.  There are no acknowledgements of the data channel; it's a 
straight fire hose.  As I expected, an FTP transfer blew Kermit right 
out of the water.  For the same sized file, the 20 measured an upload 
data rate of 1.09 *M*Bps with a 10 microsecond resolution (from first 
network write to return from closing the transfer 'socket').  The iMac 
measured 1.25 *M*Bps download.

So it would appear that an FTP transfer is about 7.38 times faster, 
which is of interest, but otherwise perhaps irrelevant as they are not 
even remotely doing the same thing.  One expects the same result for 
DAP, once I get FTP up on that transport.  Again, we're not comparing 
apples to apples.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211114/f12907a1/attachment.htm>