Re: import NetBSD rc system (multiple DNS servers)

2001-06-16 Thread Joe Landers

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 want use a "controls" section as well
with something like:

controls {
unix "/var/run/ndc-external" perm 0600 owner 0 group 0;
};

Joe Landers

- Original Message - 
From: Shannon <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 16, 2001 8:59 PM
Subject: Re: import NetBSD rc system


> 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
> > servers and two inetd's.
> > 
> > Putting everything in /var/run under the name of the
> > program gets to be dirt stupid real fast...
> 
> As currently done, sure. But I don't see any huge obstacles in the
> way of extending the rc.d scripts to handle multiple invocations of
> a daemon, and keep track of them. Something similar to how multiple
> interfaces are configured would work, and a simple extension of 
> ${DAEMIN}.pid would suffice for tracking them.  If that gets too
> messy for you, then you probably have a custom setup anyway, and
> will be rolling your own.
> 
> -- 
> [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article Network performance by OS

2001-06-16 Thread Dag-Erling Smorgrav

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 (ext2fs) is more or less equivalent,
in terms of performance and integrity, to async ffs.  This gives Linux
a big performance edge out of the box, and FreeBSD a big reliability
edge - but benchmark authors rarely care about fs integrity, as
shutting off the power during heavy disk I/O isn't generally part of
their benchmark.

Second, we tried turning write caching on ATA drives off by default,
and boy were you (the user community) pissed.  Yes, turning wc off
shows you just how crappy those non-tagged-queueing 4000 RPM ATA
drives you picked up at Fry's for some pocket change are.  So we
turned it back on.  If you're not happy with that, put 'hw.ata.wc="0"'
in your /boot/loader.conf and they'll be off after the next reboot.
Or get real disks.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matthew Hagerty

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 such an article.  I 
hope I'm not wasting my money subscribing to the magazine...

Again, thank you all for the information!  I have been using FreeBSD since 
Release-1.1 (I downloaded the binary install disks via AOL!!) and have used 
every version since.  I have also tried Solaris, Linux, BSDI, Windows, and 
NetBSD, but I keep coming back to FreeBSD.  One day I hope to be able to 
contribute my share as well.

Thanks,
Matthew


At 02:42 PM 6/16/2001 -0400, Matthew Hagerty 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).
>
>http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm
>
>The tests were performed against the TCP/IP implementation on these 
>platforms with different system calls.  File systems tests (EXT2 for 
>Linux, UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were 
>performed by creating writing, and reading 10,000 files in the same 
>directory, increasing the file size from 4K to 128K.  Tests of various 
>network applications based on number of simultaneous connections, 
>process-based vs. thread-based, and sync vs. async connection handling 
>were also performed.
>
>Hope it might be helpful to you...
>
>Matthew
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread Shannon

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
> servers and two inetd's.
> 
> Putting everything in /var/run under the name of the
> program gets to be dirt stupid real fast...

As currently done, sure. But I don't see any huge obstacles in the
way of extending the rc.d scripts to handle multiple invocations of
a daemon, and keep track of them. Something similar to how multiple
interfaces are configured would work, and a simple extension of 
${DAEMIN}.pid would suffice for tracking them.  If that gets too
messy for you, then you probably have a custom setup anyway, and
will be rolling your own.

-- 
[EMAIL PROTECTED]  _
__/ armchairrocketscientistgraffitiexenstentialist
 "And in billows of might swell the Saxons before her,-- Unite, oh
 unite!  Or the billows burst o'er her!" -- Downfall of the Gael

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article Network performance by OS

2001-06-16 Thread Rik van Riel

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 write caching and DMA on by default...

Both systems have tuning out of the box in different ways.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Kenneth Wayne Culver

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 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 performed against the TCP/IP implementation on these 
> platforms with different system calls.  File systems tests (EXT2 for Linux, 
> UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by 
> creating writing, and reading 10,000 files in the same directory, 
> increasing the file size from 4K to 128K.  Tests of various network 
> applications based on number of simultaneous connections, process-based vs. 
> thread-based, and sync vs. async connection handling were also performed.
> 
> Hope it might be helpful to you...
> 
> Matthew
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: poll(2)'s arbitrary limit

2001-06-16 Thread Sascha Schumann

> 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 occurences of fds in userland.  So, we
might end up with n * p_rlimit[RLIMIT_NOFILE] entries where n
is any number >= 1.  I have not evaluated yet the feasibility
of eliminating multiple occurences as that would involve
adding complexity for a special case to quite generic code.

> I think it may be a good idea to actually allow double
> RLIMIT_NOFILE and FD_SETSIZE for flexibility.

Yes.  What do you think about adding a sysctl which defines
the maximum size (e.g. kern.maxpollfds)?  That could be
initialized to kern.maxfilesperproc to maintain the current
behaviour.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matt Dillon

: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
:and Samba serving project data whilst also running Verilog/VDHL sims on the
:same box. I guess that this may never get to "best performance" for a given app,
:and, as such would not want to remove the possibility of tuning.

Why are you assuming that tuning takes a lot of effort?  One good sysop
is all you need.  One man-week and then you are done.  That's it.  We
aren't talking about having an entire department working 24x7 for a
year tuning machines.  We are talking about *ONE* person who tunes the
machines on the side.  The amount of effort required is zero...  That
is how it works on UNIX systems... Linux, FreeBSD, Solaris, whatever.
Tuning a UNIX box is extremely easy to do and extremely easy to
replicate.  It doesn't matter whether you have one machine or a hundred.
Not taking the time to tune your machines is roughly equivalent to
running a 6 cylinder engine on 4 cylinders. 

This is true whether you are a small shop or a big shop, whether you 
are a startup or a fortune-500 company, whether your UNIX machines
are servers or workstations.   There is no 'if'.  Anyone who
depends on the default configuration of their systems and anyone who
isn't willing to maintain them after they've been installed is throwing
away money.  Lots of money.  It's that simple.  If your IT department
isn't up to the task then maybe you should consider firing them.

-Matt

:Duncan
:
:---
:
:Duncan Barclay  | God smiles upon the little children,

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Garance A Drosihn

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
benchmarks.  I want to see them, I'm always interested in
reading them, and yet at the end of the day I almost never
really believe anything they say...

Well, some ones I believe, if there are very few significant
variables between the things being benchmarked.  Comparing
PowerPC 603's to PowerPC 603e's, for instance.

Once you get to anything where you're changing cpu's AND
os's AND compilers AND hardware AND hw configurations AND
OS configuration experience, AND AND AND...   well, it's
just hopeless.  At best they give you some ideas of what
should be done differently in "a follow-up benchmark",
to maybe perhaps get a more valid comparison on that one.
Not that I'll believe that one either, but I might at least
think "it's a better comparison".

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article Network performance by OS

2001-06-16 Thread Alfred Perlstein

* 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 them to the max, each perspective that could be modified to increase
> performance, then run silly write/read test, connect() test whatever.
> 
> And in your test, show all the performance options you used and whatnot, and
> this benchmark should be redone periodly with new advices to show people
> what OS is the fastest when it's leg is pulled.
> 
> As for the benchmark briefly, It's biased because whoever did it knew fuck
> nothing about Unix and Linux doesnt need tuning so Linux won period.
> Linux is tuned out of the box, where the others are tuned for stability.

Linux is not "tuned out of the box", Linux just allows for just
about any subsystem to monopolize the kernel resources.  Basically
when you start to stress multiple subsystems on a Linux box that
isn't tuned properly it all goes to hell.  This is because for
example your network buffers might eat up too much memory for you
to be able to do a reasonable job at caching files.

Also, I really hate it when people say Linux's disk IO is fast
compared to FreeBSD, sure it's fast, but at the expense of possible
massive corruption on a crash.

Oh wait, Linux doesn't crash, does it? :)

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Patented algorithm in FreeBSD

2001-06-16 Thread Vadim Vygonets

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. :)
> 
> You know, there is almost a fortune in that...

Indeed, Jordan, I would patent this idea if I were you.

Vadik.

-- 
Any language that involves exposing private parts to friends is a
tad suspect...
-- Geoff Lane in the Monastery, about C++

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: poll(2)'s arbitrary limit

2001-06-16 Thread Alfred Perlstein

* 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 shared between threads, the size of
> the final pollfd array can easily be greater than
> RLIMIT_NOFILE.

Are you sure?

#define RLIMIT_NOFILE   8   /* number of open files */

That would mean that the pollfd array is larger than the amount
of open files you're allowed.  I think it may be a good idea to
actually allow double RLIMIT_NOFILE and FD_SETSIZE for flexibility.

Anyone object?

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Article Network performance by OS

2001-06-16 Thread Jonathan Fortin

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
performance, then run silly write/read test, connect() test whatever.

And in your test, show all the performance options you used and whatnot, and
this benchmark should be redone periodly with new advices to show people
what OS is the fastest when it's leg is pulled.

As for the benchmark briefly, It's biased because whoever did it knew fuck
nothing about Unix and Linux doesnt need tuning so Linux won period.
Linux is tuned out of the box, where the others are tuned for stability.

Thank you.

Jonathan



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



poll(2)'s arbitrary limit

2001-06-16 Thread Sascha Schumann

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 easily be greater than
RLIMIT_NOFILE.

Unfortunately, it is impossible to poll more than
RLIMIT_NOFILE descriptors with one system call.  This is
caused by a check in sys/sys_generic.c which was introduced
three months ago:

/*
 * This is kinda bogus.  We have fd limits, but that is not
 * really related to the size of the pollfd array.  Make sure
 * we let the process use at least FD_SETSIZE entries and at
 * least enough for the current limits.  We want to be reasonably
 * safe, but not overly restrictive.
 */
if (nfds > p->p_rlimit[RLIMIT_NOFILE].rlim_cur && nfds > FD_SETSIZE)
return (EINVAL);

What is the chance of getting this changed?  Or, at least
documented?

 [EINVAL]   The specified time limit is negative.

Thanks,
- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Brian Mitchell


> 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 any difference in performance will be due to the OS
> itself and you'll also be able to stand by your benchmark as
> indicative of something people actually CARE about, namely web server
> performance.

I'm not convinced this is a fair test either, particularly  unix vs windows, 
for 2 main reasons:

1) The Apache port has not recieved as much attention as the unix ports, in 
terms of development effort/time

