Item Subject: Message text
> This is interesting... and also tells me that I'm not insane (yet..)
> I would expect (and I see) better performance through LAN using
> WRQ stuff than I get from 19.2 kbps DTC port.  It makes sense since
> LAN can get the stuff through much faster than a serial DTC port.
 
On standalone systems with no other traffic on the subnet I agree...
 
> Maybe the case that Isaac refers to is a matter of running an application
> that generates a big number of individual packets to paint the whole
> screen instead of having a few fairly large writes.  I cannot see how a
> DTC port could ever outperform a TCP connection over a LAN if the terminal
> writes are few to paint the screen.
 
Yes we see the problem with V+ screens, and other applications.  Further the VT
sessions are not as "crisp" in their response and DTC connections.  Also on the
server side, since the VTSERVER processes are at C152, they can be effected by
other processes.
 
> If the number of writes is great, than a VT-connection will suffer as it
> requires almost twice the number of process dispatches - i.e. every terminal
> write through DTS-io path can run on user's stack all the way out, a write
> over VT runs on user's stack only for the time vt_ldm needs to process it,
> then the vtserver needs to be dispatched to send the data out to the LAN...
> Inbound path - I think - does not require any more process dipatches than
> is needed for DTC attached terminal.
 
What I was trying to point out was the considerations for the client (LAN
boards, network software, terminal emulators, etc...), as well as the points you
and others brought out.
 
/isaac