In some mail from Tom Perrine, sie said: [...] > We surveyed all the syslog daemons we could find, last year, and again > more recently. No one mentioned having running code for RFC 3195 > compliant stuff. I don't recall finding anyone who admitted working > on a 3195 implmentation. I suppose you mean "open source" solutions/products, here... I would hope there is at least one commercial product supporting it given the vendor interest in that list! (No, I haven't checked myself...) [...] > 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 ;-) > Since you are "challenging" our claims, got code? :-) As a matter of fact, yes :-) (I'm not sure if you're asking that in jest wnad you did see my name in syslog-ng and/or elsewhere or you're thinking that I haven't...) > As for high-performance, all the other syslogs seemed to be aimed at > more flexibility in switching, some other weally cool features, or > database back-ends. For example, syslog-ng and pattern matching. I wrote nsyslogd which was the "inspiration" for syslog-ng. My goal wasn't pattern matching, so much as flexibility in mux'ing data from inputs to outputs and a secure implementation that performed well. I don't give a rats a*** about SQL and database insertion. The other goal was to make the data become tamper evident (tamper proof requires immeadiate protected storage and that's not something that is solved with a few lines of code.) The problem with doing that is to make it all work properly imposed a bunch of operational problems that require compromises for ease of use. That problem kind of got the better of me and I never really got back to doing something about it and producing good tools to work with its encrypted/mac'd logs. If truth be known, IMHO you would have to try hard to write syslogd in a manner that is as simple as it is today that performs worse. > 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. I can see why you're "not there" yet, quite easily. I did some testing years ago on ultra5's on trying to switch ethernet packets very quickly and was optimizing branches out for gains of around 250kb/s, per branch. btw, thanks for the credentials brief - they impressed me :) Darren _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Dec 05 2002 - 08:21:02 PST