2) Implementations of identical features may take radically different code 
paths, not all of which are equivilant in performance. There may indeed be 
better ways of implementing feature X on windows than on unix, but because 
it's a port, those implementations may not have been used.

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?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Duncan Barclay

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 thousands of simultanious connections
>:> and ten thousand files in a mail directory, so it's silly to
>:> configure the system from a joe-user perspective.
>:
>: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 bothers
> to spend a little time learning how a platform works.  I don't
> know what you are talking about.  Expensive sysadmin?  Where did that
> come from?  Any bozo with half a brain who has spent more then a week
> playing with FreeBSD in a serious way can tune it better then the idiots
> who ran the benchmark.

Whilst I agree with your sentiment I would like to bring in the spectre of the
"real world". There are many diverse usage models in the world. The "benchmark"
under discussion aims to rate various platforms running a package for
ISPs. But, I wonder where the majority of FreeBSD/Unix boxes actually live?

To take an example - where I work. We are an electronic engineering design
consultancy and have a wide mix of projects. The basic IT infrastructure is
Windows, a mix of W98, NT4 and W2k with a few Suns for IC design. We have
about 200 people on site. The majority of IT support is NOT tuning the
machines for best performance (whether it be W2k cross compiling for an embedded
system or the Suns for IC design), but just keeping up with people needing
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
and Samba serving project data whilst also running Verilog/VDHL sims on the
same box. I guess that this may never get to "best performance" for a given app,
and, as such would not want to remove the possibility of tuning.

