Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 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 phrase a reply to this that manages > > to convey my complete disagreement without resorting to profanity. > > But why did you do that? Basically, I wanted to make sure my disagreement got on record somewhere, so that if anyone trawls the mailing lists at some point in the future and sees your comments, hopefully they'll also see my reply. I know your original comment was intended at least half in jest. But there'll be people who see it and take it the wrong way -- either by assuming that FreeBSD's attitude is too elitist, or that their efforts at documentation won't be welcome, and so on. N PS: Also, there's the considerable thrill of using naughty words. . . -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 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 phrase a reply to this that manages > > to convey my complete disagreement without resorting to profanity. > > But why did you do that? Basically, I wanted to make sure my disagreement got on record somewhere, so that if anyone trawls the mailing lists at some point in the future and sees your comments, hopefully they'll also see my reply. I know your original comment was intended at least half in jest. But there'll be people who see it and take it the wrong way -- either by assuming that FreeBSD's attitude is too elitist, or that their efforts at documentation won't be welcome, and so on. N PS: Also, there's the considerable thrill of using naughty words. . . -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 probably one of > > the factors that keep the system healthy, > > I've just spent five minutes trying to phrase a reply to this that manages > to convey my complete disagreement without resorting to profanity. But why did you do that? My posting was more stupid than clever and I'm sorry I posted it. I spent five minutes thinking about why people don't document their work. Those thoughts overloaded my weak brain and I decided that there must be some good in not documenting it and I came up with my idea. It sounded so wonderful at that time, that I hurried to share it with others :-) Kind people simply pressed 'D' in their pines but some cruel souls still want to punish me :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 probably one of > > the factors that keep the system healthy, > > I've just spent five minutes trying to phrase a reply to this that manages > to convey my complete disagreement without resorting to profanity. But why did you do that? My posting was more stupid than clever and I'm sorry I posted it. I spent five minutes thinking about why people don't document their work. Those thoughts overloaded my weak brain and I decided that there must be some good in not documenting it and I came up with my idea. It sounded so wonderful at that time, that I hurried to share it with others :-) Kind people simply pressed 'D' in their pines but some cruel souls still want to punish me :-( To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
:[...] : :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 in the code :and the utter lack of documentation. : :[...] : :That quote is from part of a message on another topic (and one which is :off-topic for -hackers). : :Matt's a very talented coder. But he still has to come up to speed on how :things have been done on the FreeBSD project, and how we've diverged from :published documentation (such as "The Design and Implementation") before :he can do useful work. I like to call it "algorithmic rot". In otherwords, after a decade or two the kernel just isn't the squeeky clean implementation it could be. I get screamed at a lot when I try to clean the rot up, because half the time it involves not only documenting code but also rewriting routines that don't actually contain bugs in order to prevent future rot. Kinda like wood sealer. The KASSERT()s work that way too. You put them in to force out the bugs and to prevent new ones from entering. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
:[...] : :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 in the code :and the utter lack of documentation. : :[...] : :That quote is from part of a message on another topic (and one which is :off-topic for -hackers). : :Matt's a very talented coder. But he still has to come up to speed on how :things have been done on the FreeBSD project, and how we've diverged from :published documentation (such as "The Design and Implementation") before :he can do useful work. I like to call it "algorithmic rot". In otherwords, after a decade or two the kernel just isn't the squeeky clean implementation it could be. I get screamed at a lot when I try to clean the rot up, because half the time it involves not only documenting code but also rewriting routines that don't actually contain bugs in order to prevent future rot. Kinda like wood sealer. The KASSERT()s work that way too. You put them in to force out the bugs and to prevent new ones from entering. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 phrase a reply to this that manages > to convey my complete disagreement without resorting to profanity. I just want to publically state for the record that if we ever re-instate the position of FreeBSD president, I'm voting for Nik. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 phrase a reply to this that manages > to convey my complete disagreement without resorting to profanity. I just want to publically state for the record that if we ever re-instate the position of FreeBSD president, I'm voting for Nik. :-) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 healthy, I've just spent five minutes trying to phrase a reply to this that manages to convey my complete disagreement without resorting to profanity. You're talking bollocks. Sorry, I failed. I'm the lesser man for it, I know, and I can only pledge to widen my reading (or buy a set of Shakesperean Insult Fridge Magnets) so that it doesn't happen again. > because it keeps the unskilled people away. And it keeps the skilled people away. You have two systems, one documented, one not. You're looking for something to work on, but don't have a great deal of free time to spend. Which one do you work on? Matthew Dillon, a FreeBSD contributor who has been improving FreeBSD's virtual memory subsystem, NFS implementation, and various other bits and pieces, recently said (in <[EMAIL PROTECTED]> on the [EMAIL PROTECTED] mailing list) [...] 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 in the code and the utter lack of documentation. [...] That quote is from part of a message on another topic (and one which is off-topic for -hackers). Matt's a very talented coder. But he still has to come up to speed on how things have been done on the FreeBSD project, and how we've diverged from published documentation (such as "The Design and Implementation") before he can do useful work. In this respect, Matt's one of the good guys. Not only has he done some sterling coding, but he's also taken the time to contribute documentation explaining not only what he's done, but also what other code in FreeBSD does, and more importantly, *why it does it that way*. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 healthy, I've just spent five minutes trying to phrase a reply to this that manages to convey my complete disagreement without resorting to profanity. You're talking bollocks. Sorry, I failed. I'm the lesser man for it, I know, and I can only pledge to widen my reading (or buy a set of Shakesperean Insult Fridge Magnets) so that it doesn't happen again. > because it keeps the unskilled people away. And it keeps the skilled people away. You have two systems, one documented, one not. You're looking for something to work on, but don't have a great deal of free time to spend. Which one do you work on? Matthew Dillon, a FreeBSD contributor who has been improving FreeBSD's virtual memory subsystem, NFS implementation, and various other bits and pieces, recently said (in <199906262123.oaa04...@apollo.backplane.com> on the committ...@freebsd.org mailing list) [...] 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 in the code and the utter lack of documentation. [...] That quote is from part of a message on another topic (and one which is off-topic for -hackers). Matt's a very talented coder. But he still has to come up to speed on how things have been done on the FreeBSD project, and how we've diverged from published documentation (such as "The Design and Implementation") before he can do useful work. In this respect, Matt's one of the good guys. Not only has he done some sterling coding, but he's also taken the time to contribute documentation explaining not only what he's done, but also what other code in FreeBSD does, and more importantly, *why it does it that way*. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too?
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 documented in C anyway. Not really. The C code defines what a piece of code is doing and how it does it. It does not explain why it is doing what it is doing, and most importantly, why it is doing it the way that it is. In many cases, the code might be written the way it is because that's the first thing that popped into the author's head. In this case, it might not matter if the code is substantially re-arranged. In some cases, the code is written in a particular way because the `more obvious' ways of writing the code didn't meet the author's requirements. Whilst it possible that the particular requirement was `this code must be unintelligible', it's more likely to be a subtle interaction with some other subsystem. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too?
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. Not really. The C code defines what a piece of code is doing and how it does it. It does not explain why it is doing what it is doing, and most importantly, why it is doing it the way that it is. In many cases, the code might be written the way it is because that's the first thing that popped into the author's head. In this case, it might not matter if the code is substantially re-arranged. In some cases, the code is written in a particular way because the `more obvious' ways of writing the code didn't meet the author's requirements. Whilst it possible that the particular requirement was `this code must be unintelligible', it's more likely to be a subtle interaction with some other subsystem. Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
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 programming. Since FreeBSD > > does ship with source code, docs are not necessary. NT ships with poorly > > written docs instead, and, that is what kills it all the time, despite of > > its perfect design that I really like. People write NT drivers without > > full understanding what is going on, so they destabilize the system. > > I can't agree with this theory. Lack of documentation just moves the > degree of skill needed to, for example, write device drivers. > Document less well and your average device driver writer will write a > worse driver, with or without source code access. Source code access > helps too, of course. Coming from someone who's struggled to write a device driver, and then had to move the driver from 2.X, through to 3.X to 4.X (it's currently languishing somewhere along the line of 3.X) - I would wholely agree with Greg. Documentation is _very important_ even more so in a rapidly moving system... Having access to the source code is one thing, but 'c' was not designed for documentation, it was designed to program in... Looking at the current array of drivers in -current you get the idea everyones done it 'slightly differently', and no one comments their code enough to make it 'self documenting', nor has anyone singled out any of the vast array of drivers and said "this is a good example if your writing ISA drivers", or "this is a good one to go from if your writing PCI". Just my annoyed $0.02's worth! :) -Kp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
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 programming. Since FreeBSD > > does ship with source code, docs are not necessary. NT ships with poorly > > written docs instead, and, that is what kills it all the time, despite of > > its perfect design that I really like. People write NT drivers without > > full understanding what is going on, so they destabilize the system. > > I can't agree with this theory. Lack of documentation just moves the > degree of skill needed to, for example, write device drivers. > Document less well and your average device driver writer will write a > worse driver, with or without source code access. Source code access > helps too, of course. Coming from someone who's struggled to write a device driver, and then had to move the driver from 2.X, through to 3.X to 4.X (it's currently languishing somewhere along the line of 3.X) - I would wholely agree with Greg. Documentation is _very important_ even more so in a rapidly moving system... Having access to the source code is one thing, but 'c' was not designed for documentation, it was designed to program in... Looking at the current array of drivers in -current you get the idea everyones done it 'slightly differently', and no one comments their code enough to make it 'self documenting', nor has anyone singled out any of the vast array of drivers and said "this is a good example if your writing ISA drivers", or "this is a good one to go from if your writing PCI". Just my annoyed $0.02's worth! :) -Kp To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
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 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. > > 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 programming. Since FreeBSD > does ship with source code, docs are not necessary. NT ships with poorly > written docs instead, and, that is what kills it all the time, despite of > its perfect design that I really like. People write NT drivers without > full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
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 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. > > 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 programming. Since FreeBSD > does ship with source code, docs are not necessary. NT ships with poorly > written docs instead, and, that is what kills it all the time, despite of > its perfect design that I really like. People write NT drivers without > full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 their own eyes and brain. > > It's all documented in C anyway. 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 programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 their own eyes and brain. > > It's all documented in C anyway. 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 programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 large documentation about ports system == really really large (relatively) Anything else? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 large documentation about ports system == really really large (relatively) Anything else? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
> 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 NOT happen. > > 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. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
> 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 NOT happen. > > 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. Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 NOT happen. Programmers need documentation too. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 NOT happen. Programmers need documentation too. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 communicate. we actually did get permission to use it just in time, we ran it the night before we left rather than sleep :) I think you'd left by that time? anyway, it shot right up to the same peak apache did, but sustained it with much less effort than apache. zeus is indeed well engineered. this is mostly meaningless for you guys, except as a case where finer grained locking would have been nice. part of the parameters of the 'test' was that we were forced to use four dorky 100mb interfaces rather than a nice single gigabit interface that would have aggregated traffic. we had subsystem locks, but this workload had lots of packets coming in through the nics on the cpus and had lots of processes all also trying to get into tcp. yay massive static http churn creating massive conention on the inet/socket subsystems. NT's stack and threaded server held up under this, as does solaris x86.. just something to keep in mind, I guess, applying the usual common sense to how useful these benchmarks are in comparing systems. :) mike, hope to see you again sometime.. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 communicate. we actually did get permission to use it just in time, we ran it the night before we left rather than sleep :) I think you'd left by that time? anyway, it shot right up to the same peak apache did, but sustained it with much less effort than apache. zeus is indeed well engineered. this is mostly meaningless for you guys, except as a case where finer grained locking would have been nice. part of the parameters of the 'test' was that we were forced to use four dorky 100mb interfaces rather than a nice single gigabit interface that would have aggregated traffic. we had subsystem locks, but this workload had lots of packets coming in through the nics on the cpus and had lots of processes all also trying to get into tcp. yay massive static http churn creating massive conention on the inet/socket subsystems. NT's stack and threaded server held up under this, as does solaris x86.. just something to keep in mind, I guess, applying the usual common sense to how useful these benchmarks are in comparing systems. :) mike, hope to see you again sometime.. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP locking (Was Re: Microsoft performance (was: ...))
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 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP locking (Was Re: Microsoft performance (was: ...))
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 > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
SMP locking (Was Re: Microsoft performance (was: ...))
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've been reading the list for a while, but haven't seen any code there. Am I missing something ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SMP locking (Was Re: Microsoft performance (was: ...))
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 ? I've been reading the list for a while, but haven't seen any code there. Am I missing something ? -Arun To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 am sure many have thought it) is deadlocks. You get A waiting > > for B and b with A. With mutexi (plural?) you would lock just the resource > > that you are curently working on, and you would be guaranteed to release it > > (if the programmers do it right, of course ;). The advantage is with Mutex > > is that you don't need to be as omnipotent to use it. > > Did you forget the fact that in order to remove a giant lock set up, so > that you go one step, or multiple steps, below that, the locks below the > giant lock must ALL be there, no mistakes or omissions allowed. > > It's well worth doing, but it's not a deal like adding just one lock, no > sir! > > +--- > Chuck Robey | Interests include any kind of voice or data > [EMAIL PROTECTED] | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. > (301) 220-2114 | > +--- > > > > > > > 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: Microsoft performance (was: ...)
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 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 am sure many have thought it) is deadlocks. You get A waiting > > for B and b with A. With mutexi (plural?) you would lock just the resource > > that you are curently working on, and you would be guaranteed to release it > > (if the programmers do it right, of course ;). The advantage is with Mutex > > is that you don't need to be as omnipotent to use it. > > Did you forget the fact that in order to remove a giant lock set up, so > that you go one step, or multiple steps, below that, the locks below the > giant lock must ALL be there, no mistakes or omissions allowed. > > It's well worth doing, but it's not a deal like adding just one lock, no > sir! > > +--- > Chuck Robey | Interests include any kind of voice or data > chu...@picnic.mat.net | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. > (301) 220-2114 | > +--- > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 signalling another processor if one of its > > free queues becomes full, or if a CPU finds its pool exhausted. > > This sounds a lot like local resource management in a distributed locking > system (the local lock manager obtains covering locks on a pool of resources > and can manage those locally, but can relinquish the locks to another lock > manager when requested if it is holding them but not actually using them). > > Concurrency theory interests me, but I don't have the resources (heh, heh) to > be useful at the moment. Theoretically you can simulate an SMP enviorment by removing the "run to completion" way that the kernel works, basically in UP while the kernel is working, it can't be interupted. By removing that restriction and at the same time putting up boundries on all syscalls to push that down you can pretty much simulate the effect of SMP. The farther you push the barriers down in the codepaths the better things get, with the eventual hope of removing them almost entirely. Right now most kernel utility functions would also need to grab the status of the lock and push it down then restore it apon return. This way malloc and friends can be considered "safe". btw, am I using the word "codepath" correctly? is it even a word? :) -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 signalling another processor if one of its > > free queues becomes full, or if a CPU finds its pool exhausted. > > This sounds a lot like local resource management in a distributed locking > system (the local lock manager obtains covering locks on a pool of resources > and can manage those locally, but can relinquish the locks to another lock > manager when requested if it is holding them but not actually using them). > > Concurrency theory interests me, but I don't have the resources (heh, heh) to > be useful at the moment. Theoretically you can simulate an SMP enviorment by removing the "run to completion" way that the kernel works, basically in UP while the kernel is working, it can't be interupted. By removing that restriction and at the same time putting up boundries on all syscalls to push that down you can pretty much simulate the effect of SMP. The farther you push the barriers down in the codepaths the better things get, with the eventual hope of removing them almost entirely. Right now most kernel utility functions would also need to grab the status of the lock and push it down then restore it apon return. This way malloc and friends can be considered "safe". btw, am I using the word "codepath" correctly? is it even a word? :) -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 becomes full, or if a CPU finds its pool exhausted. This sounds a lot like local resource management in a distributed locking system (the local lock manager obtains covering locks on a pool of resources and can manage those locally, but can relinquish the locks to another lock manager when requested if it is holding them but not actually using them). Concurrency theory interests me, but I don't have the resources (heh, heh) to be useful at the moment. Kris > > > > -Alfred > > > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 becomes full, or if a CPU finds its pool exhausted. This sounds a lot like local resource management in a distributed locking system (the local lock manager obtains covering locks on a pool of resources and can manage those locally, but can relinquish the locks to another lock manager when requested if it is holding them but not actually using them). Concurrency theory interests me, but I don't have the resources (heh, heh) to be useful at the moment. Kris > > > > -Alfred > > > > > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > gr...@freebsd.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | >http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 would motivate people into doing that > > > sort of work. > > > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > > "this function xxx() is safe until this point I can process a lot > > > before actually needing this lock..." > > > "y'know I just have a structure that's not accessable to any other calls > > > that i'm going to fill in, i'll just lift the lock right here" > > > "if I just do this something here, I really am re-entrant and safe.." > > > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > > > > Something along the lines of how spl()s work? And mutex allocation like what > > we do with malloc types, maybe? > > I'm not sure what you mean by the refernce to malloc types, I just > thought something along the lines of mutex_t with an API > for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex "groups", like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex "type" could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... > > Also, some really interesting things could be done via per-CPU > resource pools to lower the amount of contention on objects. > > 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 becomes full, or if a CPU finds its pool exhausted. > > -Alfred > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 would motivate people into doing that > > > sort of work. > > > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > > "this function xxx() is safe until this point I can process a lot > > > before actually needing this lock..." > > > "y'know I just have a structure that's not accessable to any other calls > > > that i'm going to fill in, i'll just lift the lock right here" > > > "if I just do this something here, I really am re-entrant and safe.." > > > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > > > > Something along the lines of how spl()s work? And mutex allocation like what > > we do with malloc types, maybe? > > I'm not sure what you mean by the refernce to malloc types, I just > thought something along the lines of mutex_t with an API > for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex "groups", like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex "type" could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... > > Also, some really interesting things could be done via per-CPU > resource pools to lower the amount of contention on objects. > > 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 becomes full, or if a CPU finds its pool exhausted. > > -Alfred > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 would motivate people into doing that > > sort of work. > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > "this function xxx() is safe until this point I can process a lot > > before actually needing this lock..." > > "y'know I just have a structure that's not accessable to any other calls > > that i'm going to fill in, i'll just lift the lock right here" > > "if I just do this something here, I really am re-entrant and safe.." > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > Something along the lines of how spl()s work? And mutex allocation like what > we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. 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 becomes full, or if a CPU finds its pool exhausted. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 would motivate people into doing that > > sort of work. > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > "this function xxx() is safe until this point I can process a lot > > before actually needing this lock..." > > "y'know I just have a structure that's not accessable to any other calls > > that i'm going to fill in, i'll just lift the lock right here" > > "if I just do this something here, I really am re-entrant and safe.." > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > Something along the lines of how spl()s work? And mutex allocation like what > we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. 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 becomes full, or if a CPU finds its pool exhausted. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 think having the call at > > the beginning of each syscall would motivate people into doing that > > sort of work. > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > "this function xxx() is safe until this point I can process a lot > > before actually needing this lock..." > > "y'know I just have a structure that's not accessable to any other calls > > that i'm going to fill in, i'll just lift the lock right here" > > "if I just do this something here, I really am re-entrant and safe.." > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > If some of the FreeBSD gods (core) said something along the lines > > of we'd like to see the process table have XXX method of access > > and locking people will code it, the same way with the many other > > subsystems. > > > > Things like pmap and UFS and INET will be a royal pain to get > > SMP safe, however baby steps towards lifting the lock for > > simpler subsystems will lead the way. FreeBSD has the > > most intellegent people in the industry working together, > > all that is needed is a starting point. > > 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 am sure many have thought it) is deadlocks. You get A waiting > for B and b with A. With mutexi (plural?) you would lock just the resource > that you are curently working on, and you would be guaranteed to release it > (if the programmers do it right, of course ;). The advantage is with Mutex > is that you don't need to be as omnipotent to use it. Exactly, there are complex problems to deal with with locking certain structures even in the UP model (when to raise spl() and such) My point is that if someone with the experiance defined protocols for locking each subsystem we definetly have enough people to implement it eventually. If the stupbs for this were in place it would motivate people to work on it. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 think having the call at > > the beginning of each syscall would motivate people into doing that > > sort of work. > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > "this function xxx() is safe until this point I can process a lot > > before actually needing this lock..." > > "y'know I just have a structure that's not accessable to any other calls > > that i'm going to fill in, i'll just lift the lock right here" > > "if I just do this something here, I really am re-entrant and safe.." > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > If some of the FreeBSD gods (core) said something along the lines > > of we'd like to see the process table have XXX method of access > > and locking people will code it, the same way with the many other > > subsystems. > > > > Things like pmap and UFS and INET will be a royal pain to get > > SMP safe, however baby steps towards lifting the lock for > > simpler subsystems will lead the way. FreeBSD has the > > most intellegent people in the industry working together, > > all that is needed is a starting point. > > 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 am sure many have thought it) is deadlocks. You get A waiting > for B and b with A. With mutexi (plural?) you would lock just the resource > that you are curently working on, and you would be guaranteed to release it > (if the programmers do it right, of course ;). The advantage is with Mutex > is that you don't need to be as omnipotent to use it. Exactly, there are complex problems to deal with with locking certain structures even in the UP model (when to raise spl() and such) My point is that if someone with the experiance defined protocols for locking each subsystem we definetly have enough people to implement it eventually. If the stupbs for this were in place it would motivate people to work on it. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 am sure many have thought it) is deadlocks. You get A waiting > for B and b with A. With mutexi (plural?) you would lock just the resource > that you are curently working on, and you would be guaranteed to release it > (if the programmers do it right, of course ;). The advantage is with Mutex > is that you don't need to be as omnipotent to use it. Did you forget the fact that in order to remove a giant lock set up, so that you go one step, or multiple steps, below that, the locks below the giant lock must ALL be there, no mistakes or omissions allowed. It's well worth doing, but it's not a deal like adding just one lock, no sir! +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 am sure many have thought it) is deadlocks. You get A waiting > for B and b with A. With mutexi (plural?) you would lock just the resource > that you are curently working on, and you would be guaranteed to release it > (if the programmers do it right, of course ;). The advantage is with Mutex > is that you don't need to be as omnipotent to use it. Did you forget the fact that in order to remove a giant lock set up, so that you go one step, or multiple steps, below that, the locks below the giant lock must ALL be there, no mistakes or omissions allowed. It's well worth doing, but it's not a deal like adding just one lock, no sir! +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > removing it entirely in some cases. I think having the call at > the beginning of each syscall would motivate people into doing that > sort of work. > > "Hey, y'know getppid() is safe, i'll just take the lock out." > "this function xxx() is safe until this point I can process a lot > before actually needing this lock..." > "y'know I just have a structure that's not accessable to any other calls > that i'm going to fill in, i'll just lift the lock right here" > "if I just do this something here, I really am re-entrant and safe.." > > Providing a simple api for spinlocks and mutexes would be very nice. > Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? > If some of the FreeBSD gods (core) said something along the lines > of we'd like to see the process table have XXX method of access > and locking people will code it, the same way with the many other > subsystems. > > Things like pmap and UFS and INET will be a royal pain to get > SMP safe, however baby steps towards lifting the lock for > simpler subsystems will lead the way. FreeBSD has the > most intellegent people in the industry working together, > all that is needed is a starting point. > > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > systems administrator and programmer > Win Telecom - http://www.wintelcom.net/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > removing it entirely in some cases. I think having the call at > the beginning of each syscall would motivate people into doing that > sort of work. > > "Hey, y'know getppid() is safe, i'll just take the lock out." > "this function xxx() is safe until this point I can process a lot > before actually needing this lock..." > "y'know I just have a structure that's not accessable to any other calls > that i'm going to fill in, i'll just lift the lock right here" > "if I just do this something here, I really am re-entrant and safe.." > > Providing a simple api for spinlocks and mutexes would be very nice. > Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? > If some of the FreeBSD gods (core) said something along the lines > of we'd like to see the process table have XXX method of access > and locking people will code it, the same way with the many other > subsystems. > > Things like pmap and UFS and INET will be a royal pain to get > SMP safe, however baby steps towards lifting the lock for > simpler subsystems will lead the way. FreeBSD has the > most intellegent people in the industry working together, > all that is needed is a starting point. > > -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] > systems administrator and programmer > Win Telecom - http://www.wintelcom.net/ > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 would motivate people into doing that > sort of work. > > "Hey, y'know getppid() is safe, i'll just take the lock out." > "this function xxx() is safe until this point I can process a lot > before actually needing this lock..." > "y'know I just have a structure that's not accessable to any other calls > that i'm going to fill in, i'll just lift the lock right here" > "if I just do this something here, I really am re-entrant and safe.." > > Providing a simple api for spinlocks and mutexes would be very nice. > > If some of the FreeBSD gods (core) said something along the lines > of we'd like to see the process table have XXX method of access > and locking people will code it, the same way with the many other > subsystems. > > Things like pmap and UFS and INET will be a royal pain to get > SMP safe, however baby steps towards lifting the lock for > simpler subsystems will lead the way. FreeBSD has the > most intellegent people in the industry working together, > all that is needed is a starting point. 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 am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 would motivate people into doing that > sort of work. > > "Hey, y'know getppid() is safe, i'll just take the lock out." > "this function xxx() is safe until this point I can process a lot > before actually needing this lock..." > "y'know I just have a structure that's not accessable to any other calls > that i'm going to fill in, i'll just lift the lock right here" > "if I just do this something here, I really am re-entrant and safe.." > > Providing a simple api for spinlocks and mutexes would be very nice. > > If some of the FreeBSD gods (core) said something along the lines > of we'd like to see the process table have XXX method of access > and locking people will code it, the same way with the many other > subsystems. > > Things like pmap and UFS and INET will be a royal pain to get > SMP safe, however baby steps towards lifting the lock for > simpler subsystems will lead the way. FreeBSD has the > most intellegent people in the industry working together, > all that is needed is a starting point. 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 am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > > > > 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 > > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > > is a good thing, but at some point the increased network latency exceends > > > > the point of diminishing returns for the redundancy factor. > > > > > > > > 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" problem and go to fine-grained locking. This is a > > > non-trivial job. > > > > We don't need fine-grained locks. We would get good performance if we > > could get (say) per-subsystem locks. > > That's still a non-trivial task. :-) 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 would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > > > > 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 > > > > expensive and our processing is highly CPU bound. I agree that > > > > redundancy > > > > is a good thing, but at some point the increased network latency > > > > exceends > > > > the point of diminishing returns for the redundancy factor. > > > > > > > > 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" problem and go to fine-grained locking. This is a > > > non-trivial job. > > > > We don't need fine-grained locks. We would get good performance if we > > could get (say) per-subsystem locks. > > That's still a non-trivial task. :-) 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 would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > 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" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. That's still a non-trivial task. :-) -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 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 > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > 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" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. That's still a non-trivial task. :-) -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 going to be THE point of access in the next > year or so. They work too well to pass up, and now that they are OEM'ing > the disk shelves they will be too cheap to justify rolling your own for > all but the most diehard platform advocates. The point I was making, Doug, is that FreeBSD as an NFS client works quite well in my experience, PROVIDED that you are (1) running a "good" code base, and (2) have things set up correctly. I don't argue with the Netapp people; they have a good product that does a good job. The major problme has been the disk cost for a long time; if they're fixing that, then the overall picture will change dramatically and in their favor, which is a good thing. However, that doesn't change the fact that FreeBSD makes quite a good NFS client IF you do things "right". Yes, there are issues. No, they're not impossible to solve. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 going to be THE point of access in the next > year or so. They work too well to pass up, and now that they are OEM'ing > the disk shelves they will be too cheap to justify rolling your own for > all but the most diehard platform advocates. The point I was making, Doug, is that FreeBSD as an NFS client works quite well in my experience, PROVIDED that you are (1) running a "good" code base, and (2) have things set up correctly. I don't argue with the Netapp people; they have a good product that does a good job. The major problme has been the disk cost for a long time; if they're fixing that, then the overall picture will change dramatically and in their favor, which is a good thing. However, that doesn't change the fact that FreeBSD makes quite a good NFS client IF you do things "right". Yes, there are issues. No, they're not impossible to solve. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> > > 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 > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > 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" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. In my neck of the woods (doing lots of multi-threaded stuff), that is the definition of 'fine-grained' locks, vs. 'coarse-grained' locks. What we have now is a big 'coarse-grained' lock. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 dudes to > >switch to an Adaptec SCSI controller to talk to the RAID array. > >How are we holding up under this "diminished" configuration? > > 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 communicate. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> > > 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 > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > 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" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. In my neck of the woods (doing lots of multi-threaded stuff), that is the definition of 'fine-grained' locks, vs. 'coarse-grained' locks. What we have now is a big 'coarse-grained' lock. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> > > > 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 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 Adaptec SCSI controller to talk to the RAID array. > How are we holding up under this "diminished" configuration? We don't have any numbers for that yet, and we cheat a little (using a U2W controller and U2W external RAID unit). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 Adaptec SCSI controller to talk to the RAID array. > >How are we holding up under this "diminished" configuration? > > 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 communicate. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> > > > 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 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 Adaptec SCSI controller to talk to the RAID array. > How are we holding up under this "diminished" configuration? We don't have any numbers for that yet, and we cheat a little (using a U2W controller and U2W external RAID unit). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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. -- Matthew Hunt <[EMAIL PROTECTED]> * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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. -- Matthew Hunt * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 well that we're > > seriously considering 4 cpu boxes because they are not that much more > > expensive and our processing is highly CPU bound. I agree that redundancy > > is a good thing, but at some point the increased network latency exceends > > the point of diminishing returns for the redundancy factor. > > > > 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" problem and go to fine-grained locking. This is a > non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. > > -- > Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net > I ain't even *authorized* to speak for anyone other than myself, so give > up now on trying to associate my words with any particular organization. > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 well that we're > > seriously considering 4 cpu boxes because they are not that much more > > expensive and our processing is highly CPU bound. I agree that redundancy > > is a good thing, but at some point the increased network latency exceends > > the point of diminishing returns for the redundancy factor. > > > > 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" problem and go to fine-grained locking. This is a > non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. > > -- > Karl Denninger (k...@denninger.net) Web: fathers.denninger.net > I ain't even *authorized* to speak for anyone other than myself, so give > up now on trying to associate my words with any particular organization. > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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" problem and go to fine-grained locking. This is a > non-trivial job. No argument there. My point was more in support of the people who were demonstrating how other platforms are kicking our ass. Responding with, "Yeah, but if you limit yourself to the specific case where freebsd performs well, we rock!" doesn't cut it. > > However notice I said, "when my box is running." So > > far it's fallen down on NFS issues so many times that it's currently > > sidelined. > > What release are you running? Started with 3.2-Stable, moved to -Current to get the latest and greatest NFS fixes, the problem is that most of the fixes are for the server, and my box is an amd/nfs client connecting to sun (almost all 2.6) servers. I've posted rather voluminously on this topic to both -current and -hackers over the past two weeks, but I've stopped doing that because I have nothing new and I haven't gotten any responses in a while. I just checked the archives and a search on those two lists for "heavily and loaded and amd" brings up the threads. I'm actually building world right now to get the latest NFS patch just in case it helps, but I'm not sure how much longer we (my department) can justfiy the expense of me fiddling around with this because we already know that the linux box works. > > Now if we were talking about a uni-processor system doing nothing > > but serving web pages from local disk, I know I'd be kicking some serious > > ass, but that model isn't the real world anymore. Especially as Network > > Appliance boxes become more and more common (and they will be, fast and > > furious) multi-processor and NFS are for all practical purposes already > > the reality now, and will only be more so in the future. > > 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 going to be THE point of access in the next year or so. They work too well to pass up, and now that they are OEM'ing the disk shelves they will be too cheap to justify rolling your own for all but the most diehard platform advocates. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 because they are not that much more > expensive and our processing is highly CPU bound. I agree that redundancy > is a good thing, but at some point the increased network latency exceends > the point of diminishing returns for the redundancy factor. > > 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" problem and go to fine-grained locking. This is a non-trivial job. > > I had an NT machine that ran file and print service for my office (before > > I sold the company). I replaced it with SAMBA on the same hardware. > > > > Performance more than doubled, and the ONLY thing that I changed was the > > operating system. > . > However notice I said, "when my box is running." So > far it's fallen down on NFS issues so many times that it's currently > sidelined. What release are you running? There ARE NFS issues - most of which can be solved. I had to do this all the time running an ISP with a home-grown cluster system that did exactly that - all "real" data was sitting on a couple of big RAID arrays - and served via NFS. > Now if we were talking about a uni-processor system doing nothing > but serving web pages from local disk, I know I'd be kicking some serious > ass, but that model isn't the real world anymore. Especially as Network > Appliance boxes become more and more common (and they will be, fast and > furious) multi-processor and NFS are for all practical purposes already > the reality now, and will only be more so in the future. 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. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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" problem and go to fine-grained locking. This is a > non-trivial job. No argument there. My point was more in support of the people who were demonstrating how other platforms are kicking our ass. Responding with, "Yeah, but if you limit yourself to the specific case where freebsd performs well, we rock!" doesn't cut it. > > However notice I said, "when my box is running." So > > far it's fallen down on NFS issues so many times that it's currently > > sidelined. > > What release are you running? Started with 3.2-Stable, moved to -Current to get the latest and greatest NFS fixes, the problem is that most of the fixes are for the server, and my box is an amd/nfs client connecting to sun (almost all 2.6) servers. I've posted rather voluminously on this topic to both -current and -hackers over the past two weeks, but I've stopped doing that because I have nothing new and I haven't gotten any responses in a while. I just checked the archives and a search on those two lists for "heavily and loaded and amd" brings up the threads. I'm actually building world right now to get the latest NFS patch just in case it helps, but I'm not sure how much longer we (my department) can justfiy the expense of me fiddling around with this because we already know that the linux box works. > > Now if we were talking about a uni-processor system doing nothing > > but serving web pages from local disk, I know I'd be kicking some serious > > ass, but that model isn't the real world anymore. Especially as Network > > Appliance boxes become more and more common (and they will be, fast and > > furious) multi-processor and NFS are for all practical purposes already > > the reality now, and will only be more so in the future. > > 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 going to be THE point of access in the next year or so. They work too well to pass up, and now that they are OEM'ing the disk shelves they will be too cheap to justify rolling your own for all but the most diehard platform advocates. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 because they are not that much more > expensive and our processing is highly CPU bound. I agree that redundancy > is a good thing, but at some point the increased network latency exceends > the point of diminishing returns for the redundancy factor. > > 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" problem and go to fine-grained locking. This is a non-trivial job. > > I had an NT machine that ran file and print service for my office (before > > I sold the company). I replaced it with SAMBA on the same hardware. > > > > Performance more than doubled, and the ONLY thing that I changed was the > > operating system. > . > However notice I said, "when my box is running." So > far it's fallen down on NFS issues so many times that it's currently > sidelined. What release are you running? There ARE NFS issues - most of which can be solved. I had to do this all the time running an ISP with a home-grown cluster system that did exactly that - all "real" data was sitting on a couple of big RAID arrays - and served via NFS. > Now if we were talking about a uni-processor system doing nothing > but serving web pages from local disk, I know I'd be kicking some serious > ass, but that model isn't the real world anymore. Especially as Network > Appliance boxes become more and more common (and they will be, fast and > furious) multi-processor and NFS are for all practical purposes already > the reality now, and will only be more so in the future. 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. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > > > running Windows. > > > > Granted. Perhaps we're seeing an artifact of NT's developers focussing > > on optimizing their system for good benchmark performance rather than > > good real-world performance. > > > > 'twill be interesting to see the offical report to find out where the > > various strengths and weaknesses really are. > > > >- mark > > Yes. > > One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm > not at all sure why this happens, but I suspect that a big part of it is > concurrency issues within the kernel and filesystem. > > BUT - for most REAL applications that configuration is a lose. For example, > for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) > than one big box with a 4-way SMP system. Why? Because I get both better > performance that way AND redundancy - if one box fails, I still have > three more, all of which are working. If one box fails in a 4-way > SMP configuration I have nothing at all. 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 expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N>2 systems. > I had an NT machine that ran file and print service for my office (before > I sold the company). I replaced it with SAMBA on the same hardware. > > Performance more than doubled, and the ONLY thing that I changed was the > operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the "optimized idle loop" that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, "when my box is running." So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that "so far freebsd is way ahead on the hassle factor" so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 > > > running Windows. > > > > Granted. Perhaps we're seeing an artifact of NT's developers focussing > > on optimizing their system for good benchmark performance rather than > > good real-world performance. > > > > 'twill be interesting to see the offical report to find out where the > > various strengths and weaknesses really are. > > > >- mark > > Yes. > > One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm > not at all sure why this happens, but I suspect that a big part of it is > concurrency issues within the kernel and filesystem. > > BUT - for most REAL applications that configuration is a lose. For example, > for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) > than one big box with a 4-way SMP system. Why? Because I get both better > performance that way AND redundancy - if one box fails, I still have > three more, all of which are working. If one box fails in a 4-way > SMP configuration I have nothing at all. 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 expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N>2 systems. > I had an NT machine that ran file and print service for my office (before > I sold the company). I replaced it with SAMBA on the same hardware. > > Performance more than doubled, and the ONLY thing that I changed was the > operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the "optimized idle loop" that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, "when my box is running." So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that "so far freebsd is way ahead on the hassle factor" so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too?(was: cvs commit: src/sys/isa sio.c))
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 mud at us when we march > > > too slowly, but not enough of the ones that sew our banners, mend our > > > pots and pans, or teach our version of the gospel to the heathens we > > > subdue. > > > > You can never get enough of them. > > And you don't get them by calling them "camp followers" either. > > You get them by supporting them. Documentation doesn't spring out of > thin air. If (to pick an example) the new syscons stuff[1] is undocumented > then someone's got to document it. > Working on some particularly boring, and in my opinion usless documentation for work. It occured to me that in recalling the various flavors of UNIX, going back to version 6, that when the system is well documented, it is the the last version. Best example System Vr4. What this means? I don't know. If somebody would like to pay me the going rate for my services, for 6 months or so I might be willing to provide them with what ever documentation they wanted, for that six months anyway. Which is to say, that when you pay me, you get to tell me what to work on. When I work for free, I work on whatever I like. Functionality, is more important/interesting than documentation. > Right now, that can only be done by the original developers. In three > month's time we might have enough people who have written code with it > that they could do it. I see no evidence that the number of developers is increasing significantly, or that their focus id changing. > > And in a year's time we might have someone who's been diligently > following the mailing lists and has managed to piece something together > based on what they've soon. Or who has been forced to use this mass of > undocumented code[2], worked out how it works, *and* taken the time to > write the documentation. > We will get good documentation, when somebody decides there is a big enough market for the book, and pays somebody to write it. > So, when do you want useful documentation? > > N > > [1] Chosen at random. I haven't looked at it, so have no idea how clear > or easy to follow the syscons code is. > > [2] See footnote 1 again. > -- > [intentional self-reference] can be easily accommodated using a blessed, > non-self-referential dummy head-node whose own object destructor severs > the links. > -- Tom Christiansen in <[EMAIL PROTECTED]> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
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 mud at us when we march > > > too slowly, but not enough of the ones that sew our banners, mend our > > > pots and pans, or teach our version of the gospel to the heathens we > > > subdue. > > > > You can never get enough of them. > > And you don't get them by calling them "camp followers" either. > > You get them by supporting them. Documentation doesn't spring out of > thin air. If (to pick an example) the new syscons stuff[1] is undocumented > then someone's got to document it. > Working on some particularly boring, and in my opinion usless documentation for work. It occured to me that in recalling the various flavors of UNIX, going back to version 6, that when the system is well documented, it is the the last version. Best example System Vr4. What this means? I don't know. If somebody would like to pay me the going rate for my services, for 6 months or so I might be willing to provide them with what ever documentation they wanted, for that six months anyway. Which is to say, that when you pay me, you get to tell me what to work on. When I work for free, I work on whatever I like. Functionality, is more important/interesting than documentation. > Right now, that can only be done by the original developers. In three > month's time we might have enough people who have written code with it > that they could do it. I see no evidence that the number of developers is increasing significantly, or that their focus id changing. > > And in a year's time we might have someone who's been diligently > following the mailing lists and has managed to piece something together > based on what they've soon. Or who has been forced to use this mass of > undocumented code[2], worked out how it works, *and* taken the time to > write the documentation. > We will get good documentation, when somebody decides there is a big enough market for the book, and pays somebody to write it. > So, when do you want useful documentation? > > N > > [1] Chosen at random. I haven't looked at it, so have no idea how clear > or easy to follow the syscons code is. > > [2] See footnote 1 again. > -- > [intentional self-reference] can be easily accommodated using a blessed, > non-self-referential dummy head-node whose own object destructor severs > the links. > -- Tom Christiansen in <37514...@cs.colorado.edu> > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Beattie| The only problem with beat...@aracnet.com | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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, to benchmark how Linux and NT perform > >on "lower-end" hardware. They also allowed the RedHat dudes to > >switch to an Adaptec SCSI controller to talk to the RAID array. > >How are we holding up under this "diminished" configuration? > > It's stupid to tune everything for performance except for the web > server -- they should be using Zeus, not Apache. > > Tony. > -- > f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] > Winner, International Obfuscated C Code Competition 1998 > > > 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: Microsoft performance (was: ...)
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 Linux and NT perform > >on "lower-end" hardware. They also allowed the RedHat dudes to > >switch to an Adaptec SCSI controller to talk to the RAID array. > >How are we holding up under this "diminished" configuration? > > It's stupid to tune everything for performance except for the web > server -- they should be using Zeus, not Apache. > > Tony. > -- > f.a.n.finch d...@dotat.at f...@demon.net > Winner, International Obfuscated C Code Competition 1998 > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> 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 "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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) $ uptime > 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 > *** > > This server is NOT idling, it's acting (besides other things) as a radius > server servering some thousand dialins. > > Do you need any other arguments? > > \Maex > > -- > SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses > Research & Development| mailto:[EMAIL PROTECTED] | you funny and you need > Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files > D-80807 Muenchen | Fax: +49 (89) 32356-299 | > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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) $ uptime > 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 > *** > > This server is NOT idling, it's acting (besides other things) as a radius > server servering some thousand dialins. > > Do you need any other arguments? > > \Maex > > -- > SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses > Research & Development| mailto:maex-...@space.net | you funny and you > need > Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete > files > D-80807 Muenchen | Fax: +49 (89) 32356-299 | > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 developers focussing > on optimizing their system for good benchmark performance rather than > good real-world performance. > > 'twill be interesting to see the offical report to find out where the > various strengths and weaknesses really are. The weaknesses are obvious and well documented by Microsoft itself. We have a customer that insisted on using NT for its webserver. Yesterday we had trouble with the time stamp in the logs. It simply stopped at a specific time. After that the timestamp was all the same. The problem was: http://support.microsoft.com/support/kb/articles/q223/1/37.asp "This problem can occur if the server runs for more than 49 days without being restarted" 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) $ uptime 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 *** This server is NOT idling, it's acting (besides other things) as a radius server servering some thousand dialins. Do you need any other arguments? \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research & Development| mailto:[EMAIL PROTECTED] | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 developers focussing > on optimizing their system for good benchmark performance rather than > good real-world performance. > > 'twill be interesting to see the offical report to find out where the > various strengths and weaknesses really are. The weaknesses are obvious and well documented by Microsoft itself. We have a customer that insisted on using NT for its webserver. Yesterday we had trouble with the time stamp in the logs. It simply stopped at a specific time. After that the timestamp was all the same. The problem was: http://support.microsoft.com/support/kb/articles/q223/1/37.asp "This problem can occur if the server runs for more than 49 days without being restarted" 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) $ uptime 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 *** This server is NOT idling, it's acting (besides other things) as a radius server servering some thousand dialins. Do you need any other arguments? \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research & Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 loaded 2-way machine is only slightly more expensive than a 1-way, and current trends indicate that 4-ways will be increasingly common. It isn't a question of 1 big 4-way vs 4 1-ways, but of what you can get of out $Xk worth of hardware. The current sweet spot is often some number of 2-ways, and if for your app the OS doesn't scale it can make that OS less economical by comparison. john -- John Bradley Plevyak,PhD,[EMAIL PROTECTED], PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 P:(888)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 loaded 2-way machine is only slightly more expensive than a 1-way, and current trends indicate that 4-ways will be increasingly common. It isn't a question of 1 big 4-way vs 4 1-ways, but of what you can get of out $Xk worth of hardware. The current sweet spot is often some number of 2-ways, and if for your app the OS doesn't scale it can make that OS less economical by comparison. john -- John Bradley Plevyak,PhD,jplev...@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 P:(888)491-1332/5103192436.4911...@pagenet.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 dudes to >switch to an Adaptec SCSI controller to talk to the RAID array. >How are we holding up under this "diminished" configuration? It's stupid to tune everything for performance except for the web server -- they should be using Zeus, not Apache. Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 Adaptec SCSI controller to talk to the RAID array. >How are we holding up under this "diminished" configuration? It's stupid to tune everything for performance except for the web server -- they should be using Zeus, not Apache. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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-world performance and real-world operational work done over units of time. > Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results) 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. > So don't assume that NT figures must be bad.. > we have too many weaknesses in our own code to throw stones. > > It'd be intersting to see how FreeBSD 1.1.5 would have performed on the > same tests. Sometimes we've gained in general performance but lost in > some specific cases. Anyone can tune a kernel or OS for benchmarks. I'm a lot more interested in how it all works in the real world since you don't run benchmarks when you're trying to get real work done. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 an artifact of NT's developers focussing > on optimizing their system for good benchmark performance rather than > good real-world performance. > > 'twill be interesting to see the offical report to find out where the > various strengths and weaknesses really are. > >- mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. Now there ARE monolithic applications that don't take well to that kind of scaling - big DBMS servers, for example. But DBMS servers are typically I/O bound anyway, not CPU bound (there are exceptions, yes, but the general rule is that they are RAM and disk bound). I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. That's but one real-world example out of many. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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-world performance and real-world operational work done over units of time. > Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results) 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. > So don't assume that NT figures must be bad.. > we have too many weaknesses in our own code to throw stones. > > It'd be intersting to see how FreeBSD 1.1.5 would have performed on the > same tests. Sometimes we've gained in general performance but lost in > some specific cases. Anyone can tune a kernel or OS for benchmarks. I'm a lot more interested in how it all works in the real world since you don't run benchmarks when you're trying to get real work done. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 an artifact of NT's developers focussing > on optimizing their system for good benchmark performance rather than > good real-world performance. > > 'twill be interesting to see the offical report to find out where the > various strengths and weaknesses really are. > >- mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. Now there ARE monolithic applications that don't take well to that kind of scaling - big DBMS servers, for example. But DBMS servers are typically I/O bound anyway, not CPU bound (there are exceptions, yes, but the general rule is that they are RAM and disk bound). I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. That's but one real-world example out of many. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 of Idle CPU time. > > > > Another primary problem with the FreeBSD kernel (being addressed by Kirk) > > is that after writing a file, once the data has been queued for IO you > > cannot read the data in that file (even though it is present) until the IO > > is complete. With 64 tags, it is concievable that this could take a half > > second on a modern disk. > > > > These are problems shown up by the benchmarks but > > which can be shown to affect ordinary operations. > > > > There are other problems related to SMP and the GKL.. > > e.g.. two processes cannot access buffers at the same time, even though > > they are both present , because only one of them is allowed in the kernel > > at a time. Therefore One processor will spend a bunch of time at idle.. > > 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 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 Adaptec SCSI controller to talk to the RAID array. How are we holding up under this "diminished" configuration? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 of Idle CPU time. > > > > Another primary problem with the FreeBSD kernel (being addressed by Kirk) > > is that after writing a file, once the data has been queued for IO you > > cannot read the data in that file (even though it is present) until the IO > > is complete. With 64 tags, it is concievable that this could take a half > > second on a modern disk. > > > > These are problems shown up by the benchmarks but > > which can be shown to affect ordinary operations. > > > > There are other problems related to SMP and the GKL.. > > e.g.. two processes cannot access buffers at the same time, even though > > they are both present , because only one of them is allowed in the kernel > > at a time. Therefore One processor will spend a bunch of time at idle.. > > 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 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 Adaptec SCSI controller to talk to the RAID array. How are we holding up under this "diminished" configuration? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 primary problem with the FreeBSD kernel (being addressed by Kirk) > is that after writing a file, once the data has been queued for IO you > cannot read the data in that file (even though it is present) until the IO > is complete. With 64 tags, it is concievable that this could take a half > second on a modern disk. > > These are problems shown up by the benchmarks but > which can be shown to affect ordinary operations. > > There are other problems related to SMP and the GKL.. > e.g.. two processes cannot access buffers at the same time, even though > they are both present , because only one of them is allowed in the kernel > at a time. Therefore One processor will spend a bunch of time at idle.. 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? I think we call consider SMP to be a "work in progress." -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 primary problem with the FreeBSD kernel (being addressed by Kirk) > is that after writing a file, once the data has been queued for IO you > cannot read the data in that file (even though it is present) until the IO > is complete. With 64 tags, it is concievable that this could take a half > second on a modern disk. > > These are problems shown up by the benchmarks but > which can be shown to affect ordinary operations. > > There are other problems related to SMP and the GKL.. > e.g.. two processes cannot access buffers at the same time, even though > they are both present , because only one of them is allowed in the kernel > at a time. Therefore One processor will spend a bunch of time at idle.. 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? I think we call consider SMP to be a "work in progress." -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
% % %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 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. Ok, why doesn't this show up in any of the disk or network benchmarks? %Another primary problem with the FreeBSD kernel (being addressed by Kirk) %is that after writing a file, once the data has been queued for IO you %cannot read the data in that file (even though it is present) until the IO %is complete. With 64 tags, it is concievable that this could take a half %second on a modern disk. That's interesting. %These are problems shown up by the benchmarks but %which can be shown to affect ordinary operations. % %There are other problems related to SMP and the GKL.. %e.g.. two processes cannot access buffers at the same time, even though %they are both present , because only one of them is allowed in the kernel %at a time. Therefore One processor will spend a bunch of time at idle.. Yup. Thanks for filling us in! Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
% % %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 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. Ok, why doesn't this show up in any of the disk or network benchmarks? %Another primary problem with the FreeBSD kernel (being addressed by Kirk) %is that after writing a file, once the data has been queued for IO you %cannot read the data in that file (even though it is present) until the IO %is complete. With 64 tags, it is concievable that this could take a half %second on a modern disk. That's interesting. %These are problems shown up by the benchmarks but %which can be shown to affect ordinary operations. % %There are other problems related to SMP and the GKL.. %e.g.. two processes cannot access buffers at the same time, even though %they are both present , because only one of them is allowed in the kernel %at a time. Therefore One processor will spend a bunch of time at idle.. Yup. Thanks for filling us in! Russell To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 the people who give > out the money to buy the systems use benchmarks to decide > whom to give the money to. > > It's really, really stupid to rely on generic benchmarks. > > But people do, anyway. So I guess whistle and some others should > invest in tuning for the benchmarks. Like jupiter, eh? Or maybe > Apple. > > But for the rest, I wouldn't panic. > > In fact, there's probably some interesting kernel architecture > issues here. Let's hear them, now! If I wanted secrecy about > architecture details there's a shitload less time consuming > ways to do it then follow FreeBSD. 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 primary problem with the FreeBSD kernel (being addressed by Kirk) is that after writing a file, once the data has been queued for IO you cannot read the data in that file (even though it is present) until the IO is complete. With 64 tags, it is concievable that this could take a half second on a modern disk. These are problems shown up by the benchmarks but which can be shown to affect ordinary operations. There are other problems related to SMP and the GKL.. e.g.. two processes cannot access buffers at the same time, even though they are both present , because only one of them is allowed in the kernel at a time. Therefore One processor will spend a bunch of time at idle.. > > Russell > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
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 the people who give > out the money to buy the systems use benchmarks to decide > whom to give the money to. > > It's really, really stupid to rely on generic benchmarks. > > But people do, anyway. So I guess whistle and some others should > invest in tuning for the benchmarks. Like jupiter, eh? Or maybe > Apple. > > But for the rest, I wouldn't panic. > > In fact, there's probably some interesting kernel architecture > issues here. Let's hear them, now! If I wanted secrecy about > architecture details there's a shitload less time consuming > ways to do it then follow FreeBSD. 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 primary problem with the FreeBSD kernel (being addressed by Kirk) is that after writing a file, once the data has been queued for IO you cannot read the data in that file (even though it is present) until the IO is complete. With 64 tags, it is concievable that this could take a half second on a modern disk. These are problems shown up by the benchmarks but which can be shown to affect ordinary operations. There are other problems related to SMP and the GKL.. e.g.. two processes cannot access buffers at the same time, even though they are both present , because only one of them is allowed in the kernel at a time. Therefore One processor will spend a bunch of time at idle.. > > Russell > > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
