Return to BSD News archive
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!news.vbc.net!alpha.sky.net!news.aimnet.com!ossi.com!agate!howland.reston.ans.net!Germany.EU.net!news.dfn.de!news.ruhr-uni-bochum.de!news.rhrz.uni-bonn.de!mpifr-bonn.mpg.de!fs1.mpifr-bonn.mpg.de!souva From: souva@aibn58.astro.uni-bonn.de (Ignatios Souvatzis) Subject: TCP latency in the presense of RFC1323 (Was: Re: TCP latency) In-Reply-To: matt@3am-software.com's message of 14 Jul 1996 22:12:43 GMT Message-ID: <SOUVA.96Jul16132215@aibn58.astro.uni-bonn.de> Sender: news@mpifr-bonn.mpg.de Nntp-Posting-Host: aibn58 Reply-To: isouvatzis@astro.uni-bonn.de Organization: Radioastronomisches Institut der Universitaet Bonn, Bonn, FRG References: <4paedl$4bm@engnews2.eng.sun.com> <4rlf6i$c5f@linux.cs.helsinki.fi> <31DEA3A3.41C67EA6@dyson.iquest.net> <Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net> <4rpdtn$30b@symiserver2.symantec.com> <x7ohlq78wt.fsf@oberon.di.fc.ul.pt> <Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com> <x74tnfn35s.fsf@oberon.di.fc.ul.pt> <4s33mj$fv2@innocence.interface-business.de> <4sbrcr$rqd@enomem.lkg.dec.com> Date: Tue, 16 Jul 1996 11:22:15 GMT Lines: 28 Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45398 comp.unix.bsd.netbsd.misc:4073 comp.unix.bsd.freebsd.misc:23722 In article <4sbrcr$rqd@enomem.lkg.dec.com> matt@3am-software.com (Matt Thomas) writes: There are a number of problems with the way timers are implemented in TCP. The first is granularity. A slow/fast timeout has an inaccuarcy of up to 500ms/200ms. That may cause inaccuaries to creep into round-trip estimates. Shouldn't this be unimportant in the presence of the RFC1323 round trip _measurement_ (instead of "educated guessing", which old BSD TCP did)? Which reminds me of: Did anybody ever analyze why some (old?) Linux boxes would damage RFC1323 TCP packets routed through them? Only change to pre-rfc1323 would be in the TCP part, so maybe it is a problem in the os-specific part of the ppp implementation in Linux? (Assuming that no other part of the networking code violates layering). Regards, Ignatios Souvatzis -- Ignatios Souvatzis Cute quote: "You should also consider that the ST comes fully equipped with a text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de