> A person who depends on the ability to run an out-of-the-box solution
> into the ground and actually expects it to perform well without having
> to know the first thing about the platform he is running his software
> on is a complete and utter idiot and the company that employs such a
> person has a hellofalot more to worry about then the performance of an
> untuned machine.

I agree iff the business depends on the solution as its value prop. (e.g. ISP)
but, I am sure that there are many more businesses that just use a box as tool
to create their value prop. (e.g. an IC vendor). What do we do in those cases?
They do not have the staff expertise to tune, to get the best out of the tens of
applications that must be run to achieve the overall business goals.

As a genuine question, does anyone have an idea of what the split of Suns/HPs
/SGIs etc. is between "internet/intranet server" vs. "work station on a desk"
is?
 
>   -Matt

Duncan

---

Duncan Barclay  | God smiles upon the little children,
[EMAIL PROTECTED]   | the alcoholics, and the permanently stoned.
[EMAIL PROTECTED]| Steven King

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Jordan Hubbard

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 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?

This is a foolish comparison.  It's not all that rare to have a system
suffer temporary (or even continuous) spikes in demand which cause it
to go "deep into swap" whereas anyone stuffing tens of thousands of
files into directory is simply an idiot who doesn't understand what
databases are for.  It's a serious apples-and-oranges comparison.

> Biased against Win2K maybe, which beat FreeBSD without any tuning at all.

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 any difference in performance will be due to the OS
itself and you'll also be able to stand by your benchmark as
indicative of something people actually CARE about, namely web server
performance.

All this trolling merely reminds me of the benchmark paper presented a
few USENIXes ago which showed Solaris to be almost a factor of 10
slower than Linux when calling getpid() 50,000 times in a row.  Of
course the comparison was also blatantly unfair since Solaris had
extra lock overhead imposed by the fact that it was fully SMP capable
whereas (at the time) Linux was not.  Lies, damn lies, and statistics.

You want fair benchmarking, there it is.  Go put your money where your
mouth all too frequently is, Albert.

- Jordan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Alex Zepeda

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, and that's fine.  Especially since they didn't even bother to
compare it to ReiserFS, which should be much better.  However, they could 
have / should have leveled the playing field with one very simple tweak:

*Mount all filesystems async*

The tests merely tested the effect of the disk's ability to handle tagged
queuing and the disk's ability to cache stuff.

- alex

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Fwd: Re: i386/26994: AMD Athlon Thunderbird not known to identcpu.c

2001-06-16 Thread Brian Mitchell

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: Brian Mitchell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]



I don't have a thundrbird, but has far as I know, k6-2+ supports the extended
cpuid functions, so something like the following may be appropriate. This
worked on my k6-2 and didnt break on any of my other machines (without the
#if defined guards, in my case), but I don't know if there are some oddball
686es that either dont support cpuid or dont support service 0x8000 AND
do bad things when recieving it.


*** identcpu.c.old  Sat Jun 16 16:39:34 2001
--- identcpu.c  Sat Jun 16 17:19:16 2001
***
*** 75,80 
--- 75,81 
  static void print_AMD_info(u_int amd_maxregs);
  static void print_AMD_assoc(int i);
  static void do_cpuid(u_int ax, u_int *p);
+ static int do_ExtendedCPUID(char *buff);

  u_int cyrix_did;  /* Device ID of Cyrix CPU */
  int cpu_class = CPUCLASS_386; /* least common denominator */
***
*** 214,220 
cpu = CPU_PIII;
break;
default:
!   strcat(cpu_model, "Unknown 80686");
break;
}
break;
--- 215,222 
cpu = CPU_PIII;
break;
default:
!   if(do_ExtendedCPUID(cpu_model) < 0)
!   strcat(cpu_model, "Unknown 80686");
break;
}
break;
***
*** 223,229 
cpu = CPU_P4;
break;
default:
!   strcat(cpu_model, "unknown");
break;
}

