Just saw this on slashdot
http://www.guninski.com/openbsdrace.html
looking over the Open/NetBSD patches, does this apply to us as well?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Reynolds Chandler Capabilities Engineering, CDS, Intel Corp
Wes Peters writes:
> "Albert D. Cahalan" wrote:
>> No, no, no. You have to tune the systems EQUALLY. Um, how? :-)
>>
>> What if some random admin was picked to tune the systems?
>> Maybe he is a Solaris admin, but he honestly tries to tune
>> the other systems. Sure you wouldn't complain that he
On Wed, Jun 13, 2001 at 06:04:23PM -0700, Gordon Tetlow wrote:
> Anyway, here's my status:
> rcorder ported (one line code change)
I have already sent a patch to a NetBSD contact, so this one is done.
I'll hook `rcorder' up in sbin/Makefile once NetBSD either accepts the
patch or rejects it and I
On Thu, Jun 14, 2001 at 11:57:18AM -0700, Gordon Tetlow wrote:
> >From diving through it all, there will be a fair amount of departure from
> the NetBSD stuff at least up through network init. This is just due to the
> inherent differences in the OSs. Where there was departure, I took the
> curren
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>Doesn't any one remember Netiquette these days and trim what they are
>replying to??
No. Every month is September.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
(cc trimmed)
Albert D. Cahalan wrote:
> > No, he crudely tuned the FreeBSD and Solaris boxes, while proving his
> > foregone conclusion that Linux was the cat's ass. Gee, that was a
> > surprise.
>
> Oh sorry, Linux got the same treatment as FreeBSD and Solaris.
> Only the NT box was untuned,
Hi,
I agree with Serger Babkin - strings(1) wouldn't help.
Main keywords are: ndis.vxd , vip.386 , vtcp.386 .
Any DLL's has nothing common with TCP/IP stack - at least on md 9x.
Sergey Babkin wrote:
> I know one way but it's a hard one: disassemble and manually decomiple
> the code and com
> From: [EMAIL PROTECTED] (Jordan Hubbard)
> Date: Fri 15 Jun, 2001
> Subject: Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
> root@winston-> strings FTP.EXE |grep "University of California"
> @(#) Copyright (c) 1983 The Regents of the University of California.
You can't tell mu
Sergey Babkin <[EMAIL PROTECTED]> writes:
[snip]
> How about keeping the state of the system as empty files in
> a subdirectory, say, /etc/rcstate.d. This directory would be
> cleaned up at boot time and then as each of the service startup
> script is run (and completed successfully), an empty fi
On Sat, 16 Jun 2001, David O'Brien -Hackers wrote:
> On Wed, Jun 13, 2001 at 06:04:23PM -0700, Gordon Tetlow wrote:
> > Anyway, here's my status:
> > rcorder ported (one line code change)
>
> I have already sent a patch to a NetBSD contact, so this one is done.
> I'll hook `rcorder' up in sbin/Ma
On Sat, 16 Jun 2001 [EMAIL PROTECTED] wrote:
> On Thu, Jun 14, 2001 at 11:57:18AM -0700, Gordon Tetlow wrote:
> > >From diving through it all, there will be a fair amount of departure from
> > the NetBSD stuff at least up through network init. This is just due to the
> > inherent differences in t
On Sat, Jun 16, 2001 at 07:58:06AM -0700, Gordon Tetlow wrote:
> I'll submit the patches I have for this that make it work in both FreeBSD
> and NetBSD. BTW, why do we use libutil.h and they use util.h?
Just the way things are.
> I like Matt's idea (I think it was Matt) to have a new_rc switch.
On Sat, Jun 16, 2001 at 08:04:42AM -0700, Gordon Tetlow wrote:
> I also had an idea to break out the network init into several different
> pieces falling under 2 headings LINK (ether, atm) and NETWORK (ipx, ipv4,
> ipv6, atalk). I've started work on breaking everything out and was
> wondering if I
is BSDI's stack so superior to any of the other BSDs that MS would pay BSDI
for it, particularly at a time when BSDI was trying to compete with MS in the
server market? Seems like something that a bunch of BSD fanatics conjured up
after a few beers.
Bryan
To Unsubscribe: send mail to [EMAIL P
In the previous episode, Jordan Hubbard said:
> Not really, I don't have any contacts there. Sigh. I didn't think
> proving this would be quite so hard. :(
If you issue the following command on hub:
% grep "microsoft.com" freebsd-* 2>/dev/null
you may be able to find some contacts th
Greetings,
Here is a surprisingly unbiased article comparing OSes running hard core
network apps. The results are kind of disturbing, with FreeBSD (4.2)
coming in last against Linux (RH), Win2k, and Solaris (Intel).
http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm
The tests were
:
:Greetings,
:
:Here is a surprisingly unbiased article comparing OSes running hard core
:network apps. The results are kind of disturbing, with FreeBSD (4.2)
:coming in last against Linux (RH), Win2k, and Solaris (Intel).
This is old. The guys running the tests blew it in so many ways
On Sat, 16 Jun 2001, Matt Dillon wrote:
>
> :
> :Greetings,
> :
> :Here is a surprisingly unbiased article comparing OSes running hard core
> :network apps. The results are kind of disturbing, with FreeBSD (4.2)
> :coming in last against Linux (RH), Win2k, and Solaris (Intel).
>
> This is
I didn't believe my eyes
windows is better than FreeBSD..
can't be true
- Original Message --
From: Matt Dillon <[EMAIL PROTECTED]>
To: Matthew Hagerty <[EMAIL PROTECTED]>
Send: 06:56 PM
Subject: Re: Article: Network performance by OS
:
:Greetings,
:
:Here is a surprisingly unbiased artic
> Date: Sat, 16 Jun 2001 11:56:45 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
> This is old. The guys running the tests blew it in so many ways
> that you might as well have just rolled some dice. There's a slashdot
> article on it too, and quite a few of the reader comments on these
>
On Sat, 16 Jun 2001, Matt Dillon wrote:
> This is old. The guys running the tests blew it in so many ways
> that you might as well have just rolled some dice. There's a slashdot
> article on it too, and quite a few of the reader comments on these
> bozos are correct. I especial
With gratuitously non-standard quoting which I fixed, Matt Dillon writes:
> [Matthew Hagerty]
>> Here is a surprisingly unbiased article comparing OSes running
>> hard core network apps. The results are kind of disturbing,
>> with FreeBSD (4.2) coming in last against Linux (RH), Win2k,
>> and S
I'm trying to get Liveice + LAME working on a 4.3-Release box
(to stream to another 4.3-R box running Icecast).
I've configured Liveice to use /dev/dsp (also tried with /dev/dspW),
SOUND_DEVICE, HALF_DUPLEX (also tried FULL_*), and various
combinations of SAMPLE_RATE (trying to get 8000 on both t
E.B. Dreger writes:
> If the programmers who wrote that software used poll() on FreeBSD 4.2,
> then I'd say that they need to RTFM and learn about kernel queues and
> accept filters.
You mean they should just optimize for FreeBSD, or should they also
use completion ports on Win2K, /dev/poll on
:> If you intend to push a system to its limits, you damn well better
:> be prepared to tune it properly or you are just wasting your time.
:> On any operating system. You will never find joe-user running his
:> system into the ground with thousands of simultanious connections
:> and ten thousan
Albert D. Cahalan <[EMAIL PROTECTED]> types:
> > I'll bet they didn't even bother compiling up a
> > kernel... something that is utterly trivial in a FreeBSD system, and
> > if they did they certainly didn't bother tuning it.
> Lots of places would not allow this. Heavy tweaking requires heavy
> d
:The only thing that worries me a bit is that both FreeBSD
:and Linux needed to be tuned at all to run these things,
:even if it was just the maximum file descriptor setting.
:
:A lot of this tuning could easily be done dynamically
:(and is done dynamically on linux 2.4), but lots of it
:still ha
On Sat, Jun 16, 2001 at 02:14:14PM -0700, Matt Dillon wrote:
> It's certainly true that a greater degree of dynamic tuning could be
> done, but all this benchmark proves (in regards to the TCP results)
> is that FreeBSD puts its foot down earlier then other OS's in regards
> to ho
At 4:31 PM -0400 6/16/01, Albert D. Cahalan wrote:
>Feel free to post a benchmarking procedure that would let one
>person produce fair results. Results ought to be reproducable:
>you, I, and an NT kernel developer all get the same answers.
Nice ideal. Hard to imagine it happening any time soon.
At 2:04 PM -0700 6/16/01, Matt Dillon wrote:
>:So every FreeBSD server requires an expensive admin to tune it?
>:That Win2K solution is looking good now. :-)
>:
>:These admins now... they never quit their job at just the wrong
>
> Huh? I'm talking about a reasonably smart 16 year old kid who
curses, sent it to a nonexistant mail address before. Anyways, does anyone
have any time to look at this, and tell me why it's a bad idea?
-- Forwarded Message --
Subject: Re: i386/26994: AMD Athlon Thunderbird not known to identcpu.c
Date: Sat, 16 Jun 2001 17:32:06 -0400
From
On Sat, Jun 16, 2001 at 04:31:41PM -0400, Albert D. Cahalan wrote:
> I guess it's fair to shove Linux deep into swap (as pro-FreeBSD
> benchmarkers always do), but not fair to make FreeBSD handle a
> large directory?
Well... no. This test did stress FreeBSD's ability to handle large
directories
From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
Subject: Re: Article: Network performance by OS
Date: Sat, 16 Jun 2001 16:31:41 -0400 (EDT)
> So every FreeBSD server requires an expensive admin to tune it?
> That Win2K solution is looking good now. :-)
That says a lot about your selection criteria
Hi Matt,
On 16-Jun-01 Matt Dillon wrote:
>
>:> If you intend to push a system to its limits, you damn well better
>:> be prepared to tune it properly or you are just wasting your time.
>:> On any operating system. You will never find joe-user running his
>:> system into the ground with thousa
> For this particular benchmark, yes. If you want a rather less
> contrived benchmark, why not compare Apache running under both Windows
> NT and FreeBSD/Linux/Solaris? It's available for all those platforms
> and given that you're running the same application, it would be a fair
> assumption t
Hi,
one of my applications uses the SGI State Threads Library
(I/O multiplexing scheduler). At its heart is a function
which concatenates the pollfd arrays of all threads and calls
poll(2). As sockets are shared between threads, the size of
the final pollfd array can eas
Hello,
In order to perform a valid benchmark for stricly performance issues and let
aside stability trade offs,
A fair benchmark would be to purchase 3 exact systems, update BIOS, then
deploy Linux, FreeBSD, and Windows2k.
Tune them to the max, each perspective that could be modified to increase
* Sascha Schumann <[EMAIL PROTECTED]> [010616 19:03] wrote:
> Hi,
>
> one of my applications uses the SGI State Threads Library
> (I/O multiplexing scheduler). At its heart is a function
> which concatenates the pollfd arrays of all threads and calls
> poll(2). As sockets ar
Quoth Poul-Henning Kamp on Wed, Jun 13, 2001:
> In message <[EMAIL PROTECTED]>, Jordan Hubbard writes:
> >From: Bill Vermillion <[EMAIL PROTECTED]>
> >> We just need to hide all the code from the lawyers.
> >
> >Why? They wouldn't understand it anyway. What we really need to do
> >is stop HIRING
* Jonathan Fortin <[EMAIL PROTECTED]> [010616 19:13] wrote:
> Hello,
>
> In order to perform a valid benchmark for stricly performance issues and let
> aside stability trade offs,
> A fair benchmark would be to purchase 3 exact systems, update BIOS, then
> deploy Linux, FreeBSD, and Windows2k.
>
At 6:37 PM -0400 6/16/01, Brian Mitchell wrote:
>I'm not convinced there is any such thing as a fair benchmark,
>nor am I convinced that benchmarks are valuable. Clearly the
>benchmark cited is flawed, but what benchmark is not?
I must admit I (personally) have a major ambivalence towards
benchma
:a pool machine for a project or customer visit, fixing the switches when they
:blow up after a power cut, or restoring the Exhange databases...They
:don't even manage to find the time to recompile a Solaris kernel!
:
:Dynamic tuning would be ideal to help our IT get best performance out of NFS
:a
> Are you sure?
The code references the per-process limit
(p->p_rlimit[RLIMIT_NOFILE].rlim_cur).
> That would mean that the pollfd array is larger than the amount
> of open files you're allowed.
Right, the concatenation of multiple pollfd arrays does not
eliminate multiple occur
This is not really a "hardcore networking app" but a custom app written by
the person who did the benchmark. The main reason that FreeBSD came in
last was mostly because the guy didn't mount his filesystem correctly.
On Sat, 16 Jun 2001, Matthew Hagerty wrote:
> Greetings,
>
> Here is a surpris
On Sat, 16 Jun 2001, Jonathan Fortin wrote:
> Linux is tuned out of the box, where the others are tuned for
> stability.
Not quite. Linux distributions tend to be extremely
conservative in the IDE options (DMA, interrupt unmasking,
write caching, etc. all disabled) while FreeBSD seems to
have wr
On Fri, Jun 15, 2001 at 12:37:35AM -0700, Terry Lambert wrote:
> The thing that pisses me off most about the use of pid
> files is that on any border device, you are generally
> going to run at least two DNS servers (interior, exterior),
> and will probably run two SMTP servers, and even two HTTP
Greetings All,
I just wanted to thank everyone for the responses! I did not mean to start
such a debated thread. I'm glad to have the information about why FreeBSD
place so poorly in these "idiot's" tests. I'll have to write SysAdmin a
letter now and ask them why the hell they would publish
Rik van Riel <[EMAIL PROTECTED]> writes:
> Not quite. Linux distributions tend to be extremely
> conservative in the IDE options (DMA, interrupt unmasking,
> write caching, etc. all disabled) while FreeBSD seems to
> have write caching and DMA on by default...
Ahem.
First of all, Linux' file sys
Bind DNS already has this capability: the "options" section
has a directive "pid-file" that you can set to whatever you
desire. For example, on the external server's configuration
you might add:
options {
pid-file "/var/run/named.external.pid";
...
};
And, you'll probably
49 matches
Mail list logo