On Fri, Dec 06, 2002 at 02:43:18AM +1100, Darren Reed wrote: [ ... ] > > The #$@# BEEP libraries are *still* giving us fits, > > and we'd love to hear what other people are trying instead of the > > roadrunner or other BEEP libs. I have a former student who says he > > could drink bad beer for a month solid, take a sledgehammer to his own > > head and write better libs. Using a crayon. He's been fighting the > > BEEP stuf for several months (part time, in the last quarter of his BS > > CSE). > > Hmmm, BEEP sounded like a bad idea when I heard of it, now I'm sure it > is a bad idea ;-) As one of students working on this project ... let me say that I'm not convinced that BEEP is a bad idea per say. It would make a wonderful IM protocol ... but it is a little overkill for syslog. However, it does have some advantages, such as making it easy to plug in authentication and encryption. That being said, it also needs to be said that the current offerings for BEEP libraries is less than impressive. If anyone knows of a BEEP implementation other than RoadRunner or Beepcore, please send me an email. As things stand right now, we are fighting with the threading model used by RoadRunner. [ ... ] > > Out goal is to be able to saturate (or accept) at least one full-speed > > gig-E connection. If we can't drive gig-E and the disks at > > full-speed, all the time, we've got work to do. I'd like to be able > > to saturate or accept multiple gig-Es, but I think the PCI bus will > > stroke out first. I've got a server with 2 PCI busses for performance > > testing, but we're not there yet. > > Can you even do that, theoretically, with modern hardware given the > constraints placed on you by hardware ? PCI is typically 32bits at > 33MHz, which is barely 1Gbit and that's if you're going flat out. > Then you've got to move the data around buses inside the computer, > spend cycles doing computations on it, etc. Yes, but faster PCI buses are available (both bandwidth and clock speed). When we set our goal for saturating a gig-E connection we had these in mind. The point of our goal is to make the hardware the bottle neck, not our software. Then get faster hardware and try again :) -- Devin Kowatch devinkat_private _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Dec 05 2002 - 12:58:08 PST