--- 225,232 
cpu = CPU_P4;
break;
default:
!   if(do_ExtendedCPUID(cpu_model) < 0)
!   strcat(cpu_model, "unknown");
break;
}

***
*** 303,309 
strcat(cpu_model, "K6-III");
break;
default:
!   strcat(cpu_model, "Unknown");
break;
}
  #if defined(I586_CPU) && defined(CPU_WT_ALLOC)
--- 306,313 
strcat(cpu_model, "K6-III");
break;
default:
!   if(do_ExtendedCPUID(cpu_model) < 0)
!   strcat(cpu_model, "Unknown");
break;
}
  #if defined(I586_CPU) && defined(CPU_WT_ALLOC)
***
*** 1001,1003 
--- 1005,1078 
"\0403DNow!"
);
  }
+
+ /*
+  * Get the model of the cpu if it is supported by the processor. This
+  * is probably the ideal way to determine the name of the cpu, if it
+  * is supported.
+  *
+  * Documentation on this can be found at:
+  *
http://developer.intel.com/design/processor/future/manuals/Cpuid_supplement.p
df +  */
+ static int
+ do_ExtendedCPUID(char *buff)
+ {
+ #if defined(I686_CPU)
+   char cpustring[128];
+   unsigned int extCpuidFunc=0;
+
+   /* get the highest cpuid extended func supported */
+   __asm ("
+   movl $0x8000, %%eax
+   cpuid
+   movl %%eax, %0"
+   : "=g" (extCpuidFunc)
+   :
+   : "eax");
+
+   /*
+* if 0x8002 - 0x8004 are not supported, than this processor
+* will not supply us the information we need. We should gracefully
+* exit in that case.
+*/
+   if(extCpuidFunc < 0x8004)
+ #endif
+   return -1;
+ #if defined(I686_CPU)
+
+   /*
+* we can now use cpuid services 0x8002-0x8004 in order to
+* fill our buffer 16 bytes at a time (total buffer provided can
+* be up to 48 bytes).
+*/
+   __asm ("
+   cld
+   lea (%0), %%edi
+   movl $0x8002, %%eax
+   cpuid
+   movl %%eax, (%%edi)
+   movl %%ebx, 4(%%edi)
+   movl %%ecx, 8(%%edi)
+   movl %%edx, 12(%%edi)
+   addl $16, %%edi
+   movl $0x8003, %%edi
+   cpuid
+   movl %%eax, (%%edi)
+   movl %%ebx, 4(%%edi)
+   movl %%ecx, 8(%%edi)
+   movl %%edx, 12(%%edi)
+   addl $16, %%edi
+ 

Re: Article: Network performance by OS

2001-06-16 Thread Garance A Drosihn

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
> bothers to spend a little time learning how a platform works.
> I don't know what you are talking about.

I think he's talking about some of the characters in the upcoming
"Lord of the Rings" movie trilogy, namely, 'the trolls'.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Garance A Drosihn

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.  All
of these OS's have their tricks when installing, and the person
who "knows" the OS thinks nothing of those "simple" tuning issues.
The person who doesn't "know" the OS wouldn't have a clue about
the tuning.

I have the feeling that this thread isn't going to generate
much useful info, if the debate is going to include quasi-
trolls like that.

Mind you, I do agree that it would be very nice if we ["the
industry"] could figure out benchmarking tactics which did
not depend on the knowledge level of the person doing the
benchmark.  It would also be really nice to see lasting
peace in every corner of the globe, but that also isn't
going to happen without divine intervention.  Getting back
to benchmarks, the problem is that as soon as someone designs
a benchmark, some members of the competition (the "competition"
in whatever field is being benchmarked) sits down and figures
out how to "look good on that benchmark".

>So every FreeBSD server requires an expensive admin to tune it?
>That Win2K solution is looking good now. :-)

We have windows servers here at RPI.  They require expensive
admins too.  We're putting up an exchange server right now,
and it's requiring more time, effort and resources to set up
correctly than just about anything we've ever put up in
Unix-land - even though some of our recent hires include good
people who have a lot of experience with Windows (and almost
none with Unix...).

I am sure that for SOME companies in SOME environments, Win2K
is setup "right for them" right out of the box.  However, that
does not hold true for all companies, all environments, or all
usage-patterns.  It just does not universally apply.

Again, this seems more like a troll than any serious or even
realistic discussion of the issues.  My guess is that nothing
much good is going to come from this thread, at the rate it's
going.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Bosko Milekic


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 much it is willing to dedicate to the network.  In a real life
> situation where you may be running a multi-user load or a large database,
> the very last thing you want to do is shift every last bit of your
> resources away from the users or the database and to the network when
> an 'unexpected load' comes in (unexpected meaning something that is a
> factor of 100 or 1000x what the machine normally handles).  The
> truth of the matter is that no amount of dynamic tuning can handle
> every situation... at some point you have to manually tune the box.
> FreeBSD does exactly the right thing on an untuned box by capping the
> network resources.  If the authors want to run the machine into the 
> ground with a benchmark, they have to tune the machine properly to handle
> the load because FreeBSD anyway is more interested in keeping the
> integrity of the machine as a whole together then it is tuning itself
> to match some idiot who thinks he is gods own gift to humanity running
> a benchmark.

This is the best written paragraph on the issue in this entire thread.
This is exactly my philosophy toward the whole thing. And I can tell you from
previous dealings with companies that use FreeBSD as their main platform that
this is one of the main reasons why.

>   -Matt

Regards,
-- 
 Bosko Milekic
 [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matt Dillon


: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 has static maximums which have to be tuned by hand.
:Compile-time tuning for stuff which can be dynamically
:allocated (and freed) is IMHO a big sillyness in the OS.
:
:
:Yes, this report was completely useless as a benchmark,
:but it DID highlight a point where Linux and BSD can be
:improved: dynamic allocation (and freeing) of things
:like file descriptors and socket structures.
:
:regards,
:
:Rik

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 much it is willing to dedicate to the network.  In a real life
situation where you may be running a multi-user load or a large database,
the very last thing you want to do is shift every last bit of your
resources away from the users or the database and to the network when
an 'unexpected load' comes in (unexpected meaning something that is a
factor of 100 or 1000x what the machine normally handles).  The
truth of the matter is that no amount of dynamic tuning can handle
every situation... at some point you have to manually tune the box.
FreeBSD does exactly the right thing on an untuned box by capping the
network resources.  If the authors want to run the machine into the 
ground with a benchmark, they have to tune the machine properly to handle
the load because FreeBSD anyway is more interested in keeping the
integrity of the machine as a whole together then it is tuning itself
to match some idiot who thinks he is gods own gift to humanity running
a benchmark.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Mike Meyer

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
> documentation to be reproducable by a future admin. It adds cost.
> There is a "don't break anything" concern.

Building a custom kernel on BSD isn't heavy tweaking, it's SOP. If you
follow recommended practices, no documentation is required to make the
results reproduceable on that system. If you have good admin
procedures, then no documentation is required to reproduce the system
on new hardware after the other is destroyed in a fire.

> Go on, admit it. The benchmark was fair to FreeBSD, and you just
> don't like to see the results.

Ok, the bechmark was fair. To complete the trio(*), the Pope is a pagan
and bears hold it until they're out of the woods.

They didn't run all the systems in truly out of the box state, and
didn't say *how* the selected what tuning they did. They didn't
discuss the design goals of the systems, which are different and will
influence the effect of measurements.

This was a puff piece masquerading as a benchmark.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matt Dillon


:> 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 files in a mail directory, so it's silly to
:> configure the system from a joe-user perspective.
:
: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 bothers
to spend a little time learning how a platform works.  I don't
know what you are talking about.  Expensive sysadmin?  Where did that
come from?  Any bozo with half a brain who has spent more then a week
playing with FreeBSD in a serious way can tune it better then the idiots
who ran the benchmark.

A person who depends on the ability to run an out-of-the-box solution
into the ground and actually expects it to perform well without having
to know the first thing about the platform he is running his software
on is a complete and utter idiot and the company that employs such a
person has a hellofalot more to worry about then the performance of an
untuned machine.

The reality in the world is that most of these so-called benchmarks are
meaningless.  This one happens to be worse then normal, especially when
the less informed masses start quoting them.  People like me, who have
actually HAD real unplanned loads smash into their FreeBSD boxes, know
exactly how good FreeBSD is in handling those loads.  No contrived 
benchmark can match real world results.  I mean, give me a break, 
create and delete 10,000 files in a directory with softupdates turned
off?  The only time I ever had more then 10,000 queue files in a directory
was running BEST, supporting 30,000+ users and some insanely huge 
mailing lists.  Anyone actually running that kind of load had better be
able to afford (or be) a sysop who at least knows his ass from a hot rock!

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Albert D. Cahalan


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 Solaris, and RT signals
on Linux? What is wrong with using the portable API on every OS?

In an open competition where each team writes the code, sure, it
is fine to use fancy FreeBSD features. Otherwise no, it isn't OK.
FreeBSD shouldn't need nonportable hacks to keep up with Win2K
and Linux.

You're sounding like a Microsoftie, demanding that code be written
to the latest OS-specific API to get decent performance.

> Not to mention that anyone using a kernel "out of the
> box" needs to be larted.

If you run Google or Yahoo, sure. If the admin is really the guy
hired to make web pages selling potted plants, no way.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



trouble with Liveice+LAME

2001-06-16 Thread Theodore Hope

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 to 
stream to slow modem users).  The idea is to plug a cd player
into the "line in" of the sound card and stream it out.

Something that caught my eye is when I bring up Liveice
(on std curses interface) it says "Input ... 16 bit, ... Hz",
the "16 bit" stays unchanged regardless of what I change in
the Liveice cfg file.

Recompiled kernel recognizes the sound card just fine, and
/dev/sndstat shows "pcm0: ESS Solo-1E at io  (1p/1r channels)"

The sound card is fine, because when I plug a portable cd player
into the "line in" of the sound card, I can listen to it
on the speaker output of the same sound card.

This is with LAME 3.88b (not from ports) and the 
latest Liveice (not from ports).

On the surfaace, things seem to work both locally, on the
remote machine running Icecast, and on the windoze pc client
running Winamp.  However, only static garbage comes out on
the windoze Winamp.  After lots of fiddling, I decided to
enable Liveice's "SAVE_FILE"; I ran it for a while and
then took the *.mp3 file it saved and opened it with
Winamp, and it's just static garbage.  So, this suggests
that something's wrong at the very outset (possibly with 
the way LAME is working, or the way Liveice is calling LAME,
etc).  When I "ps" and see how LAME is being called, things
look ok, and "lsof" shows that Liveice is indeed reading
/dev/dsp (not /dev/dspW).

I know this stuff (Liveice+LAME) works under Linux, but
of course I want to use fbsd 4.3-R :-)

