<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I was doing some more Kermit-20 measurements while I continue to
debug the NRT code.</p>
<p>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.<br>
</p>
<p>I did a transfer of the same file to an iMac and was <i>very</i>
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
<u>increase</u> of 17%. I instrumented Kermit to report the
allocated monitor buffers by line type and got the table below
from various sign ons, viz:<br>
</p>
<blockquote>
<p><font size="5"><tt> TTY line Type: FE PTY NRT TVT CTM</tt><tt><br>
</tt><tt> Input Buffers: 1 1 1 1 1</tt><tt><br>
</tt><tt> Output Buffers: 2 1 2 4 2</tt></font><br>
</p>
</blockquote>
<p>The abbreviations are as follows:</p>
<ul>
<li><font size="4"><tt> FE</tt></font>, Front End (RSX-20F)
terminal (there is only one, CTY)</li>
<li><font size="4"><tt>PTY</tt></font>, Pseudo-terminal</li>
<li><font size="4"><tt>NRT</tt></font>, DECnet Network Remote
Terminal</li>
<li><font size="4"><tt>TVT</tt></font>, Internet Telnet Virtual
Terminal</li>
<li><font size="4"><tt>CTM</tt></font>, DECnet CTERM (I forget
what CTERM abbreviates to)</li>
<li><font size="4"><tt>LAT</tt></font>, Local Area Terminal (I
don't currently have a working transport and client for this)<br>
</li>
</ul>
<p>So what we can see is that a TVT has four <u>times</u> 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.<br>
</p>
<p>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 <b>M</b>Bps
with a 10 microsecond resolution (from first network write to
return from closing the transfer 'socket'). The iMac measured
1.25 <b>M</b>Bps download.<br>
</p>
<p>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.<br>
</p>
<br>
</body>
</html>