phil@amdcad.UUCP (Phil Ngai) (03/13/86)
There's a vendor who wants to sell me an ethernet interface that looks
like a DMF serial interface. (actually, there's several of them) They
claim telnetd uses a lot of resources. I was dubious but then I used
the 'top' utility and saw a telnetd doing continous output at an
effective rate of 9600 baud uses 20% of a 780.
It sounds like the vendor is right. Any comments? Are there any
implementations of telnetd which are more efficient or is this just
inherent in the nature of the system?
--
"We must welcome the future, remembering that soon it will become the
present, and respect the past, knowing that once it was all that was
humanly possible."
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comhedrick@topaz.RUTGERS.EDU (Charles Hedrick) (03/15/86)
The vendor is right. Telnetd is a pig. There are some things known that will speed it up a bit. If you are using vanilla 4.2, there are some patches to the pty code that will speed up pty's a lot. But even with those patches, telnetd can use a fair amount of CPU time. Fortunately, in practice people don't sit there typing out files at 9600 baud. So things aren't as bad as they could be. I'd try to get an estimate of the amount of terminal output you do during you peak load period, and see whether the CPU use is worth attacking. I could certainly imagine situations where an Ethernet interface that looks like a DMF would be a great idea. Actually, I'd rather see somebody fix telnetd. I have talked with people who know the terminal code, and they conclude that a couple of days work could improve performance dramatically. But I can't get them to do it. grrrrr....... I have thought of doing it myself, but it would take me an order of magnitude longer to do it than a real kernel wizard.
cak@purdue.UUCP (Christopher A. Kent) (03/15/86)
Sure enough, telnetd is expensive. So is rlogind. I wish I had the time to do this, but I don't, so I'll pass on the idea and perhaps someone will do the world a favor and implement it. First, why it's so expensive: because each packet (potentially one per character!) causes at least 2 context switches, and crosses the user/system boundary 4 times (socket->telnetd, telnetd->pty, pty echo->telnetd, telnetd-> socket). There are fixes to TCP that can be made to buffer several characters into one packet; this cuts the network overhead, but doesn't affect the telnetd performance. It seems that as long as telnetd runs as a user program, it's doomed to be expensive. So, I say, move telnetd into the kernel! This has worked for other operating systems, notably TOPS-20. Build a new tty-like bottom half driver that does telnet's options negotiations, etc., and interfaces to the top half of the tty driver; it would look like a DH, DZ, etc. telnet options would directly affect "stty" parameters, force signals, etc. No more using ptys for this style of remote login. This was done in the CSNET X.25-to-IP code for X.28/X.29 PAD access; we built a new bottom half. In some sense, the protocol was a little simpler to deal with (didn't have to twist TCP around inside the kernel, the board made that a bit easier) but there's no reason why this shouldn't work in principle. Of course, it would be nice to do the same with rlogin. The only problem that I see there is that rlogind does some work involving the file system during protocol startup; telnetd doesn't. (I'm talking about checking hosts.equiv and so on.) I don't see right off how to make that happen from inside the kernel. Perhaps the getty table for rlogind ports would invoke a special table that understood how to interpret the initial protocol authorization handshake, or call login with the appropriate arguments... yah, it seems like that might work. In fact, both rlogind and telnetd ports could be made to understand little goodies like passing the terminal type and that (telnet has an option for this, too, though 4.2 doesn't seem to know how to handle/use it.) If you do this, please let the world know so it can be farmed back into 4.4BSD (;-). And so I could have it for my systems! Cheers, chris
jt@nrcvax.UUCP (Jerry Toporek) (03/17/86)
In article <10620@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >There's a vendor who wants to sell me an ethernet interface that looks >like a DMF serial interface. (actually, there's several of them) They >claim telnetd uses a lot of resources. I was dubious but then I used >the 'top' utility and saw a telnetd doing continous output at an >effective rate of 9600 baud uses 20% of a 780. > >It sounds like the vendor is right. Any comments? Are there any >implementations of telnetd which are more efficient or is this just >inherent in the nature of the system? Phil: I don't know if you are referencing our product or not, but from the des- cription you certainly might be. If the telnet daemon is intended to extensively inspect both the input and output streams, then resource utilization such as you describe might occur. Our net terminal driver looks like a DMF only in the sense that it interfaces with the VMS terminal class handler just like a DMF, or DZ, or whatever. The telnet daemon in this sort of setup is not required to do any input or output processing, that is all left to the class handler. In this case a good bit of resource can be wasted passing off output to the telnet daemon to pass onn to the net. (This is what we were doing in our initial version.) This can be improved upon by arranging to pass data received by the terminal driver from the class handler directly to the network driver. (This is what we now do. We still route keyboard input through the daemon, since there are a few things we want to handle there, like urgent data.) In this configuration, the test you mention above, monitoring a continuous output to the net terminal, should show resource utilization by the daemon of 0. jt -- ========================= `` '' ==================================== Jerry Toporek <`@-@'> Network Research Corp. ihnp4!nrcvax!jt ( > ) 1620 Federal Ave. Suite #2 ucbvax!calma!nrcvax!jt \~/ LA, CA, 90025, USA {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jt (213) 479-6436
rick@nyit.UUCP (Rick Ace) (03/20/86)
[] cak@purdue.UUCP (Christopher A. Kent) writes: > Sure enough, telnetd is expensive. So is rlogind. I wish I had the time to > do this, but I don't, so I'll pass on the idea and perhaps someone will > do the world a favor and implement it. > > First, why it's so expensive: because each packet (potentially one per > character!) causes at least 2 context switches, and crosses the user/system > boundary 4 times (socket->telnetd, telnetd->pty, pty echo->telnetd, telnetd-> > socket). Indeed. rlogin is expensive too. Consider what happens when a user types *one* character on an rlogin connection: an agent process on the client system wakes up, reads the character, and writes it out to a socket; an agent (rlogind) awakens on the server, reads the character from its socket, and feeds it to the pty; the tty driver on the slave end of the pty devours the character and echoes it; the server agent awakens again to read the echoed character from the pty and write it to the socket; an agent process on the client (rlogin) awakens to read the character from the socket and write it to the user's terminal. Whew, that's a total of four (two on the client plus two on the server) context switches! > [discussion about moving these funtions into the kernel] > Of course, it would be nice to do the same with rlogin. We did. > The only problem > that I see there is that rlogind does some work involving the file system > during protocol startup; telnetd doesn't. (I'm talking about checking > hosts.equiv and so on.) I don't see right off how to make that happen > from inside the kernel. You negotiate the connection in user-mode in rlogin and rlogind. Once the connection has been established, rlogin does an ioctl to bind the user's tty with the TCP socket, and rlogind does a complementary ioctl to bind its TCP socket with its pty; from now until the connection breaks, all character switching is done exclusively within the kernel. The rlogin (sans child) and rlogind agent processes still exist; however, their roles have been reduced to negotiating the connection and awaiting (via kernel sleep()) its termination... the per-character context switches are gone. Since the protocol is unchanged, it's possible for a kernel-rlogin client to interoperate with a vanilla 4.2bsd rlogind and vice-versa. > If you do this, please let the world know so it can be farmed back into > 4.4BSD (;-). And so I could have it for my systems! > > Cheers, > chris World, you are hereby notified. I've made a set of mods for 4.2bsd to implement kernel-switched rlogin connections, both the client and server ends. We've been using them for several months now. If there is sufficient interest, I'll pursue making a public distribution. Although I haven't seen 4.3bsd (anyone know what's happening here?), the 4.2 mods shouldn't be too hard to install in 4.3. PURISTS BEWARE: This facility requires a few small hooks in ttyinput(), sbwakeup(), tty_pty.c, and maybe one or two other places that aren't on the tip of the tongue. If this disgusts you, mail your flames to /dev/null and proceed to the next posting :-). From a pragmatist's perspective, a modicum of smut in one's kernel is a small price to pay for more responsive rlogin connections, fewer context switches (and on Vaxes, fewer cache flushes), and happier users. I asked Mike Karels if he had any interest in this stuff, but they are contemplating an implementation of streams or a stream-oid facility in 4.4 that would obviate the need for my specialized hack. (DISCLAIMER: The ideas expressed in this paragraph are purely speculative and should not be interpreted as facts or even rumors about future Berkeley software releases.) ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 {decvax,seismo}!philabs!nyit!rick
phil@amdcad.UUCP (Phil Ngai) (03/25/86)
In article <572@nrcvax.UUCP> jt@nrcvax.UUCP (Jerry Toporek) writes: >Phil: > >I don't know if you are referencing our product or not, but from the des- >cription you certainly might be. No, I had someone else in mind. >Our net terminal driver looks like a DMF only in the sense that it interfaces >with the VMS terminal class handler just like a DMF, or DZ, or whatever. What I meant was they had a Unibus board with the same CSRs as a real DMF. Obviously, you lose the ability to do real networking with this kind of interface. >In this case a good bit of >resource can be wasted passing off output to the telnet daemon to pass onn to >the net. (This is what we were doing in our initial version.) This can be >improved upon by arranging to pass data received by the terminal driver from >the class handler directly to the network driver. (This is what we now do. This sounds like a good idea. Can you make Unix do this too? -- "Welcome to the Hotel California... You can check out any time you like, but you can never leave." Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
jt@nrcvax.UUCP (Jerry Toporek) (03/27/86)
In article <11048@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >In article <572@nrcvax.UUCP> jt@nrcvax.UUCP (Jerry Toporek) writes: >>In this case a good bit of >>resource can be wasted passing off output to the telnet daemon to pass onn to >>the net. (This is what we were doing in our initial version.) This can be >>improved upon by arranging to pass data received by the terminal driver from >>the class handler directly to the network driver. (This is what we now do. > >This sounds like a good idea. Can you make Unix do this too? Well, I don't know much about driver to driver communication under Unix. When you mentioned the DMF lookalike I thought you were probably talking about VMS since the usual trick for doing a net tty driver on VMS is to "look like" a real device. -- ========================= `` '' ==================================== Jerry Toporek <`@-@'> Network Research Corp. ihnp4!nrcvax!jt ( > ) 1620 Federal Ave. Suite #2 ucbvax!calma!nrcvax!jt \~/ LA, CA, 90025, USA {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jt (213) 479-6436