Date: Fri, 26 Sep 1997 02:53:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: tlambert@primenet.com, dg@root.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) Message-ID: <199709260253.TAA23134@usr05.primenet.com> In-Reply-To: <199709260007.SAA29559@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 25, 97 06:07:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >This will increase the load on the timer code with a lot of 20 tick > >timers for a 100Hz softclock. > > No. There would be exactly one TCP timer for doing delayed acks in > the queue at a given time. The TCP code would be performing it's > own "one shot" timer management if you will. Yes, I missed this. David corrected me privately. I don't really like the idea of a multiplicity of timer code like this. I would prefer that TCP not manage it's own timers with a pseudo-softclock resulting from a timeout event in the real softclock. The initial posting to which David responded wanted to use centralized timer code for all timing functions. I liked that idea, with the caveat that the wheel would get loaded fast (Nate brought this up in the using-timers-for-network case back in the original discussion). > >I haven't seen a formal layout of the design Archie Cobb said he > >discussed with Julian, so I can't comment on that, but it would be > >a good idea to consider all angles before making such a significant > >change to the networking code (one of BSD's shiny spots). > > Archie's design is similar to having a set of hierarchical timing wheels > which would handle large loads of timers with varying lifespans and > chances of expiration better than the single level wheel we have now. > I think that this is a better approach than having an ordered/unordered > list for each bucket. I still like the ordered list for the O(n+1) event processing for n events in the process of expiring for a given tick. On the other hand, if it's possible to get HRT with good realtime constraints on maximum event processing duration, then it's sixes as far as I'm concerned. The point of ordering the list is less to deal with the seperation of things that take n ticks and n+256 ticks in the same bucket than it is to deal with RT. How would you handle RT events and priority-lent non-RT events for processes blocking RT required resources, without using a time/priority ordered list, where the RT events were inserted first? > See the G.Varghese and A. Lauck paper I referenced yesturday: > > http://dworkin.wustl.edu/~varghese/PAPERS/twheel.ps.Z Will do, as soon as I get ghostscript compiled up... is there a readable version of the paper anywhere meanwhile? The last paper I had to borrow a PS printer to read. Alternately, can you reference everything at once? ;-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709260253.TAA23134>