Thanks in advance for any tips or pointers.  -T.H.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Albert D. Cahalan


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 (Intel).
>
> 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 like comment #41.
> Don't worry, FreeBSD stacks up just fine in real environments.

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.

>From another post where you tried to list the ways they blew it:

> 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 files in a mail directory, so it's silly to
> configure the system from a joe-user perspective.

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
moment, people always have a hot-spare admin, or you think one
can find and hire a really good admin as soon as needed?

Nobody would ever have an unplanned demand that would run the
"system into the ground with thousands of simultanious connections
and ten thousand files in a mail directory" of course, especially
when the admin isn't available. After all, the OS couldn't cope.
Wait, wasn't this where FreeBSD was supposed to be really good
while Linux and Win2K sucked? Hmmm, interesting.

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?

> Slashdot respondants did a pretty good job identifying the problems
> - network mbufs, softupdates, Robert here just brought up the
> possibility of IDE write caching being turned off, etc etc etc.  The

It was SCSI. Read the article.

> fact that the bozos doing the 'benchmark' knew about sysctl but only
> tuned the file descriptor limit is a pretty good indication of how
> biased they were.

Biased against Win2K maybe, which beat FreeBSD without any tuning at all.
FreeBSD got the same treatment as Solaris and Linux did.

> 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
documentation to be reproducable by a future admin. It adds cost.
There is a "don't break anything" concern.

