🚀 go-pugleaf

From article <19458@smoke.brl.mil>, by gwyn@smoke.brl.mil (Doug Gwyn):
>>Doug, do you have any evidence that context-switch overhead is truly
>>significant?
> 
> I have both xt and pty versions of layers running on a VAX-11/780 under
> 4.3BSD, and the pty version has noticeably reduced throughput.  When I
> investigated this some time ago I concluded that it was explained by
> context-switch overhead.

Can you tell me anything about the methods of your investigation? I'd
like to make sure it was a fair comparison.  When you're talking about
throughput then you're talking about full packets so there doesn't need
to be a context switch on every character, only on each packet.  That
should help matters. 

Today's pseudo tty version of layers on Suns has just as good of 
throughput to a 730+ as any xt-driver based layers I've seen (except 
the new streams layers when it is using larger packet sizes and/or 
network XT protocol and I expect that when that is added to the pseudo 
tty layers it will see just as much speed-up).  The only thing I 
haven't properly compared is how much of a load the pseudo-tty layers 
puts on a CPU compared to an xt-driver based layers when there are a 
lot of terminals active.

Probably the fact that a Sparc is so much faster than a VAX11/780
has something to do with the better throughput as well.

>>... I maintain that pty-based layers are so superior to xt-driver
>>based layers that they're worth the extra context switches.
> 
> The biggest problem with xt seems to be the difficulty of porting it.
> Ptys have one big problem in that only a single byte of ioctl information
> can be passed over the pty.  Streams seem like the best way to go, but I
> don't have access to a streams implementation of layers to try out.

And many pty implementations don't even support the one single byte of
ioctl information (the TIOCUCNTL) or have bugs in the support.  I have
modified the pseudo tty layers so that it has a #ifdef to skip
using that feature and to instead pass information through the socket
that layers creates for listening for agent calls.
 
>>I have also seen hosts that had very poor serial port drivers with
>>very slow turn-around time drag down layers throughput.
> 
> I recently was moved to an Annex terminal server and found that layers
> operation has significantly reduced throughput when funneling the data
> through this terminal switch.  I haven't yet performed any experiments
> to determine just what the bottleneck is.

I think the problem is probably delays in turnaround time. A lot of
rs232 drivers deliberately put in delays to wait for more characters to
come to try and packetize things in as large a packet as possible. If
you're stuck with 32 byte packets that can be a big problem.  I know
somebody who was in a similar situation who did some experimenting with
4 buffers instead of 2 and it improved his throughput.  Unfortunately, 
if the terminal window blocks it only has space for 2 buffers and it starts
endlessly nacking the 3rd and 4th buffers which is unacceptable.

If you've got a 730 what you need is to use the increased packet sizes.
Like I said, though, that's only supported in the streams-XT-driver
based layers so far.  

> A real problem with rlogin-style support on a lot of operating systems
> is that every single byte of data has to be transferred to and from a
> user-mode process.  What I'd really like to see is the ability to
> establish a "splice" between two channels so that all data flow
> occurs in the kernel.  This should be easy with streams, but none of
> the BSD-based rsh/rlogin/etc. implementations I've seen follows this
> general approach.  Probably the Annex software has a similar deficiency.

I don't see that as being such a big deal because the characters aren't
individually passed to the user-mode process, they're sent in larger blocks.

- Dave Dykstra
  dwd@king.att.com