Return to BSD News archive
#! rnews 2805 bsd Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!vixen.cso.uiuc.edu!sdd.hp.com!swrinde!howland.reston.ans.net!math.ohio-state.edu!news.cis.ohio-state.edu!rutgers!utcsri!cs.toronto.edu!schenk Newsgroups: gnu.misc.discuss,comp.os.linux.networking,comp.unix.bsd.netbsd.misc From: schenk@cs.toronto.edu (Eric Schenk) Subject: Re: TCP latency (Re: GNUseless Debates (Was Re: GNU software on a Linux system)) X-Nntp-Posting-Host: qew.cs.toronto.edu Message-ID: <1996Jun11.004639.8574@jarvis.cs.toronto.edu> X-Newsreader: NN version 6.5.0 #8 (NOV) References: <1JWBCFZN@wuschel.ibb.schwaben.com> <4p7cne$2ri@linux.cs.Helsinki.FI> <4pa83i$2km@solutions.solon.com> <4pcsmv$l9p@master.di.fc.ul.pt> <4pd10g$dmq@solutions.solon.com> <4pfgbi$92l@master.di.fc.ul.pt> Date: 11 Jun 96 04:46:39 GMT Lines: 36 Xref: euryale.cc.adfa.oz.au gnu.misc.discuss:26261 comp.os.linux.networking:41271 comp.unix.bsd.netbsd.misc:3751 roque@master.di.fc.ul.pt (Pedro Roque Marques) writes: >Peter Seebach (seebs@solutions.solon.com) wrote: >: Pedro Roque Marques <roque@master.di.fc.ul.pt> wrote: >: >RFC 1323 defines TCP options. If the linux box is acting as a router there >: >is absolutly no chance it would change this fields unless you are using >: >masquerading/transparent proxying. So the router being Linux or not has >: >nothing to do with it. >: But it does, by observation; if the BSD boxes are connected directly, >: they get good speeds, if they are connected through a Linux box, using >: the same pair of modems, and an otherwise-workable ethernet net between >: one of them and the Linux box, we suddenly get *very* bad performance; >: maybe 10 bytes/second. >There is one issue that could get into play here: it's likely that the >fact that options are present in packets makes header compression fail >for every packet while still taking the performance cost of maintaining >the connection states. Try switching ppp header compression off. Ah. This tweaks a memory. I seem to recall that a bug in the VJ compression code got fixed sometime in the 1.3.X development cycle. Also, the sort of speed Peter is report is consistent with reports of problems with VJ compression incompatabilities. [Mere failure to be able to do header compression should not cause the performance hit that Peter is seeing.] In any case, I'd be interested to hear if either turning off VJ compression or upgrading the Linux box to the 2.0 kernel fixes the problem. -- eric --------------------------------------------------------------------------- Eric Schenk www: http://www.cs.toronto.edu/~schenk Department of Computer Science email: schenk@cs.toronto.edu University of Toronto