Every other system was in the same boat, so stop complaining.
Linux got stuck with 2.2.16-22, even though it comes with
friendly interactive kernel config editors.

Go on, admit it. The benchmark was fair to FreeBSD, and you just
don't like to see the results. BTW I'm serious about seeing your
procedure for fair benchmarking.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Rik van Riel

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 like comment #41.  Don't worry,
> FreeBSD stacks up just fine in real environments.

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 has static maximums which have to be tuned by hand.
Compile-time tuning for stuff which can be dynamically
allocated (and freed) is IMHO a big sillyness in the OS.


Yes, this report was completely useless as a benchmark,
but it DID highlight a point where Linux and BSD can be
improved: dynamic allocation (and freeing) of things
like file descriptors and socket structures.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread E.B. Dreger

> 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 are correct.  I especially like comment #41.  Don't worry,
> FreeBSD stacks up just fine in real environments.

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.  Not to mention that anyone using a kernel "out of the
box" needs to be larted.

Personally, I think that article casts more doubt on the authors than on
FreeBSD...


Eddy

---

Brotsman & Dreger, Inc.
EverQuick Internet Division

Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

---

Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS Re: Article: Network performance by OS

2001-06-16 Thread mustafa


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 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
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 like comment #41.  Don't worry,
FreeBSD stacks up just fine in real environments.

-Matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message




___
Palnet Webmail, http://www.palnet.com





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matthew Jacob



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.  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 like comment #41.  Don't worry,
> FreeBSD stacks up just fine in real environments.

Disagree wrt NFS services.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Article: Network performance by OS

2001-06-16 Thread Matt Dillon


:
: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
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 like comment #41.  Don't worry,
FreeBSD stacks up just fine in real environments.

-Matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Article: Network performance by OS

2001-06-16 Thread Matthew Hagerty

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 performed against the TCP/IP implementation on these 
platforms with different system calls.  File systems tests (EXT2 for Linux, 
UFS for FreeBSD and Solaris, and NTFS for Windows 2000) were performed by 
creating writing, and reading 10,000 files in the same directory, 
increasing the file size from 4K to 128K.  Tests of various network 
applications based on number of simultaneous connections, process-based vs. 
thread-based, and sync vs. async connection handling were also performed.

Hope it might be helpful to you...

Matthew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread Daniel Kim

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.

Any Microsoft employee should be able to find an appropriate contact
through their Enterprise Directory or Exchange Global Address List, so
locating the group/division should not be a problem. But the question
is, are they willing to respond?

--dk


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread Bsdguru

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 PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread David O'Brien

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 should continue with it or if it just too much of a change.

Yes it is too much of a change.  Let me restate again that the idea right
now is to just *minimally* port the NetBSD RC scripts.  Once we have a
system booting with RCng, we can see where it blows and discuss changes.
 
-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread David O'Brien

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. I'll
> look at adding the code for it and submitting a patch,

You are going off on a tangent.  You are worried about the flag day
before we even have a flag to run up the poll.

> > > /etc/rc.subr ported
> >
> > What changes were needed here?
> 
> I basically added a function called checkwildno() that is similar to
> checkyesno that returns 1 for NO (plus variants) or '' and returns 0 for
> anything else.  This gets rid of alot of case statements in the modules,
> making them simple if's.

