On Wed, Jun 30, 1999 at 08:02:06PM -0500, Stan Shkolnyy wrote:
> On Wed, 30 Jun 1999, Nik Clayton wrote:
> > Sorry it's taken me a while to reply to this; ironically, most of my time
> > has been spent on freebsd-doc recently.
> >
> > On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny
On Wed, Jun 30, 1999 at 08:02:06PM -0500, Stan Shkolnyy wrote:
> On Wed, 30 Jun 1999, Nik Clayton wrote:
> > Sorry it's taken me a while to reply to this; ironically, most of my time
> > has been spent on freebsd-doc recently.
> >
> > On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny w
On Wed, 30 Jun 1999, Nik Clayton wrote:
> Sorry it's taken me a while to reply to this; ironically, most of my time
> has been spent on freebsd-doc recently.
>
> On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> > I've come to understanding that lack of documentation is prob
On Wed, 30 Jun 1999, Nik Clayton wrote:
> Sorry it's taken me a while to reply to this; ironically, most of my time
> has been spent on freebsd-doc recently.
>
> On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> > I've come to understanding that lack of documentation is proba
:[...]
:
:I guessed I freaked some people out when I declared that I wanted to
:work on the VM system, discussions in the first few months went with
:half of core talking to me like I didn't know jack when I do know at
:least jack, but had to come up to speed on FreeBSDisms
:[...]
:
:I guessed I freaked some people out when I declared that I wanted to
:work on the VM system, discussions in the first few months went with
:half of core talking to me like I didn't know jack when I do know at
:least jack, but had to come up to speed on FreeBSDisms
On Wed, Jun 30, 1999 at 09:01:03PM +0100, Nik Clayton wrote:
> On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> > I've come to understanding that lack of documentation is probably one of
> > the factors that keep the system healthy,
>
> I've just spent five minutes trying t
On Wed, Jun 30, 1999 at 09:01:03PM +0100, Nik Clayton wrote:
> On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> > I've come to understanding that lack of documentation is probably one of
> > the factors that keep the system healthy,
>
> I've just spent five minutes trying to
Sorry it's taken me a while to reply to this; ironically, most of my time
has been spent on freebsd-doc recently.
On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> I've come to understanding that lack of documentation is probably one of
> the factors that keep the system heal
Sorry it's taken me a while to reply to this; ironically, most of my time
has been spent on freebsd-doc recently.
On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote:
> I've come to understanding that lack of documentation is probably one of
> the factors that keep the system healt
Nick Hibma <[EMAIL PROTECTED]> wrote:
>> Programmers need documentation too.
>
>And they are going to scream like mad if there isn't any. But in the end
>they start reading the code anyway, even if there is docu, because they
>don't trust anything but their own eyes and brain.
>
>It's all documen
Nick Hibma wrote:
>> Programmers need documentation too.
>
>And they are going to scream like mad if there isn't any. But in the end
>they start reading the code anyway, even if there is docu, because they
>don't trust anything but their own eyes and brain.
>
>It's all documented in C anyway.
No
Greg Lehey wrote:
> > I've come to understanding that lack of documentation is probably one of
> > the factors that keep the system healthy, because it keeps the unskilled
> > people away. I don't know whether it's true but I read in books that
> > reading code is one of the methods to learn prog
Greg Lehey wrote:
> > I've come to understanding that lack of documentation is probably one of
> > the factors that keep the system healthy, because it keeps the unskilled
> > people away. I don't know whether it's true but I read in books that
> > reading code is one of the methods to learn progr
In message <[EMAIL PROTECTED]> Matthew Hunt writes:
: Security holes are rarely in the kernel, and you can easily keep your
: applications up-to-date without rebooting.
And the ones that re in the kernel tend to be DoS type problems that
force a reboot anyway :-(
Warner
To Unsubscribe: send ma
In message <19990624114734.a96...@wopr.caltech.edu> Matthew Hunt writes:
: Security holes are rarely in the kernel, and you can easily keep your
: applications up-to-date without rebooting.
And the ones that re in the kernel tend to be DoS type problems that
force a reboot anyway :-(
Warner
To
On Saturday, 26 June 1999 at 12:03:59 -0500, Constantine Shkolny wrote:
> On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:[EMAIL PROTECTED]]
> wrote:
>>> Programmers need documentation too.
>>
>> And they are going to scream like mad if there isn't any. But in the end
>> they start reading th
On Saturday, 26 June 1999 at 12:03:59 -0500, Constantine Shkolny wrote:
> On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:hi...@skylink.it]
> wrote:
>>> Programmers need documentation too.
>>
>> And they are going to scream like mad if there isn't any. But in the end
>> they start reading the
On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:[EMAIL PROTECTED]]
wrote:
> > Programmers need documentation too.
>
> And they are going to scream like mad if there isn't any. But in the end
> they start reading the code anyway, even if there is docu, because they
> don't trust anything but
On Saturday, June 26, 1999 8:08 AM, Nick Hibma [SMTP:hi...@skylink.it]
wrote:
> > Programmers need documentation too.
>
> And they are going to scream like mad if there isn't any. But in the end
> they start reading the code anyway, even if there is docu, because they
> don't trust anything but th
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote:
>
> And they are going to scream like mad if there isn't any. But in the end
> they start reading the code anyway, even if there is docu, because they
> don't trust anything but their own eyes and brain.
ports system == really really l
On Sat, Jun 26, 1999 at 03:08:10PM +0200, Nick Hibma wrote:
>
> And they are going to scream like mad if there isn't any. But in the end
> they start reading the code anyway, even if there is docu, because they
> don't trust anything but their own eyes and brain.
ports system == really really la
> On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote:
> > But one thing I like is, although FreeBSD *does* try to appease user
> > demands, it's controlled by programmers, not users, so if something is
> > a technically extemely evil idea, no matter how the masses yell for it,
> > it will
> On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote:
> > But one thing I like is, although FreeBSD *does* try to appease user
> > demands, it's controlled by programmers, not users, so if something is
> > a technically extemely evil idea, no matter how the masses yell for it,
> > it will
Hi Chuck,
On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote:
> But one thing I like is, although FreeBSD *does* try to appease user
> demands, it's controlled by programmers, not users, so if something is
> a technically extemely evil idea, no matter how the masses yell for it,
> it wil
Hi Chuck,
On Wed, Jun 23, 1999 at 07:20:56PM -0400, Chuck Robey wrote:
> But one thing I like is, although FreeBSD *does* try to appease user
> demands, it's controlled by programmers, not users, so if something is
> a technically extemely evil idea, no matter how the masses yell for it,
> it will
On Thu, 24 Jun 1999, Mike Smith wrote:
> > It's stupid to tune everything for performance except for the web
> > server -- they should be using Zeus, not Apache.
>
> The Zeus evaluation license prohibits its use for benchmarks, and the
> Zeus folks failed to respond to any of my attempts to com
On Thu, 24 Jun 1999, Mike Smith wrote:
> > It's stupid to tune everything for performance except for the web
> > server -- they should be using Zeus, not Apache.
>
> The Zeus evaluation license prohibits its use for benchmarks, and the
> Zeus folks failed to respond to any of my attempts to comm
On Thu, 24 Jun 1999, Arun Sharma wrote:
> You mean [EMAIL PROTECTED] ? I've been reading the list for a while,
> but haven't seen any code there. Am I missing something ?
I've just redirected some stuff there, and
there's some stuff that will be sent there shortly.
>
> -Arun
>
>
T
On Thu, 24 Jun 1999, Arun Sharma wrote:
> You mean freebsd-...@freebsd.org ? I've been reading the list for a while,
> but haven't seen any code there. Am I missing something ?
I've just redirected some stuff there, and
there's some stuff that will be sent there shortly.
>
> -Arun
>
>
On Thu, Jun 24, 1999 at 10:56:07PM -0700, Julian Elischer wrote:
> Alan Cox has just started passing around some code that starts on the
> breakdown of the GKL
>
> I suggest that all intersted parties go to the SMP list
> if they wish to take part in this action.
You mean [EMAIL PROTECTED] ? I'v
On Thu, Jun 24, 1999 at 10:56:07PM -0700, Julian Elischer wrote:
> Alan Cox has just started passing around some code that starts on the
> breakdown of the GKL
>
> I suggest that all intersted parties go to the SMP list
> if they wish to take part in this action.
You mean freebsd-...@freebsd.org
Alan Cox has just started passing around some code that starts on the
breakdown of the GKL
I suggest that all intersted parties go to the SMP list
if they wish to take part in this action.
On Thu, 24 Jun 1999, Chuck Robey wrote:
> On Thu, 24 Jun 1999, David E. Cross wrote:
>
> > I think mutex
Alan Cox has just started passing around some code that starts on the
breakdown of the GKL
I suggest that all intersted parties go to the SMP list
if they wish to take part in this action.
On Thu, 24 Jun 1999, Chuck Robey wrote:
> On Thu, 24 Jun 1999, David E. Cross wrote:
>
> > I think mutex
On Fri, 25 Jun 1999, Kris Kennaway wrote:
> On Thu, 24 Jun 1999, Alfred Perlstein wrote:
>
> > Pardon the niaveness of this idea, but things like per-CPU
> > malloc areas and each CPU haveing a queue for CPUs if
> > memory is free'd by a processor that down't "own" it.
> > Things like someone si
On Fri, 25 Jun 1999, Kris Kennaway wrote:
> On Thu, 24 Jun 1999, Alfred Perlstein wrote:
>
> > Pardon the niaveness of this idea, but things like per-CPU
> > malloc areas and each CPU haveing a queue for CPUs if
> > memory is free'd by a processor that down't "own" it.
> > Things like someone sig
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> Pardon the niaveness of this idea, but things like per-CPU
> malloc areas and each CPU haveing a queue for CPUs if
> memory is free'd by a processor that down't "own" it.
> Things like someone signalling another processor if one of its
> free queues
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> Pardon the niaveness of this idea, but things like per-CPU
> malloc areas and each CPU haveing a queue for CPUs if
> memory is free'd by a processor that down't "own" it.
> Things like someone signalling another processor if one of its
> free queues b
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> On Thu, 24 Jun 1999, Brian F. Feldman wrote:
>
> > On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> >
> > > On Thu, 24 Jun 1999, Karl Denninger wrote:
> > >
> > > A simple start would be to explicitly put a macro or call in each
> > > syscall to pu
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> On Thu, 24 Jun 1999, Brian F. Feldman wrote:
>
> > On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> >
> > > On Thu, 24 Jun 1999, Karl Denninger wrote:
> > >
> > > A simple start would be to explicitly put a macro or call in each
> > > syscall to pus
On Thu, 24 Jun 1999, Brian F. Feldman wrote:
> On Thu, 24 Jun 1999, Alfred Perlstein wrote:
>
> > On Thu, 24 Jun 1999, Karl Denninger wrote:
> >
> > A simple start would be to explicitly put a macro or call in each
> > syscall to push down the lock. That way people can move that
> > macro far
On Thu, 24 Jun 1999, Brian F. Feldman wrote:
> On Thu, 24 Jun 1999, Alfred Perlstein wrote:
>
> > On Thu, 24 Jun 1999, Karl Denninger wrote:
> >
> > A simple start would be to explicitly put a macro or call in each
> > syscall to push down the lock. That way people can move that
> > macro fart
On Thu, 24 Jun 1999, David E. Cross wrote:
> > A simple start would be to explicitly put a macro or call in each
> > syscall to push down the lock. That way people can move that
> > macro farther and farther down in the syscall code path, hopefully
> > removing it entirely in some cases. I thi
On Thu, 24 Jun 1999, David E. Cross wrote:
> > A simple start would be to explicitly put a macro or call in each
> > syscall to push down the lock. That way people can move that
> > macro farther and farther down in the syscall code path, hopefully
> > removing it entirely in some cases. I thin
On Thu, 24 Jun 1999, David E. Cross wrote:
> I think mutex is the way to go. I am 100% for it, and I think now that this
> problem is getting a good deal of light we should start to do something about
> it.
>
> One of the problems with locks that doesn't seem to have been mentioned
> (although
On Thu, 24 Jun 1999, David E. Cross wrote:
> I think mutex is the way to go. I am 100% for it, and I think now that this
> problem is getting a good deal of light we should start to do something about
> it.
>
> One of the problems with locks that doesn't seem to have been mentioned
> (although I
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> On Thu, 24 Jun 1999, Karl Denninger wrote:
>
> A simple start would be to explicitly put a macro or call in each
> syscall to push down the lock. That way people can move that
> macro farther and farther down in the syscall code path, hopefully
>
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> On Thu, 24 Jun 1999, Karl Denninger wrote:
>
> A simple start would be to explicitly put a macro or call in each
> syscall to push down the lock. That way people can move that
> macro farther and farther down in the syscall code path, hopefully
> r
> A simple start would be to explicitly put a macro or call in each
> syscall to push down the lock. That way people can move that
> macro farther and farther down in the syscall code path, hopefully
> removing it entirely in some cases. I think having the call at
> the beginning of each syscal
> A simple start would be to explicitly put a macro or call in each
> syscall to push down the lock. That way people can move that
> macro farther and farther down in the syscall code path, hopefully
> removing it entirely in some cases. I think having the call at
> the beginning of each syscall
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote:
> > On Thu, 24 Jun 1999, Karl Denninger wrote:
> >
> > > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > > > We're adding some machines at work for (essentially) cgi
>
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote:
> > On Thu, 24 Jun 1999, Karl Denninger wrote:
> >
> > > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > > > We're adding some machines at work for (essentially) cgi
>
On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote:
> On Thu, 24 Jun 1999, Karl Denninger wrote:
>
> > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anythin
On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote:
> On Thu, 24 Jun 1999, Karl Denninger wrote:
>
> > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anything
On Thu, Jun 24, 1999 at 11:14:24AM -0700, Doug wrote:
> >
> > That's the world I lived in (except that I used FreeBSD for the NFS
> > servers as well!) and done properly it works EXTREMELY well.
>
> I'm not going to have that luxury, and I really believe that
> NetApp and it's cousings are
On Thu, Jun 24, 1999 at 11:14:24AM -0700, Doug wrote:
> >
> > That's the world I lived in (except that I used FreeBSD for the NFS
> > servers as well!) and done properly it works EXTREMELY well.
>
> I'm not going to have that luxury, and I really believe that
> NetApp and it's cousings are
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anything less than 2 cpu
> > > boxes, and the current round of testing is going so well that we're
> > > seriously considering 4 cpu boxes because they are not that much more
> >
> Wes Peters <[EMAIL PROTECTED]> wrote:
> >
> >Sorry to follow up on my own message, but I noted today in PCWeek
> >their trip back to the benchmark lab includes ripping 3 CPUs and
> >768M RAM out of the system, to benchmark how Linux and NT perform
> >on "lower-end" hardware. They also allowed t
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anything less than 2 cpu
> > > boxes, and the current round of testing is going so well that we're
> > > seriously considering 4 cpu boxes because they are not that much more
> > >
> >
> > I think it's been pretty well known since the beginning that FreeBSD
> > SMP performance is nothing to cheer about. How does FreeBSD fare
> > against NT or other systems on single processor systems?
>
> Sorry to follow up on my own message, but I noted today in PCWeek
> their trip back
> Wes Peters wrote:
> >
> >Sorry to follow up on my own message, but I noted today in PCWeek
> >their trip back to the benchmark lab includes ripping 3 CPUs and
> >768M RAM out of the system, to benchmark how Linux and NT perform
> >on "lower-end" hardware. They also allowed the RedHat dudes to
>
> >
> > I think it's been pretty well known since the beginning that FreeBSD
> > SMP performance is nothing to cheer about. How does FreeBSD fare
> > against NT or other systems on single processor systems?
>
> Sorry to follow up on my own message, but I noted today in PCWeek
> their trip back t
On Thu, Jun 24, 1999 at 07:27:42PM +0200, Nick Hibma wrote:
> The advantage of frequent reboots and patches is that at least you are
> up to date with security patches. :-)
Security holes are rarely in the kernel, and you can easily keep your
applications up-to-date without rebooting.
--
Matth
On Thu, Jun 24, 1999 at 07:27:42PM +0200, Nick Hibma wrote:
> The advantage of frequent reboots and patches is that at least you are
> up to date with security patches. :-)
Security holes are rarely in the kernel, and you can easily keep your
applications up-to-date without rebooting.
--
Matthe
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > We're adding some machines at work for (essentially) cgi
> > processing only. It was never considered to use anything less than 2 cpu
> > boxes, and the current round of testing is going so
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > We're adding some machines at work for (essentially) cgi
> > processing only. It was never considered to use anything less than 2 cpu
> > boxes, and the current round of testing is going so w
I certainly hope you have applied the recent NFS patches. That should solve
your problem.
--
David Cross | email: [EMAIL PROTECTED]
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.2
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > In short, increasing SMP efficiency should really be a priority
> > for N>2 systems.
>
> Agreed. But this is a BIG job, because to do that you have to solve the
> "one big kernel lock" p
On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> We're adding some machines at work for (essentially) cgi
> processing only. It was never considered to use anything less than 2 cpu
> boxes, and the current round of testing is going so well that we're
> seriously considering 4 cpu boxe
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> > In short, increasing SMP efficiency should really be a priority
> > for N>2 systems.
>
> Agreed. But this is a BIG job, because to do that you have to solve the
> "one big kernel lock" pr
I certainly hope you have applied the recent NFS patches. That should solve
your problem.
--
David Cross | email: cro...@cs.rpi.edu
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.27
On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote:
> We're adding some machines at work for (essentially) cgi
> processing only. It was never considered to use anything less than 2 cpu
> boxes, and the current round of testing is going so well that we're
> seriously considering 4 cpu boxes
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> > Karl Denninger wrote:
> >
> > > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > > machine from web service to Samba for file and print service for PCs
> >
On Thu, 24 Jun 1999, Karl Denninger wrote:
> On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> > Karl Denninger wrote:
> >
> > > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > > machine from web service to Samba for file and print service for PCs
> >
On Wed, 23 Jun 1999, Nik Clayton wrote:
> On Wed, Jun 23, 1999 at 04:39:28PM +0930, Greg Lehey wrote:
> > > But Mark illustrates my point perfectly; developers don't write
> > > documentation. That's what camp followers are for. So far, we have
> > > the ones that whine about the loot and throw
On Wed, 23 Jun 1999, Nik Clayton wrote:
> On Wed, Jun 23, 1999 at 04:39:28PM +0930, Greg Lehey wrote:
> > > But Mark illustrates my point perfectly; developers don't write
> > > documentation. That's what camp followers are for. So far, we have
> > > the ones that whine about the loot and throw
In the tests they used both Zeus AND Apache
On Thu, 24 Jun 1999, Tony Finch wrote:
> Wes Peters <[EMAIL PROTECTED]> wrote:
> >
> >Sorry to follow up on my own message, but I noted today in PCWeek
> >their trip back to the benchmark lab includes ripping 3 CPUs and
> >768M RAM out of the system, t
In the tests they used both Zeus AND Apache
On Thu, 24 Jun 1999, Tony Finch wrote:
> Wes Peters wrote:
> >
> >Sorry to follow up on my own message, but I noted today in PCWeek
> >their trip back to the benchmark lab includes ripping 3 CPUs and
> >768M RAM out of the system, to benchmark how Linu
> The advantage of frequent reboots and patches is that at least you are
> up to date with security patches. :-)
LKM/KLD might help here... with the kernel of your kernel being
essentially a linker :)
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
> The advantage of frequent reboots and patches is that at least you are
> up to date with security patches. :-)
LKM/KLD might help here... with the kernel of your kernel being
essentially a linker :)
cheers
luigi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscr
The advantage of frequent reboots and patches is that at least you are
up to date with security patches. :-)
Nick
> planck(1:327) $ uname -a
> FreeBSD planck 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Mon Jun 23
> 16:49:02 CEST 1997 root:/usr/src/sys/compile/CHDKERNEL i386
>
> planck(1:328
The advantage of frequent reboots and patches is that at least you are
up to date with security patches. :-)
Nick
> planck(1:327) $ uname -a
> FreeBSD planck 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Mon Jun 23
> 16:49:02 CEST 1997 root:/usr/src/sys/compile/CHDKERNEL i386
>
> planck(1:328)
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > machine from web service to Samba for file and print service for PCs
> > running Windows.
>
> Granted. Perhaps we're seeing an artifact of NT's devel
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > machine from web service to Samba for file and print service for PCs
> > running Windows.
>
> Granted. Perhaps we're seeing an artifact of NT's develo
On Thu, Jun 24, 1999 at 10:00:41AM -0500, Karl Denninger wrote:
> I know about the SMP issues. But in many applications going to SMP is
> actually a reliability AND throughput lose (web servers is one example).
> You're better off with 4 machines than 1 big 4-way machine.
The problem is that a l
On Thu, Jun 24, 1999 at 10:00:41AM -0500, Karl Denninger wrote:
> I know about the SMP issues. But in many applications going to SMP is
> actually a reliability AND throughput lose (web servers is one example).
> You're better off with 4 machines than 1 big 4-way machine.
The problem is that a lo
Wes Peters <[EMAIL PROTECTED]> wrote:
>
>Sorry to follow up on my own message, but I noted today in PCWeek
>their trip back to the benchmark lab includes ripping 3 CPUs and
>768M RAM out of the system, to benchmark how Linux and NT perform
>on "lower-end" hardware. They also allowed the RedHat du
Wes Peters wrote:
>
>Sorry to follow up on my own message, but I noted today in PCWeek
>their trip back to the benchmark lab includes ripping 3 CPUs and
>768M RAM out of the system, to benchmark how Linux and NT perform
>on "lower-end" hardware. They also allowed the RedHat dudes to
>switch to an
On Wed, Jun 23, 1999 at 08:48:54PM -0700, Julian Elischer wrote:
> With Uniprocessor things are a lot more equal.
> but we still suck on netbench.
>
> This is due to the exact form of netbench which is exactly nonoptimal for
> FreeBSD.
I'm not interested in benchmarks. I'm interested in real-w
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> Karl Denninger wrote:
>
> > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > machine from web service to Samba for file and print service for PCs
> > running Windows.
>
> Granted. Perhaps we're seein
On Wed, Jun 23, 1999 at 08:48:54PM -0700, Julian Elischer wrote:
> With Uniprocessor things are a lot more equal.
> but we still suck on netbench.
>
> This is due to the exact form of netbench which is exactly nonoptimal for
> FreeBSD.
I'm not interested in benchmarks. I'm interested in real-wo
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote:
> Karl Denninger wrote:
>
> > I've found FreeBSD to outperform NT-anything in any task you throw at the
> > machine from web service to Samba for file and print service for PCs
> > running Windows.
>
> Granted. Perhaps we're seeing
Wes Peters wrote:
>
> Julian Elischer wrote:
> >
> > ok here are some of the problems..
> >
> > Matt's changes allow dd to copy data at 2.5 times the rate it did before.
> > I consider dd to be an application. The problem is due to resource
> > handling in the kernel and results in large amounts
Wes Peters wrote:
>
> Julian Elischer wrote:
> >
> > ok here are some of the problems..
> >
> > Matt's changes allow dd to copy data at 2.5 times the rate it did before.
> > I consider dd to be an application. The problem is due to resource
> > handling in the kernel and results in large amounts o
Julian Elischer wrote:
>
> ok here are some of the problems..
>
> Matt's changes allow dd to copy data at 2.5 times the rate it did before.
> I consider dd to be an application. The problem is due to resource
> handling in the kernel and results in large amounts of Idle CPU time.
>
> Another pr
Julian Elischer wrote:
>
> ok here are some of the problems..
>
> Matt's changes allow dd to copy data at 2.5 times the rate it did before.
> I consider dd to be an application. The problem is due to resource
> handling in the kernel and results in large amounts of Idle CPU time.
>
> Another pri
%
%
%On Wed, 23 Jun 1999, Russell L. Carter wrote:
%
%>
%> %Basically there are some applications and benchmarks for which FreeBSD
%>
%> uh, "benchmarks" only, until evidence is produced otherwise.
[...]
%ok here are some of the problems..
%
%Matt's changes allow dd to copy data at 2.5 times t
%
%
%On Wed, 23 Jun 1999, Russell L. Carter wrote:
%
%>
%> %Basically there are some applications and benchmarks for which FreeBSD
%>
%> uh, "benchmarks" only, until evidence is produced otherwise.
[...]
%ok here are some of the problems..
%
%Matt's changes allow dd to copy data at 2.5 times th
On Wed, 23 Jun 1999, Russell L. Carter wrote:
>
> %Basically there are some applications and benchmarks for which FreeBSD
>
> uh, "benchmarks" only, until evidence is produced otherwise.
>
> Tuning for benchmarks has been around a long long time.
>
> People get worked up about this because
On Wed, 23 Jun 1999, Russell L. Carter wrote:
>
> %Basically there are some applications and benchmarks for which FreeBSD
>
> uh, "benchmarks" only, until evidence is produced otherwise.
>
> Tuning for benchmarks has been around a long long time.
>
> People get worked up about this because t
1 - 100 of 118 matches
Mail list logo
