Date: Thu, 09 Aug 2001 00:10:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rolf Neugebauer <neugebar@dcs.gla.ac.uk> Cc: Weiguang SHI <weiguang_shi@hotmail.com>, bright@mu.org, jeff@expertcity.com, freebsd-hackers@FreeBSD.ORG Subject: Re: timing question Message-ID: <3B723782.F55EDEBA@mindspring.com> References: <F4977bieLYCT4aJ6pkN00000e1b@hotmail.com> <ysqae1ad39h.fsf@therese.dcs.gla.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Rolf Neugebauer wrote: > NB. for achieving higher timer resolutions you might find it > interesting to look at Soft-Timers at Rice [2]. Events are scheduled > at the usual timer interrupt frequency but the time wheels are also > checked at system-call and other interrupt times, thus, depending on > load, achieving finer grained timer resolutions. The TOCS paper, > referenced on that site, also describes a mixed approach between > Soft-Timers and hardware timers to achieve tighter delay bounds. I like most of Mohit Aron's papers, and Peter Druschel's work is pretty much landmark. The real problem with them is that their implementations are for very old versions of FreeBSD, or they are licensed with a pretty restrictive license that would prevent them from being incorporated in FreeBSD, or both. The soft timers aren't the only code, either. There are two different LRP implementations they have released in conjunction with the Scala server project; the one for FreeBSD 4.x is under a very restrictive license, while the other one is very old, and both of them are "graduate student code", i.e., they are not anywhere near usable in a production system. The LRP paper is the one I have been obliquely referencing with regard to receiver livelock avoidance in the thread "allocating at interrupt" (or something like that). Unfortunately, Mohit is now working for Zambeel on a Linux based product (I have a guess about it, actually), but they are still in stealth mode, so we aren't going to be seeing much from him for a while. Druschel is still working for Rice, last I heard, but has also formed a forward proxy cache company with some other academics, and they consistently win the performance numbers in the cache bakeoffs for forward proxy caches tested via the "polygraph" benchmark (polygraph is a typical "your product id a bad idea, so I am going to write something to kill it" benchmark, but everyone publishes numbers, so it's accepted as a figure of merit, even though it goes incredibly out of its way to first characterize how a forward proxy cache works, and then pick a pessimal usage pattern to bust it... "so there"). Most of the Scala ideas don't require 5 PhD's to understand, and someone well versed in the literature could implement them, with effort (for example, I've implemented LRP for FreeBSD 4.3-STABLE for the company I work for; LRP deals with one of the seven deadly receiver livelock issues). With HP selling a 10Gbit copper ethernet card on 64 bit PCI, even without the standards ratified (the optical geeks can't get their act together to get their components specified for that rate), it would be very easy to overwhelm your bus with DMA from the copper card, if you didn't handle each of the seven deadly issues in the livelock case correctly. For those who don't know the term, think "denial of service attack". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B723782.F55EDEBA>