Doesn't any one remember Netiquette these days and trim what they are
replying to??
[ thread left below to see how bad this is getting.. ]
On Fri, Jun 15, 2001 at 02:42:35PM -0700, Jordan Hubbard wrote:
This is a good reference, but sadly it only really refers to the
sockets paradigm as first
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
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 did a
bad
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
current
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, and it
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
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 much from
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 file
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/Makefile
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 the OSs.
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
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 there.
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
:
: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 old.
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 article
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
bozos
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 especially
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 Solaris
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
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 thousand
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
: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
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 how
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
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.
I
Hi Matt,
follow ups to -chat
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
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 that
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 are
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 them. :)
* 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.
Tune
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
: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
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
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
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
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 system
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 also
49 matches
Mail list logo