Again, why don't we just concentrate on porting the NetBSD scripts and
not the second system enhancements?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread Gordon Tetlow

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. Where there was departure, I took the
> > current FreeBSD boot scripts and turned them into modules so as to make it
> > very similar to the current system.
>
> What about adding the typical "test foo" logic to the NetBSD files to
> handle both OS's?

I suppose we could do this, but the departures are more like rewrites.
Again, this is all before the network init stage where things are *very*
different (swap comes to mind immediately).

I've written in the gaps for things we have that they don't (entropy
stuff). Again, since my connectivity is dicey, it may be a week.

> > I did make one change that I
> > think will be helpful, I moved pccard initialization to before the
> > mounting of /usr (but after mounting /var). This way people can use pccard
> > for mounting filesystems from /etc/fstab which I don't think you can do
> > now. Anyone have any objections to this move?
>
> Yes, it departs from the NetBSD scripts.  Please see if LukeM will agree
> with this change.  If not, I would like to see consensus we need/want
> this change at this point in time.

This was just an idea (and a bad one at that) due to the death of pccard
in 5.0-R it would be silly to mess with it now.

> > it would require moving
> > pccardd and pccardc to /sbin, but that should be it.
>
> pccardd is dying in 5.0-R according to Warner.  RCng will never be MFCed
> to RELENG_4, so this is a mute point.

Yup, I put in my request for devd to be in /sbin (although it still may
not need to be).

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 should continue with it or if it just too much of a change.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread Gordon Tetlow

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 once NetBSD either accepts the
> patch or rejects it and I know if I need to pull the files off the vendor
> branch or not.

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?

> > /etc/rc ported
> > /etc/rc.shutdown ported
>
> These are problematic as I could not just vendor import them as we
> already have files of these names.  Can you make these two available for
> discussion some where?
>

