Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!vixie
From: vixie@decwrl.dec.com (Paul Vixie)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Serial TCP/IP - all the same?
Message-ID: <80@volition.dec.com>
Date: 24 Aug 88 02:54:54 GMT
References: <759@stcns3.stc.oz> <977@rlgvax.UUCP> <26204@think.UUCP> <5189@pasteur.Berkeley.EDU>
Organization: DEC Western Research Lab
Lines: 27

# Let me attempt an answer -- the SLIP frame-escape method has the
# property that the only place a FRAME_END character appears in the
# SLIP-encoded data is between packets, i.e. FRAME_END doesn't occur
# within a packet even in escaped form.

Now let _me_ list another reason why this is a Good Thing.  There are quite
a few smart serial devices in the world these days.  Most of the time they
don't use any of their smarts -- getting UNIX line editing into the serial
board is something one can be quite proud of, if one can make it work at all.

If you can help do SLIP by adding some logic to your serial card, you can get
a nice performance bang for a small amount of effort: tell your serial card
to collect bytes until a timeout, buffer overflow, or terminating character
in the input.  If you use a large enough timeout and buffer, your main CPU
only has to deal with SLIP when a whole packet has arrived.

If you don't have a smart serial card, you can still get a little bit of
benefit from this down in the lowest levels of your input driver.  But if
you have a protocol that makes you keep track of state between input
characters, it gets harder no matter where you are trying to optimize it,
and you will probably end up not optimizing it.

Yours for fewer interrupts,
-- 
Paul Vixie
Digital Equipment Corporation	Work:  vixie@dec.com	Play:  paul@vixie.UUCP
Western Research Laboratory	 uunet!decwrl!vixie	   uunet!vixie!paul
Palo Alto, California, USA	  +1 415 853 6600	   +1 415 864 7013