hubcap@hubcap.clemson.edu (System Janitor) (01/12/91)
Would anyone in this forum care to comment on these claims?
-Mike
*********** LAT/ TELNET comparison ***********
- LAT is optimized for terminal/host connectivity on a single LAN
"For asynchronous traffic on local networks, LAT is the best
available technology and won't easily be supplanted by OSI's
VT or IP's TELNET [protocols]" (Donald G. Hirsh, DEC
Professional, February 1990).
- LAT causes less of a burden on the CPU and the network
"In preliminary test using KI Research's KiNet, DR Labs found
the DEC's LAT protocol imposed lower overhead on both the host
CPU and the network than TELNET. For example, with 45 active
TELNET session on a Mips M/120-5 system, the CPU had zero
percent idle time, meaning that it was overload, and only 4.4
percent of the network bandwidth was utilized. With 64 active
LAT sessions to the same machine, the CPU was still 50 percent
idle, and only 2 percent of the network bandwidth was
utilized. This difference is due in large part to the fact
that LAT does not use the full DECnet stack, whereas TELNET
uses the full TCP/IP stack." (Lee Schlesinger, Digitial
Review, August 27, 1990)henry@zoo.toronto.edu (Henry Spencer) (01/12/91)
In article <12578@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes: >- LAT is optimized for terminal/host connectivity on a single LAN Ah, so one never needs to connect one's terminal to a host that is not on the same local network? Gee, DEC, thanks for telling me. I thought otherwise. :-) It is difficult to evaluate the accuracy of such claims when the LAT specs are (last I heard) still secret. My first reaction is "this sounds like marketing fluff". >- LAT causes less of a burden on the CPU and the network > "In preliminary test using KI Research's KiNet, DR Labs found > the DEC's LAT protocol imposed lower overhead on both the host > CPU and the network than TELNET... This is *extremely* sensitive to implementation details. My gut reaction is that it says almost nothing about the protocols. > ...This difference is due in large part to the fact > that LAT does not use the full DECnet stack, whereas TELNET > uses the full TCP/IP stack... Now this *is* marketing fluff. Telnet uses the full TCP/IP "stack", all two levels of it: IP for data delivery, TCP for reliability, sequencing, and flow control. Unless the laws of nature have gotten repealed somehow, LAT needs all those functions too. I can think of no reason offhand why a well-tuned TCP/IP implementation -- more often spoken of than found, alas -- should incur any extra overhead compared to whatever LAT uses. For a guess, they're comparing a user-level Telnet server implementation against an in-kernel LAT server, and it is no surprise that the in-kernel approach is more efficient. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
roy@phri.nyu.edu (Roy Smith) (01/12/91)
hubcap@hubcap.clemson.edu (System Janitor) writes: > Would anyone in this forum care to comment on these claims? [...] > LAT causes less of a burden on the CPU and the network How much of this is inherent in the protocols and how much depends on the implementations? Most Unix telnet servers are implemented as user processes which use pseudo terminals to talk to login shell processes, which is a very inefficient way to do things. For a single character typed by the user, you get: TCP/IP pty driver TCP/IP kernel process \ / \ / - - - - \ - - - - / - - - - \ - - - - - / - - - - - - - - - - - - \ / \ / telnetd telnetd user process as the character comes in off the network, gets handed to telnetd which turns it around to give to the pty driver which generates the echo and the echo'ed character is handed back to telnetd which sends it back out onto the network again; 4 context switches for each character typed. Some time ago I remember reading about somebody (Rick Ace?) who had a neat hack which did most of telnet entirely in the kernal, only invoking the user-space telnetd when a IAC character was encounted. I wonder how that implementation would stack up against LAT for CPU utilization? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
oberman@rogue.llnl.gov (01/12/91)
In article <12578@hubcap.clemson.edu>, hubcap@hubcap.clemson.edu (System Janitor) writes: > Would anyone in this forum care to comment on these claims? > > -Mike > > *********** LAT/ TELNET comparison *********** [Comments on superiority of LAT to Telnet and VT deleted.] These comments are certainly correct if taken in the correct context. 1. LAT operates only on a LAN. It can't be routed and depends on the broadcast nature of LANs. While bridges don't effect LAT, routers, even if between LANs will break it. 2. Normal caveats on the optimization of any specific implementation apply. While it would be difficult, I can imagine a very bad implementation of LAT running with more overhead than a good Telnet. 3. LAT depends on multicasts for servers to learn of available services. This generates 1 packet per host per minute background on a LAN. It is not significant except on VERY large LANs. And the multicasts are not, of course, blocked by bridges. We have about 1000 LAT hosts on our LAN and the multicast level is not a problem, but it sure is obvious on an analyzer. 4. LAT is proprietary and licensed by DEC. If you use it, DEC want's their cut. Ki Research is paying DEC for every license they ship. Telnet is available from almost everyone. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
henry@yogi.fhhosp.ab.ca (01/12/91)
> Would anyone in this forum care to comment on these claims? > > -Mike > > *********** LAT/ TELNET comparison *********** I can't comment from a technical point of view, but from a real-world user's point of view, LAT has one distinct advantage - it handles buffering in a non-annoying way. Control-C's are have very little latency as compared to TELNET. If you're considering buying a terminal server, I'd buy one with both.. Cheers, -Henry Bland
tucker@smsc.sony.com (Tim Tucker 817) (01/13/91)
> - LAT causes less of a burden on the CPU and the network > "In preliminary test using KI Research's KiNet, DR Labs found > the DEC's LAT protocol imposed lower overhead on both the host > CPU and the network than TELNET. For example, with 45 active > TELNET session on a Mips M/120-5 system, the CPU had zero > percent idle time, meaning that it was overload, and only 4.4 > percent of the network bandwidth was utilized. With 64 active > LAT sessions to the same machine, the CPU was still 50 percent > idle, and only 2 percent of the network bandwidth was > utilized. This difference is due in large part to the fact > that LAT does not use the full DECnet stack, whereas TELNET > uses the full TCP/IP stack." (Lee Schlesinger, Digitial > Review, August 27, 1990) Hmmm, in theory LAT is cheaper than TCP/IP, but I wonder if Digital Review was comparing apples and oranges? Most likely the TCP/IP implementation was based on BSD. That means the user space BSD telnet/rlogin daemons are used. These daemons, I'm not knocking them, cause a very heavy context switch burden under high multi-user loads. Several years ago I worked a complete kernel implementation of both telnet and rlogin for a BSD based system (the Gould UTX/32 2.0 OS). It turned out to be pretty easy. We used the public domain reference code that has been on the archives for years as an example on how to get started. The result was exactly what you would expect. We went upto 128 users, I think, during QA tests and still meet our application load requirements (bid requirements). It would be interesting to see how these LAT kernel stacks compare against a lean kernel implementation of TELNET or RLOGIN. Tim Tucker tucker@smsc.sony.com
henry@zoo.toronto.edu (Henry Spencer) (01/13/91)
In article <1991Jan11.170417.1732@yogi.fhhosp.ab.ca> henry@yogi.fhhosp.ab.ca writes: >I can't comment from a technical point of view, but from a real-world >user's point of view, LAT has one distinct advantage - it handles >buffering in a non-annoying way. Control-C's are have very little >latency as compared to TELNET. Be careful to distinguish between the protocol and the implementations. As I understand it, there is no reason in the TELNET *protocol* why interrupts should have any significant latency, although getting it right in the *implementation* is subtle and many implementors ignore the issue. >If you're considering buying a terminal server, I'd buy one with both.. I'd test the TELNET latency instead. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/13/91)
Would anyone in this forum care to comment on these claims?
Yeah, I'll comment. A word about my background first. Around 1983,
TCP started to be implemented, and I worked in the network group at
SRI International. We were talking about using the network to replace
our terminal port selectors. Bridge communications built the worlds
first commercial terminal server, but it spoke XNS, and they were not
interested (at that time) in supporting TCP. On the other hand, they
would provide documentation so we could write our own code. TCP was
very young in those days, and we reflected that maybe a special
purpose terminal protocol would be useful. We didn't do anything, but
were very excited when DEC announced LAT, since it incorporated many
of the ideas we had been talking about. Unfortunately, DEC refused to
divulge a specification for their new protocol, preferring to keep it
to themselves. Somewhat later, I moved to Stanford University, where
all terminal access to the computers was already via the network.
Initially, this was using the Xerox PUP "Chat" protocol, but
eventually software was written for our "ethertips" was written to
support TCP. I did the monitor modifications to TOPS20 to allow it to
support 60+ incoming telnet users and still have some cycles left.
Later, cisco Systems spun out of Stanford, taking the ethertip and
router code, and making them into commercial products. I went to work
there, doing much work on the terminal server related software,
including adding LAT support about a year ago...
- LAT is optimized for terminal/host connectivity on a single LAN
"For asynchronous traffic on local networks, LAT is the best
available technology and won't easily be supplanted by OSI's
VT or IP's TELNET [protocols]" (Donald G. Hirsh, DEC
Professional, February 1990).
Yes, LAT is optimized for terminal host connectivity, but most of those
optimizations are sort of pointless. The biggest "optimzation" is probably
the ability to put traffic from/to multiple users in a single packet. In
reality, I doubt whether this happen much - for output to a terminal, a
user could really use a whole packet's worth of data, and for input from
the terminal, even the ~60 ms "slot" times used by LAT don't usually
result in data from more than one used in a packet.
The lack of a network layer might be considered an optimization, but this
"single LAN" that it allows is a fast-vanishing beast. The fact that it
cannot operate over a complex or Wide-area network is a SERIOUS limitation
of LAT. Cisco recently announced a "protocol translator" that can convert
between LAT and X25 PAD calls, and offered this to a customer as a solution
for getting LAT across an X.25 network (what they wanted was bridging over
X.25). Somewhat reluctantly, the customer was willing to test an arrangement
that looked like:
LAT PAD PAD LAT
[LAT TS]=======[PT]----[X25 Sw]----[x25 Net]----[X25 Sw]----[PT]======[VMS]
ether 1Mb 56kb 56kb 1Mb Ether
They measured echo delays, and watched the X.25 network loading. They (and
even I) were surprised when this arrangment resulted in signifcantly BETTER
response times than a solution that did bridge over X.25. Loading of the
X.25 network was also very much less.
On the other hand, the conclusion that LAT will not easilly be replaced by
Telnet or VTP is quite true. For one thing, LAT does have several real
(as opposed to theoretical) advantages:
1) most existing LAT implementations are more efficient that the
existing telnet implementations. Sad, but true.
2) LAT was designed with a specific OS in mind, and supports the
concepts of that OS better than telnet, which is more general.
For example, host control of "local flow control" and data
transparency are clearly defined in LAT, while the flow control
option has only recently been added to telnet, and is not widely
available to users.
3) There is an enormous installed base of LAT. LAT comes free with
each DEC computer, while adding IP tends to cost someting. DEC
was the first company to push the network as a way of connecting
terminals to their computers (for which they deserve quite a bit
of credit), and is \the/ market leader in terminal server sales
(in spite of the fact that their terminal servers are expensive
and feature-poor compared to many of their competitors.)
On the other hand, it is equally unlikely that LAT will replace Telnet, or
prevent VTP from being deployed. For one thing, DEC wants license fees
for LAT implementations, and royalties for each line of LAT terminal servers.
- LAT causes less of a burden on the CPU and the network
"In preliminary test using KI Research's KiNet, DR Labs found
the DEC's LAT protocol imposed lower overhead on both the host
CPU and the network than TELNET. For example, with 45 active
TELNET session on a Mips M/120-5 system, the CPU had zero
percent idle time, meaning that it was overload, and only 4.4
percent of the network bandwidth was utilized. With 64 active
LAT sessions to the same machine, the CPU was still 50 percent
idle, and only 2 percent of the network bandwidth was
utilized. This difference is due in large part to the fact
that LAT does not use the full DECnet stack, whereas TELNET
uses the full TCP/IP stack." (Lee Schlesinger, Digitial
Review, August 27, 1990)
I suspect that most of this is related to the implementations, rather
than the protocols themselves. As someone has already mentioned, the
usual unix telnetd implementation of telnet is a performance nightmare
due to its excessive context switching. Many telnet terminal servers
negotiate very small (and non-optimal) packet and tcp window sizes in
an attempt to save memory and/or provide quicker response to interrupt
characters. Many unix TCPs are not up to the current "state-of-the-art"
in TCP performance issues.
Of course, this is all accademic, since for the end users "the
implementation is the protocol" or some such. On the other hand, this
is an essentially accademic forum, so we can talk theory.
>I can't comment from a technical point of view, but from a real-world
>user's point of view, LAT has one distinct advantage - it handles
>buffering in a non-annoying way. Control-C's are have very little
>latency as compared to TELNET.
Be careful to distinguish between the protocol and the implementations.
Henry is exactly correct. This is entirely an implementation issue.
cisco's implementation of telnet has always been "correct", but other
implementation details caused our handling of interrupt characters to
be slower than a lot of people would like. Under pressure from customers,
we were finally able to make our telnet flush output essentially as quickly
as desired (without using small windows or packets, and without any local
handling of interrupt characters). It does require that the other end
also handle telnet correctly.
In summary, there is no particularly good reason why LAT should work
better or be a more popular soution for connecting terminals to
computers, but currently it does, and it is, and it's likely to remain
that way for a very long time, mostly because comercial pressures have
made it a more user-tuned product. And that's important.
Bill Westfield
cisco Systems.
-------rich@pluto.dss.com (Rich Rupp) (01/14/91)
In article <1991Jan13.001403.2933@smsc.sony.com>, tucker@smsc.sony.com (Tim Tucker 817) writes: > > - LAT causes less of a burden on the CPU and the network > > "In preliminary test using KI Research's KiNet, DR Labs found > > [description deleted] > Hmmm, in theory LAT is cheaper than TCP/IP, but I wonder if Digital Review > was comparing apples and oranges? I'm familiar with the DR Labs tests, since our VCP-1000 hardware was used as the terminal server in both the TCP/IP/TELNET and LAT cases. In the case of a single user on a terminal server connected into a host, LAT wins over telnet because it's a light-weight protocol - few layers, with very little processing required. The data buffer's can be passed off without telnet's requirement to look at each of the user's characters for IAC's. If multiple sessions are from a single terminal server to the same host, the savings is greater because of LAT's ability to multiplex data from multiple sessions in a single packet. We've spent a lot of time doing comparisons. We have lat implementations on 5 platforms, including system V and bsd. It is still a big win even if you implement Rick Ace's telnet improvements. You'll be seeing a lot of Unix box vendors offering LAT on their platforms. It's not just for DEC compatibility. It's because in some of the new, multiprocessor boxes their marketing people have targeted the machines for a large number of users and they are finding that the TCP/TELNET connections alone drive the machines to their knees. -- ---------------------------------------------------------------------------- Richard L. Rupp rich@pluto.dss.com Datability Inc. 212 807 7800, Fax: 212 807 0958
robinson (Jim Robinson) (01/14/91)
In article <12578@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes: >Would anyone in this forum care to comment on these claims? > >*********** LAT/ TELNET comparison *********** > > >- LAT causes less of a burden on the CPU and the network > "In preliminary test using KI Research's KiNet, DR Labs found > the DEC's LAT protocol imposed lower overhead on both the host > CPU and the network than TELNET. For example, with 45 active > TELNET session on a Mips M/120-5 system, the CPU had zero > percent idle time, meaning that it was overload, and only 4.4 > percent of the network bandwidth was utilized. With 64 active > LAT sessions to the same machine, the CPU was still 50 percent > idle, and only 2 percent of the network bandwidth was > utilized. This difference is due in large part to the fact > that LAT does not use the full DECnet stack, whereas TELNET > uses the full TCP/IP stack." (Lee Schlesinger, Digitial > Review, August 27, 1990) A good question to ask is whether LAT performs checksumming. Given that LAT is a LAN protocol, it seems that it is quite possible that it (perhaps optionally) does no checksumming and instead relies on the LAN to detect and discard corrupted packets (as does ethernet). If this is the case then it would have a natural, and arguably unfair, advantage over TCP due to the rather CPU intensive nature of checksumming. I believe that checksumming is *not* a TCP option (although in practice it is usually possible to turn it off in BSD derived implementations), but even if it is the above comparison is less meaningful without knowing whether both protocols were running with checksumming on or off. -- Jim Robinson {uunet,ubc-cs}!van-bc!mdivax1!robinson robinson@mdivax1.uucp
prc@erbe.se (Robert Claeson) (01/14/91)
In article <1991Jan11.170417.1732@yogi.fhhosp.ab.ca>, henry@yogi.fhhosp.ab.ca writes: |> I can't comment from a technical point of view, but from a real-world |> user's point of view, LAT has one distinct advantage - it handles |> buffering in a non-annoying way. Control-C's are have very little |> latency as compared to TELNET. What terminal server have you been using? The Annex IIe from Xylogics that I occasionally use doesn't have any noticeable delay in handling control C. Whenever I type it, the output stops immediately. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
bob@MorningStar.Com (Bob Sutterfield) (01/15/91)
In article <12653518846.15.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
The lack of a network layer might be considered an optimization,
but this "single LAN" that it allows is a fast-vanishing beast.
The fact that it cannot operate over a complex or Wide-area network
is a SERIOUS limitation of LAT.
Right, but as you later say,
...LAT will not easilly be replaced by Telnet or VTP...
3) There is an enormous installed base of LAT.
After a few years of listening in on the "Campus-Size LAN Discussion
Group <BIG-LAN@SUVM.BITNET>", it seems that the "single LAN" might not
be vanishing quite as quickly as one might hope. There are
organizations out there today, actively installing very large bridged
networks. Why? because (a) DEC sells bridges and (b) DEC sells LAT;
which are complementary solutions to certain problems imposed by the
fact that (c) DEC sells VMS.
If the DEC salesman got to campus before the Sun or Cisco or Bridge or
Proteon salesmen, and if the local tech people grew up in the VMS
culture, then the campus computing services bureaucrats are more prone
to specifying LAT and bridging their network. The benefits of routers
are immaterial in a LAT network, and in fact routers break the LAT
functionality upon which the users have already become dependent.
Sorry if this sounds like cynical VMS- or DEC-slamming, it's intended
only as a recognition of marketing reality.karn@envy.bellcore.com (Phil R. Karn) (01/15/91)
In article <1991Jan14.015852.26228@mdivax1.uucp>, writes: |> A good question to ask is whether LAT performs checksumming. [...] |> [...] rather CPU intensive nature of checksumming. Checksumming is a complete non-issue here. Its cost falls into the noise when compared to all the other things that happen when you type a character or refresh a screen. Even in high bandwidth situations (i.e., FTP rather than TELNET) the cost of TCP checksumming is usually minimal compared to, say, the cost user/kernel context switches and of talking to the Ethernet hardware. And Van Jacobson and Dave Borman have shown how TCP implementations can combine checksumming with data copying. This all but eliminates the cost of checksumming, especially on machines with fast processors and slow memories. Even if TCP checksumming weren't minimal, it would be a big mistake to turn it off - the "end to end argument" reigns supreme. Phil
lefty@TWG.COM (01/15/91)
<van-bc!robinson@ucbvax.berkeley.edu> writes: >A good question to ask is whether LAT performs checksumming. Given that LAT >is a LAN protocol, it seems that it is quite possible that it (perhaps >optionally) does no checksumming and instead relies on the LAN to detect >and discard corrupted packets (as does ethernet). If this is the case then >it would have a natural, and arguably unfair, advantage over TCP due to the >rather CPU intensive nature of checksumming. LAT does _not_, in fact, perform any checksumming of the data streams. It should probably be pointed out that LAT, unlike IP, was originally designed specifically with an Ethernet environment in mind; checksumming in those circumstances was probably felt to be unnecessary. >I believe that checksumming is *not* a TCP option (although in practice it >is usually possible to turn it off in BSD derived implementations), but >even if it is the above comparison is less meaningful without knowing >whether both protocols were running with checksumming on or off. Of course, with telnet, checksumming is occurring at both the IP and TCP layers of the protocol. LAT, having been derived independently of any particular protocol stack, doesn't incur this kind of overhead... - David N. Schlesinger (lefty@twg.com) | Sr. Software Engineer | "And you may ask yourself, The Wollongong Group | 'How do I work this?'" 415/962-7100 |