I like Matt's idea (I think it was Matt) to have a new_rc switch. I'll
look at adding the code for it and submitting a patch, it'll be kinda
dicey this week since I'm on vacation and I'm not sure how much I'll be
online (I'm sitting in the Albany airport atm =) Also, next week is my
last week at my current job before switching jobs (at least I'm not
moving). So it'll be kinda hectic.

> > /etc/rc.subr ported
>
> What changes were needed here?

I basically added a function called checkwildno() that is similar to
checkyesno that returns 1 for NO (plus variants) or '' and returns 0 for
anything else.  This gets rid of alot of case statements in the modules,
making them simple if's.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread Cyrille Lefevre

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 with the 
> same name would be created in this directory. Reversely, when a 
> service shutdown script is completed (or started ?), the state 
> file is removed. This will allow to define the run states easily 
> as empty rc scripts containing only dependency information in them.

how about if a service die or started w/o the rc subsystem ?

Cyrille.
--
home: mailto:[EMAIL PROTECTED]   UNIX is user-friendly; it's just particular
work: mailto:[EMAIL PROTECTED]   about who it chooses to be friends with.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread Mark Valentine

> 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 the utilities, there are still too many obvious
traces of the proprietary product they originally licensed (much of which
was not BSD-derived, and the stuff that was ended up less BSD-like -
try looking at a few of lines of context around the above grep to see
inexplicable traces of TLI interface code).

I suspect that not much if anything is left of the kernel code they initially
deployed, though (which was definitely very un-BSD in origin --you can see from
old NT documentation that it was a STREAMS implementation, but you really don't
want to know what form it took prior to that!-- though it gained some BSD code
later on - can't recall whether any of that was prior to MS getting it).

Microsoft should, however, definitely have been acknowledging BSD code in
their documentation right from the start, until that clause was repealed (the
documentation they bought did).  This includes the Wolverine stuff they gave
out as an add-on to Windows for Workgroups, which had a similar FTP.EXE and
so on (Wolverine was released after the original NT TCP/IP implementation).

However, I can't offer any concrete proof as to whether their core TCP/IP
implementation migrated to BSD code (though I would certainly expect it to
be so, as there wasn't much else to choose from back then if I remember),
and I no longer work alongside folks who might have tracked that stuff better.

Cheers,

Mark.

-- 
Mark Valentine, Thuvia Labs <[EMAIL PROTECTED]>   
"Tigers will do ANYTHING for a tuna fish sandwich."   Mark Valentine uses
"We're kind of stupid that way."   *munch* *munch*and endorses FreeBSD
  --   

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread diman


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 compare it with the BSD code. I've once done such
> a research on the HP-UX pty code (for other reasons) and it matched
> the BSD code practically exactly except for the added spin locks.
>
> -SB


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Sysadmin article

2001-06-16 Thread Jonathan Irwin

(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 beat FreeBSD BTW.
> He did "ulimit -n 8192" on all three UNIX-like systems, and...

(details snipped)

> Hey, no fair! FreeBSD and Solaris got twice as much tuning as
> the Linux box, and NT got none. But you don't like the results,
> so you say this was somehow unfair.
> 
> I'd say the real winner was NT. It mostly kept up with Linux,
> trashed FreeBSD and Solaris, and didn't need any tuning to do it.

All he was doing was increasing the maximum files per process.
Without this the test wouldn't even run properly, so I certainly
wouldn't call it 'performance tuning'.

(...)

> Oh, you mean he should fairly tune them for performance?
> Let's see you tune an NT box as well as your FreeBSD box.
> Except for an open competition, benchmarking on tuned
> boxes is crap. There just isn't any way to be fair.

Agreed.  However the operating systems tested all take a different
approach to what gets included or tuned in a default install.  FreeBSD
(and Solaris AFAIK) both ship with rather conservative defaults.
Linux on the other hand tends to need relatively little tuning 'out of
the box', for example ext2fs can only really be compared to UFS with
softupdates (or mounted async).

I just hope nobody does any of these types of benchmarks on FreeBSD
4.3-RELEASE with IDE disks...  AFAIK all the others leave IDE
write-caching turned on (not sure about Solaris there though).

This thread has probably been going on long enough...

Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

2001-06-16 Thread Drew Eckhardt

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



Re: import NetBSD rc system

2001-06-16 Thread freebsd-hackers

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 FreeBSD boot scripts and turned them into modules so as to make it
> very similar to the current system.

What about adding the typical "test foo" logic to the NetBSD files to
handle both OS's?

> I did make one change that I
> think will be helpful, I moved pccard initialization to before the
> mounting of /usr (but after mounting /var). This way people can use pccard
> for mounting filesystems from /etc/fstab which I don't think you can do
> now. Anyone have any objections to this move?

Yes, it departs from the NetBSD scripts.  Please see if LukeM will agree
with this change.  If not, I would like to see consensus we need/want
this change at this point in time.


> it would require moving
> pccardd and pccardc to /sbin, but that should be it.

pccardd is dying in 5.0-R according to Warner.  RCng will never be MFCed
to RELENG_4, so this is a mute point.

-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: import NetBSD rc system

2001-06-16 Thread David O'Brien -Hackers

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 know if I need to pull the files off the vendor
branch or not.

> /etc/rc ported
> /etc/rc.shutdown ported

These are problematic as I could not just vendor import them as we
already have files of these names.  Can you make these two available for
discussion some where?

> /etc/rc.subr ported

What changes were needed here?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Sysadmin article

2001-06-16 Thread Albert D. Cahalan

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 job if FreeBSD lost?
>>
>> Driver quality varies too, so hardware choice matters. It is
>> not OK to test on identical hardware, unless the purchaser
>> selects random off-the-shelf hardware to avoid any bias.
>>
>> There are 2 sane ways to benchmark:
>>
>> 1. Use an out-of-the box config on randomly selected hardware.
>>This is what a typical low-paid admin will throw together,
>>so it certainly is a valid test. It is best to run this test
>>many times, since an OS may get unlucky with hardware selection.
>>(tuning is equal: none at all)
>
> But this is not a valid test.  I certainly wouldn't hire someone
> who knows NOTHING about the platform to run a critical service on
> it, why would I accept a benchmark run in such a manner?  This is
> a completely ludicrous statement.

Not. Lots of places don't have the time, money, or judgement
to hire an expert. Even if they do, they often don't want to
be stuck relying on that expert too much. Maybe he quits one
day, and soon after that his manager gets stuck rebuilding
the system. It's nice to have an OS doesn't require serious
hacking and careful hardware selection to operate with reasonable
performance.

> The other problem is the impossibility of any such benchmark to
> discover the underlying reasons behind the default configuration.
> Re-run the same test, pulling the power cord once an hour (pretend
> you're in California here) and see which spends most of it's time
> in fsck.

I don't have a problem with that test, even if I may dislike
the results. It is a perfectly reasonable test to run.

>> In the Sysadmin article, the biggest error was that the admin
>> crudely tuned the FreeBSD and Linux boxes.
>
> 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 beat FreeBSD BTW.
He did "ulimit -n 8192" on all three UNIX-like systems, and...

Linux:
 echo 65536 > /proc/sys/fs/file-max

FreeBSD:
 kern.maxfiles=65536
 kern.maxfilesperproc=32768

Solaris:
 set rlim_fd_max=0x8000
 set rlim_fd_cur=0x8000

Hey, no fair! FreeBSD and Solaris got twice as much tuning as
the Linux box, and NT got none. But you don't like the results,
so you say this was somehow unfair.

I'd say the real winner was NT. It mostly kept up with Linux,
trashed FreeBSD and Solaris, and didn't need any tuning to do it.

>> He should have left
>> both with out-of-the-box limits to be fair to NT and Solaris.
>
> No, he should have configured all of them as close to equally as
> possible.

That is pretty much what he did.

Oh, you mean he should fairly tune them for performance?
Let's see you tune an NT box as well as your FreeBSD box.
Except for an open competition, benchmarking on tuned
boxes is crap. There just isn't any way to be fair.

>> It is absurd to suggest that he should have been hacking away
>> at compile-time constants. Every OS had a default kernel.
>
> And nobody on the planet, other than you, would use it for this
> or any other application.

I'd rather not, but I might if I was pressed for time.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



does this affect FreeBSD too?

2001-06-16 Thread John Reynolds


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 Corporation
[EMAIL PROTECTED]  My opinions are mine, not Intel's. Running
[EMAIL PROTECTED]FreeBSD 4.3-STABLE. FreeBSD: The Power to Serve.
http://www.reynoldsnet.org/  Come join us!!! @ http://www.FreeBSD.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message