Re: DragonflyBSD on the desktop (was: Re: Replacing Sendmail with Postfix in the base system)
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > > :Is there an official binary driver policy for > DragonFly? I understand > :people want the fast GUI and stuff to work, > but giving in to the crap > :that companies push on the open source > community isn't acceptable in > :my opinion. Its just going to ultimately > prolong the problem and > :diminish the efforts of people trying to get > companies to open up > :their drivers. > : > :Personally, I would say its good if you don't > support the likes of nvidia. > : > :-Kevin > > I am not particularly interested in > supporting binary only drivers > considering past experience where the > vendors have supplied them, but > then not bothered to keep them up to date > or fix bugs or support > new versions of the OS. NVidia has been > especially anti-social in > this regard. If we want anything that > 'lasts', it has to be native. So you're pledging to rigorously support the 45 (or however many there are) ethernet drivers you inherited from freebsd, plus all new controllers that come out? Have you fixed all of the bugs in the bge driver yet? I see you don't support the intel 82563EB controller on the Woodcrest compatible MB I was looking at. When can I expect to see that? Will I have to donate a board to you to get someone to do/test the driver for it? I'm being a devil's advocate here, but your stance is ridiculous, considering that you don't have the financial resources nor the manpower to support drivers properly yourself. The truth is that only a small handful of drivers have ever been any good in any open source OS; the ones that the one or two guys with the talent to support them use themselves. You used to have to beat David Greenman over the head to add support for intel's latest fxp part, because he was off on some other project and he didn't have the time. Not that any vendor is going to bother doing a driver for DFLY with its pidly user base, but the argument is just silly. The windows model works; the trick is getting enough users for the vendors to care. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: usage accounting inconsistencies
--- Danial Thom <[EMAIL PROTECTED]> wrote: > When applying a constant load (v1.5.3-PREVIEW), > usage is categorized differently in UP mode > than > n SMP model. > > In UP Mode > > CPU-0 state: 0.00% user, 0.00% nice, 0.00% > sys, 32.14% intr, 67.86% idle > > In SMP mode: > > CPU-0 state: 0.00% user, 0.00% nice, > 31.27% > sys, 0.00% intr, 68.73% idle > CPU-1 state: 0.00% user, 0.00% nice, > 0.00% > sys, 1.56% intr, 98.44% idle > > Is this to be expected? It seems to me that if > the handoff to the receive queue marks the end > of > interrupt processing in SMP mode (I assume), > that > it also should be measured that way in UP mode. > It would be nice if they were the same so one > could get a better handle on the efficiencies > or > inefficiencies of the SMP processing. > > DT : : Nearly all interrupts are run on cpu 0. This : isn't going to change : until the APIC interrupt routing infrastructure : is rewritten. : : Matt If thats the case, then why is cpustat showing 'intr' usage only on CPU-1? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: usage accounting inconsistencies
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > Nearly all interrupts are run on cpu 0. > This isn't going to change > until the APIC interrupt routing > infrastructure is rewritten. > > -Matt > I don't think that answers the question. It seems to me that the code that is running on CPU-1 and shown as "system" should also be shown as "system" in UP mode. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
usage accounting inconsistencies
When applying a constant load (v1.5.3-PREVIEW), usage is categorized differently in UP mode than n SMP model. In UP Mode CPU-0 state: 0.00% user, 0.00% nice, 0.00% sys, 32.14% intr, 67.86% idle In SMP mode: CPU-0 state: 0.00% user, 0.00% nice, 31.27% sys, 0.00% intr, 68.73% idle CPU-1 state: 0.00% user, 0.00% nice, 0.00% sys, 1.56% intr, 98.44% idle Is this to be expected? It seems to me that if the handoff to the receive queue marks the end of interrupt processing in SMP mode (I assume), that it also should be measured that way in UP mode. It would be nice if they were the same so one could get a better handle on the efficiencies or inefficiencies of the SMP processing. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
cpustat?
I remember some chatter about cpustat but i don't see it in 1.5.3-PREVIEW, and I don't see that top shows the cpu breakdown. What's the status of this, or what's the utility of choice for monitoring the allocation of cpu resources? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: High interrupt CPU usage in top
--- Mark Cullen <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > Mark Cullen <[EMAIL PROTECTED]> wrote: > > > Taken when the interrupt in top was at > 22%, building world: > > > > > > 320 total > > > 279 clk > > > 37 fxp0 > > > 4 ata1 > > > > > > Taken when the interrupt in top was at 5%, > still building world: > > > > > > 288 total > > > 281 clk > > > 7 fxp0 > > > ata1 > > > > > > Watching it in real-time there are some > spikes where either fxp0 or ata1 > > > will go up to about ~40-60, but it doesn't > really seem to relate to the > > > number seen in top if you ask me... > > > > All of that looks quite normal. It certainly > shouldn't > > account for a significant CPU interrupt > percentage. > > Either top(1) is lying, or something else is > fishy. > > > > Best regards > >Oliver > > > > They were taken with systat as per Danials > suggestion by the way, and I > noticed afterwards it actually shows CPU states > like top, slightly > different from top, probably just due to the > different times they were > started and stuff, but still didn't really seem > to relate to the > relatively high number. > > I have noticed that INVARIANTS is in the > GENERIC kernel config, might > that have anything to do with it? > I just made mysql on a 4.9 Freebsd box and I get 50-80% interrupt usage. Its probably long disk stop-and-waits or something. I'd guess its nothing unusual. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: High interrupt CPU usage in top
--- Mark Cullen <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > Mark Cullen <[EMAIL PROTECTED]> wrote: > > > I don't know if it is anything to be > concerned about, but I seem to be > > > seeing high interrupt CPU usage in top (at > least) when compiling things... > > > > > > --- > > > load averages: 0.81, 0.57, 0.36 > up 0+00:37:49 > > > 15:41:44 > > > 43 processes: 2 running, 41 sleeping > > > CPU states: 37.1% user, 0.0% nice, 27.9% > system, 35.0% interrupt, 0.0% idle > > > > Have you tried "vmstat -i"? It might give an > indication > > if any of the device interrupts is causing > the problem. > > > > I remember a similar problem on FreeBSD > machines where the > > USB interrupt was shared with the NIC > interrupt. The USB > > interrupt handler is quite heavy-weight, so > it slowed down > > the processing of NIC interrupts, even if no > actual USB > > devices were in use at all. Moving the USB > controller to > > a different interrupt (or disabling USB > completely) solved > > the problem. > > > > Best regards > >Oliver > > > > Yep, doesn't look particularly unusual to me > (taken while compiling > multiple things)? > > interrupt total rate > clk 3134621281 > atkbd0 5405 0 > sio10 0 > sio00 0 > fxp0 176854 15 > ppc01 0 > acpi0 0 0 > uhci0/fxp1 0 0 > psm00 0 > ata0 40 0 > ata1 250336 22 > irq19 51 0 > swi_siopoll 0 0 > swi_crypto/swi_camnet 0 0 > swi_cambio 0 0 > swi_vm 0 0 > swi_taskq 0 0 > Total 3567308319 > > Looks like USB is sharing with fxp1? Not that > fxp1 is actually even > plugged in or being used at all at the moment!! > Unfortuantly disabling > USB is not an option for me, I have a USB -> > Serial converter which I > need for the UPS. > You'd have to do a delta as these are from system startup: Run "systat -vmstat 1" while compiling to see it real-time to see where the fat is. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: High interrupt CPU usage in top
--- Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > On 07.06.2006, at 16:41, Mark Cullen wrote: > > I don't know if it is anything to be > concerned about, but I seem to be > > seeing high interrupt CPU usage in top (at > least) when compiling > > things... > > ha! i reported the same, but never found out > the reason. which > hardware (exactly) do you use? > > cheers >simon What I would do is: 2) Try it with 1 cpu enabled. 3) pop on a freebsd 4.x or 5.x and see if I get similar results At least that isolates it to dragonfly, MP or the hardware. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: What is DF aimed at?
--- Dmitri Nikulin <[EMAIL PROTECTED]> wrote: > On 6/5/06, Danial Thom <[EMAIL PROTECTED]> > wrote: > > > > > > --- Matthew Dillon > <[EMAIL PROTECTED]> > > wrote: > > > > > :Uh, how do you get that? Clustering > implies > > > :networking, and Matt has repeatedly stated > > > that > > > :he doesn't really care about network > > > performance. > > > : > > > :And clustering implies servers, which Matt > has > > > :recently and repeatedly stated aren't his > > > focal > > > :point. I don't see how you can have one as > a > > > goal > > > :and not the other. Clustering required > hightly > > > :efficient networking first and foremost. > > > : > > > :DT > > > > > > Er, I said no such thing. You > apparently > > > did not read my > > > posting(s) very carefully. > > > > You said you only wanted "very good > networking" > > and that if you wanted to push traffic at the > > bleeding edge you should get dedicated > hardware > > solutions from cisco. > > > > You know optimizing networking isn't such a > bad > > thing. You can have your cake and eat it too. > > Having stellar networking performance will > not > > hurt your project, nor is it a "waste of > time". > > It would make your OS much more attractive to > a > > much wider user base. Even Intel gave in and > > decided to build a CPU to win the benchmarks. > > People want the best. No-one is going to > notice > > if you're 3rd best, but everyone will notice > if > > you're #1. > > People use Linux and it's far from the best in > security, stability and > for many cases even performance. They use it > because it does a lot and > is marketable. Done. Quality doesn't matter > otherwise it would never > have left the garage. > > Even so, optimizing every last possible drop > from the network stack is > *not* compatible with the goals of this > project. For example, if you > understand the LWKT system and Matt's > presentation/emails regarding > the way socket threads are distributed on > multi-processor systems, > you'll note that they're split by port and > bound to that CPU for their > lifetime. This means that load balancing is not > as optimal as > possible, since actual load is not factored in. > However, work > aggregation is a lot more successful, because > migrations are costly. > Also, the system itself is near lockless and, > as far as localised > network stacks go, impressively optimal > already. > > Since getting proper load balancing of the > threads in would be counter > to DragonFly's very architecture, and since > that optimization itself > has significant downsides and can actually make > a pitifully small > positive difference, there's no point > optimizing to that extreme. This > is an example, I'm sure Matt could conjure many > more cases where the > extra optimization just isn't worth it, but he > has better things to > do. > > I don't know about "stellar" here. Let's wait > until more of the kernel > is MPSAFE, including the network stack, and do > a bench set against a > few instances of FreeBSD and Linux. I'd be more > than happy to try it > out, I've got some em (Intel gigabit) cards and > an X2 4400+ and that's > a nice start. You can try it on your millions > of dollars worth of 10GE > machines. Contribute to the project! You have > money and obviously a > lot of spare time, so help the project out > instead of insulting its > developers. That'll be a good deed and you may > realise just how great > this community is when you're not perceived as > an ass bandit. > > -- Dmitri Nikulin > Why would I contribute to a project that has in 3 days told me: - they don't care about my goals - *nix isn't suitable as a network appliance - it unreasonable for me to not want my console filled with spammy stray interrupt messages, and to go fix it myself - I don't know anything about hardware I think that one thing I got out of the monowall article is that you can't choose an OS that doesn't have as a priority maintaining optimized network performance. I think he's right about that. He's wrong about choosing OpenBSD for a lot of reasons, but I really don't think you're trying to build a general purpose O/S here, because you reject many of the commerical uses of 'BSD as being unimportant to you. You can't be good at something by accident. If there is no effort to be good at something you probably won't be good at it. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Thread will be terminated on monday 'Argh, Stray interrupts 2006'
Seemed appropriate. People that terminate threads because they don't want to fix a problem in their OS because its too much work deserve such. Why can't he just admit that he broke something that was fixed and it needs to be repaired, rather than blaming it on chip manufacturers, and somehow claiming that its not his problem? Its his OS, so its his problem. Its just lame. Or is this OS, if it works ok on my core guy's motherboards, then its good enough? --- [EMAIL PROTECTED] wrote: > All I can really say is, Daniel, you're a > f*cking idiot. > > > Will you also stand on your desk and beat > your > > chest as you delete it? > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: What is DF aimed at?
--- Dmitri Nikulin <[EMAIL PROTECTED]> wrote: > On 6/5/06, Danial Thom <[EMAIL PROTECTED]> > wrote: > > > > > > --- Matthew Dillon > <[EMAIL PROTECTED]> > > wrote: > > > > > :Uh, how do you get that? Clustering > implies > > > :networking, and Matt has repeatedly stated > > > that > > > :he doesn't really care about network > > > performance. > > > : > > > :And clustering implies servers, which Matt > has > > > :recently and repeatedly stated aren't his > > > focal > > > :point. I don't see how you can have one as > a > > > goal > > > :and not the other. Clustering required > hightly > > > :efficient networking first and foremost. > > > : > > > :DT > > > > > > Er, I said no such thing. You > apparently > > > did not read my > > > posting(s) very carefully. > > > > You said you only wanted "very good > networking" > > and that if you wanted to push traffic at the > > bleeding edge you should get dedicated > hardware > > solutions from cisco. > > > > You know optimizing networking isn't such a > bad > > thing. You can have your cake and eat it too. > > Having stellar networking performance will > not > > hurt your project, nor is it a "waste of > time". > > It would make your OS much more attractive to > a > > much wider user base. Even Intel gave in and > > decided to build a CPU to win the benchmarks. > > People want the best. No-one is going to > notice > > if you're 3rd best, but everyone will notice > if > > you're #1. > > People use Linux and it's far from the best in > security, stability and > for many cases even performance. They use it > because it does a lot and > is marketable. Done. Quality doesn't matter > otherwise it would never > have left the garage. > > Even so, optimizing every last possible drop > from the network stack is > *not* compatible with the goals of this > project. For example, if you > understand the LWKT system and Matt's > presentation/emails regarding > the way socket threads are distributed on > multi-processor systems, > you'll note that they're split by port and > bound to that CPU for their > lifetime. This means that load balancing is not > as optimal as > possible, since actual load is not factored in. > However, work > aggregation is a lot more successful, because > migrations are costly. > Also, the system itself is near lockless and, > as far as localised > network stacks go, impressively optimal > already. > > Since getting proper load balancing of the > threads in would be counter > to DragonFly's very architecture, and since > that optimization itself > has significant downsides and can actually make > a pitifully small > positive difference, there's no point > optimizing to that extreme. This > is an example, I'm sure Matt could conjure many > more cases where the > extra optimization just isn't worth it, but he > has better things to > do. > > I don't know about "stellar" here. Let's wait > until more of the kernel > is MPSAFE, including the network stack, and do > a bench set against a > few instances of FreeBSD and Linux. I'd be more > than happy to try it > out, I've got some em (Intel gigabit) cards and > an X2 4400+ and that's > a nice start. You can try it on your millions > of dollars worth of 10GE > machines. Contribute to the project! You have > money and obviously a > lot of spare time, so help the project out > instead of insulting its > developers. That'll be a good deed and you may > realise just how great > this community is when you're not perceived as > an ass bandit. > > -- Dmitri Nikulin > It seems to me, that if your "methods" are sound, that you should be able to beat FreeBsd and linux. Why is that not a worthy goal? FreeBSD 4.x with 1 processor beats linux with 2 by a wide margine. How difficult can it be to simply be better with 2 processors than Freebsd 4.x is with one? Thats really the only criteria for getting past the wall. we all know that freebsd 5.x+ sucks. being better than that shouldnt be something to reject. Dt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: What is DF aimed at?
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > :Uh, how do you get that? Clustering implies > :networking, and Matt has repeatedly stated > that > :he doesn't really care about network > performance. > : > :And clustering implies servers, which Matt has > :recently and repeatedly stated aren't his > focal > :point. I don't see how you can have one as a > goal > :and not the other. Clustering required hightly > :efficient networking first and foremost. > : > :DT > > Er, I said no such thing. You apparently > did not read my > posting(s) very carefully. You said you only wanted "very good networking" and that if you wanted to push traffic at the bleeding edge you should get dedicated hardware solutions from cisco. You know optimizing networking isn't such a bad thing. You can have your cake and eat it too. Having stellar networking performance will not hurt your project, nor is it a "waste of time". It would make your OS much more attractive to a much wider user base. Even Intel gave in and decided to build a CPU to win the benchmarks. People want the best. No-one is going to notice if you're 3rd best, but everyone will notice if you're #1. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > :And the whole fanless, diskless moving parts > BS > :is just so stupid I can't stand it. Its like a > :bunch of college kids sitting around thinking > of > :things to complain about. The guy is using > crap > :hardware, stripped down os and has to put all > the > :design effort into shrinking everything down, > and > :for what? To avoid one failure every 2-3 > years? > :Its just plain stupid, both fiscally and from > an > :engineering standpoint. The guy is still > living > :in the MFM, $2 fan days. I have 1000s of > systems > :in the field with like zero failures. Build > the > :system right and modern hardware doesn't fail > :that easily. > > Thousands, eh? So, million's of dollars > and thousands of unspecified > installed piece of equipment. And, what is > it EXACTLY that you do, > Danial? Because you don't seem to know the > most basic facts about field > installations and hardware longevity. > > But I certainly do. I have equipment that > has been operating at a > major utility district at Lake Tahoe for 20 > years. Not 1 year, not > 2 years, not 5 years... *20* years, and I > can tell you with some > assurance that Fanless and Diskless makes a > *HUGE* difference in > hardware longevity and maintainance > requirements. Using a dedicated > micro operating system also makes a huge > difference when you need to > measure uptime in years rather then months. > It is absolutely and most > definitively *NOT* BS. > > In anycase, this is yet another ridiculous > twisting of the facts. You > seem to twist facts quite often to fit your > view of reality. Maybe > you should actually try *UNDERSTANDING* > other people's viewpoints before > you insult them. "know the basics"? How many network appliances have you sold on modern hardware? You still think the PCI-X bus is "new" for pete's sake. I have about 2000 boxes in the field with Celerons, P4s and Opterons with blowers and IDE hard drives and guess how many of them have come back in the last 2 years? Zippo. Its clowns like you that convince other clowns that things that might have mattered 10 years ago still matter. Who out there are running fanless servers? Nobody. How many of the guys that reported dragonfly uptimes of a year are running on fanless, diskless systems? None of them. The entire concept is a joke conceived by guys who live in a Lab like yourself. Yes, millions of dollars. And the reason is that you can't push 500K pps with a box without a fan or a disk. You have to make too many trade offs, and for no reason whatsoever. The features and functionality you get by using a large disk drive by far outweighs the negatives. The corporate world is not a science project where you get points for doing cool shit. Its about making decisions that make sense. I can't remember the last time I lost a sale because some buffoon required no moving parts. Thats like so 1998. People aren't that stupid. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Thread will be terminated on monday 'Argh, Stray interrupts 2006'
Will you also stand on your desk and beat your chest as you delete it? --- Matthew Dillon <[EMAIL PROTECTED]> wrote: > This thread will be terminated at midnight > (PDT) tonight. As usual I'll > give all parties involved the last word. > Then postings related to it > will start bouncing. > > I am also going to issue a public warning > to Danial Thom... this is > the third time in as many years that you > have seriously disrupted > our mailing lists and it tries even my > patience. If it happens a > fourth time you will be permanently banned > from our mailing lists. > > -Matt > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- W B Hacker <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > > >> > >>Same as always: > >> > >>1) ALT-F2 (3, 4, etc.) before logging in. > >> > >>2) Edit /etc/syslog.conf to send soem/all > >>console messages elsewhere > >>- after which (1) is no longer necessary. > >> > >>Bill > >> > > > > Thats not really a solution > > - you asked for a 'workaround'. This is such. Covering your ears is not a workaround. > > > > > I know I've been told that its a bios > > configuration problem, > > Actually a MB wiring (PCB trace) or *bridge > design flaw that a > BIOS has to work around. Used to occur much > more frequently, > and with OS/2 and Slackware as well as 3.X and > early 4.X *BSD. > > > however I don't get stray > > interrupts if I pop a FreeBSD disk on the > exact > > same hardware. > > > *BSD added a workaround somewhere around 4.6 > IIRC. > > - Prior to that, one had to either swap MB, > (*BSD) or set > printing to polled, not interrupt-driven > (OS/2). > > At one time, some MB even had the problem on > the TTY ports, i.e. > - shortly after rebooting from install, the > console simply > streamed IRQ error messages from getty. > > So why is it a misconfiguration in > > DFLY but not in FreeBSD? > > > > Probably becasue current drivers no longer use > a (supposedly) > obsolete workaround. > > One would have to inspect the par Port drivers > with T86 (or some > other trace tool) to ID it - then a binary > patch should be all > that it takes to fix it (the drivers involved > are dirt-simple, > about 240 Bytes in FORTH, perhaps 2K in ASM > source ~ 1K in > machine-code) - but I last wrote such for the > George Morrow > Design 'Empire' S-100 I/O board - which used > the same chips for > Serial and parallel later adopted for the IBM > PC-1, just > different base addresses. Same FORTH code ran > on the PC1 thru > AT, (112 Kbps serial when IBM was limited to > 9.6 or 19.2 Kbps). > > > - TRY THIS: > > - enter the BIOS and *disable* the parallel > port. > > - if no joy, also disable any on-board sound. There is no parallel port on the machine. A lot of new motherboards are eliminating it. There is also no sound card or on-board audio. Its a server for pete's sake! > > Too often, some idjut has made the support I/O > inter-dependent, > or has such anomalies in the BIOS. > > Nobody seems to work in machine-code anymore, > and that is the > best way to do this low-level stuff w/o > surprises. > > What MB are you using, and whose name is on the > bIOS? Its a Supermicro H8SSL-i. Im not sure of the bios, the machine is quite far away from me at the moment. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Scott Ullrich <[EMAIL PROTECTED]> wrote: > Scott Ullrich wrote: > > Gergo Szakal wrote: > > > >> FYI, the leader of m0n0wall, talking about > the feature of his OS > >> mentioned that DragonFlyBSD is not even > taken into consideration by > >> him to base his system on, 'cause it's > 'desktop oriented.' > > > > > > Actually that is partially untrue. Fred > Wright said this... > > > > Sorry, meant to show the URL: > http://m0n0.ch/wall/list-dev/showmsg.php?id=12/75 this guy needs to come up for air and join the 21st century. Most of his "ideas" are 10 years out of date. Without tearing him to shreds bit by bit, the commercial pull of using *nix for routing is that the economies of scale of using off-the-shelf PC hardware allow you to use so much horsepower for such a small amount of money (relative to dedicated hardware solutions), that the inefficiencies of the design become a positive. Rather than running microkernels on stripped down hardware, you can run full-featured systems and they perform as well or even better than dedicated hardware solutions, for 1/3 the cost. Once you go to specialized hardware, you've lost the key advantage of using the free OS in the first place, which is the rich feature set of the entire O/S. Everything he says is exactly backwards. And the whole fanless, diskless moving parts BS is just so stupid I can't stand it. Its like a bunch of college kids sitting around thinking of things to complain about. The guy is using crap hardware, stripped down os and has to put all the design effort into shrinking everything down, and for what? To avoid one failure every 2-3 years? Its just plain stupid, both fiscally and from an engineering standpoint. The guy is still living in the MFM, $2 fan days. I have 1000s of systems in the field with like zero failures. Build the system right and modern hardware doesn't fail that easily. He's also not looking for performance, so you can't expect him to get excited about MP. And why is he whining about driver support? On an appliance type platform you only need a few drivers to work well. Who cares if the mobo-wonder ethernet card is supported or not? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: What is DF aimed at?
--- Scott Ullrich <[EMAIL PROTECTED]> wrote: > Gergo Szakal wrote: > > On Sat, 03 Jun 2006 19:25:37 -0400 > > Scott Ullrich <[EMAIL PROTECTED]> wrote: > > > > > >>Scott Ullrich wrote: > >> > >>>Gergo Szakal wrote: > >>> > >>> > FYI, the leader of m0n0wall, talking about > the feature of his OS > mentioned that DragonFlyBSD is not even > taken into consideration by > him to base his system on, 'cause it's > 'desktop oriented.' > >>> > >>> > >>>Actually that is partially untrue. Fred > Wright said this... > >>> > >> > >>Sorry, meant to show the URL: > >>http://m0n0.ch/wall/list-dev/showmsg.php?id=12/75 > >> > >> > >>>Manuel still hasn't really weighed in on > DragonFly from what I have > >>>gathered. And you can say that I somewhat > pay close attention to > >>>m0n0wall due to starting the pfSense project > ;) At any rate, this is > >>>now getting way off topic, sorry for the > noise. > >>> > >>>Scott > > > > > > 'The primary foci are as follows: > > > > FreeBSD:Servers > > NetBSD: Portability > > OpenBSD:Security and Reliability > > Dragonfly Desktops' > > > > Maybe I misinterpret, but I really don't want > to argue about this. The devs know what their > purposes are, and me, the user know what mine > are. I don't care about others. So far DF seems > a superb system for me, and I like if the > purposes of a project are sharply outlined > (improper English). So far I had only 1 problem > that I could not resolve, but that is > pkgsrc-wip related. The HDD containing my > install is in the 2nd machine and works > flawlessly. > > > Dragonfly is all about bringing clustering to > the masses. It is pretty > well outlined in our goals section. Uh, how do you get that? Clustering implies networking, and Matt has repeatedly stated that he doesn't really care about network performance. And clustering implies servers, which Matt has recently and repeatedly stated aren't his focal point. I don't see how you can have one as a goal and not the other. Clustering required hightly efficient networking first and foremost. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
Talk about wasting a lot of time! lol --- Dmitri Nikulin <[EMAIL PROTECTED]> wrote: > On 6/4/06, Ben Cadieux <[EMAIL PROTECTED]> > wrote: > > O_o > > > > You guys sure waste a lot of time on trolls. > Too bad Danial didn't > > post any official title, he's starting to > remind me of the Jerry > > Taylor incident. It's pretty clear this guy > is too ignorant to have > > "23 years" of life experience, let alone that > much time using unixes. > > Let's do detective work! > > He seems to have first appeared (at least by > Google's omniscient > perception) around about here: > http://lkml.org/lkml/2005/9/20/129 > > This is a typical "we've broken XYZ so let's > start developing hacks" > lkml thread. He participated with less > harassment intensity than here, > but a little nonetheless. I think that case was > justified. > > Shortly after (well ok, three months), he > posted here: > http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg7.html > This is on a surprisingly similar topic, so I > figured it was something > close to his heart. Still no abuse! He might > not be a pure troll. > > http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00017.html > Arguing with Matt. It happens I suppose. Maybe > he does know something, > who knows? > > http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00108.html > Now that's insulting. > > > So his modus operandi is changing. At first he > made seemingly > innocuous responses in other threads (there are > probably more, that's > the first example I found, and it's a good one) > and escalated to > insults as soon as it seemed to him that he > could undermine a core > developer. Now he goes out and starts > escalating in a fresh thread. > > He's a troll, but a devious one, and probably > actually knows > something. He *doesn't* know that there is no > point in DragonFly > working to be a user-friendly desktop OS now, > since such efforts often > get in the way of Real Work like the heroic > effort Matt has applied to > the kernel architecture, and so would defeat > the point of DragonFly. > We already have DesktopBSD and PC-BSD, and > they're comparable to Linux > in overall quality, so what's the problem? > > A lot of corporations and zealots won't take up > anything with a BSD > license because of the past brain-dead GPL > preaching of ESR and RMS, > and no level of awesome installer will change > their minds. If people > voluntarily used Linux instead of BSD back when > Linux was barely > usable for anything at all > (http://www.spatula.net/proc/linux/index.src), > who could reasonably > expect that the situation will reverse now, > when Linux has billions of > dollars of momentum towards becoming usable, > and BSDs are still > focusing on the much less marketable task of > actually working > properly? > > Heck, in a perfect world, users wouldn't have > been brain-damaged by > Microsoft and Apple and their ideas for how an > interface should work, > which is clearly the polar opposite of anything > actually usable. Then > BSDs and other real unices would be the natural > choice because of > their grand devotion to sanity and > maintainability. But because users > expect the same level of brokeness, security > holes and frequent > architectural failures of Windows in everything > they run these days, > they must turn to Linux distributions to suit > their expectations. Put > someone like that in front of a truly stable, > logical and secure > operating system and they think it's smoke and > mirrors. Bah. > > -- Dmitri Nikulin > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- walt <[EMAIL PROTECTED]> wrote: > James Mansion wrote: > [...] > > Actually I work in a rather large bank and I > write > > trading systems... > > The most important thing I've learned from > reading this > thread is that DragonFly continues to attract > attention > from an amazing variety of bright people all > around the > world. > > Even though I don't understand a lot of the > technical > talk I read in these groups, I think I know > enough > about people to be able to spot competent ones > when I > see them. > > I see no reason to doubt a bright future for > DragonFly. The reason DFLY is getting attention is because there's nothing else out there and we've about had it with the FreeBSD camp. FreeBSD has the right idea, but not the talent to get the job done. Matt unfortunately doesn't understand or care what the market wants; he's more on a personal mission of some sort that has nothing to do with providing the marketplace with the next generation 'BSD performer that it wants. Someone eventually will wrestle either FreeBSD or DFLY away, or branch off and do what needs to be done. Unfortunately it may take longer than a lot of us were hoping for. On the other hand, we may never see a team like the original BSD team talent-wise. The Beatles have broken up, and things may never be the same again. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
Thats why you need a substantial staff to do what you're attempting to do. Whats going to happen when your customer base grows to beyond the 32 guys who think you're God? You've clearly made the problem worse, and you'll have to decide whether you want to fix it, or have people reject using your OS. Thats what product development is all about. People don't want to hear why it doesn't work right. They just want it to work. At some point you'll have to come to terms with that, or you'll fail. DT --- Matthew Dillon <[EMAIL PROTECTED]> wrote: >Er. Danial, you are just being an idiot > now. Programmers are >lazy? Why don't YOU try to reverse engineer > an ethernet card >with half a dozen HARDWARE bugs in it > without vendor documentation! > >Vendors not only do not provide > documentation, they also tend to >hide hardware bugs and deny their existance. > In fact, *MOST* general >purpose PC chipsets these days are chock > full of hardware bugs, nearly >ALL undocumented by the vendor. Vendors > come out with chip revs every >other month, each with their own set of > quirks. There are over *200* >ATA chipsets out there, probably even more, > and just as many ethernet >chipsets. Hundreds of chipsets containing > tens of hundreds of >undocumented hardware bugs. Buggy BIOSes. > Buggy firmware. Even buggy >CPUs (but at least Intel and AMD document > those bugs)! > >You seem to believe that this stuff is > somehow easy to figure out. >And, worse, you seem to believe that we > somehow have an obligation to >drop everything at your whim and spend all > our time solving your >problems. Well, I got news for you... it is > NOT easy to figure out, >and we have no such obligation. > >Open source works because the people > involved are willing to spend >their own time and money solving problems, > and because both programmers >and users alike enjoy a sense of community. > EVERYONE works hard to >achieve their goals. But you don't seem to > think that you have any >obligation at all as an end-user. You seem > to believe that you can >denigrate people and make accusations, call > people lazy, etc etc etc, >and you STILL expect people to solve your > problems? That's pretty stupid, >dude! > >I will tell you straight out that I have no > desire whatsoever to help >you. In fact, I am very close to banning > you from the mailing lists >alltogether because you are becoming > seriously harmful to our community. > >You seem to believe that you are somehow > owed help and that you >don't have to give anything back in return > (not even a friendly >conversation, apparently). You seem to > believe that a programmer can >sit down and in a few hour solve your worst > nightmare of a problem, and >you seem to believe that you can put down > people and then still expect >them to drop everything to help you. You > seem to believe that hardware >is somehow simple and obvious and easy to > decipher. > >Well, I got news for you, Danial. That > isn't reality. The reality is >that sometimes the simplest bug.. a one line > error in code for example, >is the hardest to find. The reality is that > the 60 seconds you spend in >your armchair writing out yet another stupid > email is nothing compared >to the MAN-WEEKS it can sometimes take a > real programmer to track down >a bug. The reality is that third party > vendors in the general purpose >PC arena don't give a flying crap about open > source or open operating >systems and tend to be more interested in > covering their own asses then >in actually producing reliable hardware. > The reality is that hardware >is COMPLEX. Do you think an ethernet > chipset just pushes packets and >pulls packets in? That's just the tip of > the iceberg. That isn't >reality. > >If you want your problems solved, then you > have to get down and dirty and >help track them down on your own time. And > I'm not talking about spending >60 seconds writing yet another armchair > email. I'm talking about >dedicating real time to solving your > problems, just like *WE* do. > >And that is my last word on the subject. > > -Matt > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Vlad GALU <[EMAIL PROTECTED]> wrote: > On 6/3/06, Danial Thom <[EMAIL PROTECTED]> > wrote: > > > > > > --- Matthew Dillon > <[EMAIL PROTECTED]> > > wrote: > > > > > I couldn't have put it better myself. > > > > > > Vis-a-vie network performance, my goal > for > > > DragonFly is to have 'good' > > > performance. But I think it is a > complete > > > waste of time to try to > > > squeeze every last erg out of the > network > > > subsystem like FreeBSD has. > > > We aren't trying to compete with Cisco, > and > > > nobody in their right mind > > > would take a turnkey BSD or linux-based > > > system over a Cisco (or other > > > piece of high-end networking gear) to > route > > > multi-gigabits/sec of > > > traffic. I still think we can get > close > > > to FreeBSD's rated performance, > > > eventually, but I am not willing to > create > > > a mess of hacks and crazy > > > configuration options to turn DragonFly > > > into the ultimate ether switch > > > when I can purchase one off the shelf > for a > > > few hundred bucks. > > > > > > I think the last time I tried to use a > > > general purpose UNIX OS as an > > > actual 'router' was in 1994. We used > two > > > BSDi boxes (and later FreeBSD > > > boxes) to route the two T1's that BEST > > > Internet had when we had just > > > started up. It was a horror, frankly. > > > Hardware bugs in the ethernet > > > cards and even in the T1 card required > a > > > lot of hacking to work around, > > > and trying to run BGP with gated was > even > > > worse. > > > > > > Back then 'real' networking hardware > was > > > bulky and expensive. Today, > > > though, there is no excuse. It's cheap > > > (and even cheaper on E-Bay), > > > and far more reliable then a general > > > purpose PC. > > > > > > If someone is trying to route > > > multi-gigabits worth of traffic then > > > the infrastructure is clearly important > > > enough to warrent purchasing > > > dedicated networking gear. If someone > > > isn't trying to go all out, > > > then a general purpose OS might be > > > adequate, if still not as reliable. > > > > > > So all I can say to Mr Thom in that > regard > > > is: Stop trying to fit a > > > square peg into a round hole and just > buy > > > the appropriate gear for your > > > network infrastructure needs. > > > > > > > -Matt > > > > > > > > > > Your caveman-like views are as troubling as > they > > are entertaining. You seem to have no grasp > of > > the modern world and no understanding of > 'BSDs > > niche. Everything was buggy in '94, but with > you > > and clowns like Paul Borman trying to do > > networking, what the hell would you expect no > > matter what you had to work with? :))) > > > > Many, many large network appliances (load > > balancers, bandwidth managers, firewalls, > > security filters) are based on linux or BSD. > The > > reason is that CISCOs and "mega-gigabit > routers" > > have no extra CPU power to do things like > > filtering and shaping at a very high level. > I've > > made myself many millons of $$ selling a few > > thousand network devices, which is more than > > you'll ever make having a really cool desktop > OS, > > even if its better than anything else out > there. > > Designing a product for fun is one thing, but > if > > you want to get funding you have to produce > > something that's useful for the corporate > world, > > not for a bunch of pimply-faced college kids. > The > > reality of the corporate world is that even > if > > DFLY is the best damned OS ever written, they > > will use windows or linux, because you can't > > staff a support center with DFLY experts. Its > > simply never going to happen. You can however > get > > in as a server platform, because only a > couple of > > guys have to know what they're doing. > > > > Unix as a desktop box is not even an > > afterthought. 'B
RE: Any serious production servers yet?
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > I couldn't have put it better myself. > > Vis-a-vie network performance, my goal for > DragonFly is to have 'good' > performance. But I think it is a complete > waste of time to try to > squeeze every last erg out of the network > subsystem like FreeBSD has. > We aren't trying to compete with Cisco, and > nobody in their right mind > would take a turnkey BSD or linux-based > system over a Cisco (or other > piece of high-end networking gear) to route > multi-gigabits/sec of > traffic. I still think we can get close > to FreeBSD's rated performance, > eventually, but I am not willing to create > a mess of hacks and crazy > configuration options to turn DragonFly > into the ultimate ether switch > when I can purchase one off the shelf for a > few hundred bucks. > > I think the last time I tried to use a > general purpose UNIX OS as an > actual 'router' was in 1994. We used two > BSDi boxes (and later FreeBSD > boxes) to route the two T1's that BEST > Internet had when we had just > started up. It was a horror, frankly. > Hardware bugs in the ethernet > cards and even in the T1 card required a > lot of hacking to work around, > and trying to run BGP with gated was even > worse. > > Back then 'real' networking hardware was > bulky and expensive. Today, > though, there is no excuse. It's cheap > (and even cheaper on E-Bay), > and far more reliable then a general > purpose PC. > > If someone is trying to route > multi-gigabits worth of traffic then > the infrastructure is clearly important > enough to warrent purchasing > dedicated networking gear. If someone > isn't trying to go all out, > then a general purpose OS might be > adequate, if still not as reliable. > > So all I can say to Mr Thom in that regard > is: Stop trying to fit a > square peg into a round hole and just buy > the appropriate gear for your > network infrastructure needs. > > -Matt > > Your caveman-like views are as troubling as they are entertaining. You seem to have no grasp of the modern world and no understanding of 'BSDs niche. Everything was buggy in '94, but with you and clowns like Paul Borman trying to do networking, what the hell would you expect no matter what you had to work with? :))) Many, many large network appliances (load balancers, bandwidth managers, firewalls, security filters) are based on linux or BSD. The reason is that CISCOs and "mega-gigabit routers" have no extra CPU power to do things like filtering and shaping at a very high level. I've made myself many millons of $$ selling a few thousand network devices, which is more than you'll ever make having a really cool desktop OS, even if its better than anything else out there. Designing a product for fun is one thing, but if you want to get funding you have to produce something that's useful for the corporate world, not for a bunch of pimply-faced college kids. The reality of the corporate world is that even if DFLY is the best damned OS ever written, they will use windows or linux, because you can't staff a support center with DFLY experts. Its simply never going to happen. You can however get in as a server platform, because only a couple of guys have to know what they're doing. Unix as a desktop box is not even an afterthought. 'BSDs niche is as a network server. Period. You might think its a waste of time to optimize networking, but it seems to me you're wasting your time entirely if your goal is to be a little faster than LINUX as a desktop box. Who cares? FreeBSD with 1 processor is faster than linux with 2, but no-one used FreeBSD anyway. Nobody wants to use 'BSD as a desktop machine, except for a handful of people with a lot more time on their hands than the rest of us. People want to use 'BSD as network servers. People in the real world that is. Maybe thats why your not with FreeBSD anymore; your refusal to modernize your ideas to what's going on in the real world, and your complete lack of understanding where the dollars are to fund your efforts? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > > :Thats not really a solution as I don't want a > :system thats processing 100s of interrupts per > :second for no reason. I previously reported > that > :these were gone, but now that I put another > card > :in the box (a dual port intel ethernet), > they're > :back. > : > :I know I've been told that its a bios > :configuration problem, however I don't get > stray > :interrupts if I pop a FreeBSD disk on the > exact > :same hardware. So why is it a misconfiguration > in > :DFLY but not in FreeBSD? > : > :DT > > I like how you always twist things so it's > somehow our fault. > > The BIOS/MB issue is that some motherboards > route all system interrupts > to a single PIC IRQ line in order to allow > the BIOS to implement things > like USB keyboard support and NetBoot > during boot. The chipset > manufacturers do not publish how to turn it > off, and on some motherboards > there is no way to turn it off short of > turning off the PIC itself, > and even then it is sometimes not possible > to turn it off. > > It might be possible to bypass the issue > using the SMP + APIC_IO option, > but chipset vendors have also had the keen > idea of doing the same sort > of shit for IOAPIC interrupts too. Some of > Intel's own chipsets completely > break IOAPIC pin masking by causing the > chip to route to a default > vector if a pin is masked. Sometimes it is > possible to bypass > the problem by not using IOAPIC interrupt > masking (and sometimes it isn't), > and sometimes it is possible to bypass the > problem by masking the > pin representing the default vector. Or > not. > > FreeBSD has recently moved away from using > the PIC alltogether, primarily > by using the LAPIC timer instead of the > i2854. I think its a good idea, > but it represents quite a chunk of work. > It may or may not solve this > particular issue (it is just one of many > related to broken BIOSes and > motherboards that pop up). > > In anycase, if you want to solve the > problem the source code is right > there, start coding! You seem to want to > simplify problems down to > one-liner's, and blame us for all your woes > in the process, but the > reality is that it is a far more complex > issue then you seem to want to > believe. You can call it "twisting", but your OS is based on Freebsd 4.8, and it doesn't happen with FreeBSD 4.9. So unless its something that they fixed in 4.9, its likely something that you folks changed or do differently. In fact I've never seen so MANY stray interrupts on any box on any OS in the 23 years or so that I've been using one un*x or another. Not to be negative, but those are the facts. My view is that its the responsibility of the programmer to mask hardware quirks and bios "bugs". You don't "explain" that an ethernet controller has a bug so it locks up all the time; you figure out a way to make it so that it either doesn't lock up or so that it is restarts as tranparently as possible. Lazy programmers complain about how difficult it is to do things, and good ones come up with solutions. Its fairly clear that whatever the bug is, you've made it worse, or removed some work-around. As more and more people use DFLY, you'll spend more and more time explaining to people that its not your fault. Its probably less effort in the long run to just figure something out that corrects it. Turning on SMP stopped the stray irq messages. I get one stray IRQ message immediately after loading the acpi.ko module, and then no more. If you think of something that might fix it in UP mode, I'm happy to try it out. Is there a performance cost of running an smp kernel on a UP machine? I don't intend to run DFLY UP anyway, but just interested in knowing if it shuts off the SMP modes when only 1 cpu is detected. DT Its been suggested that I turn acpi off, and there doesn't seem to be a toggle in the bios, and dfly insists on loading the module __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Bill Hacker <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > > My tech tried firing up 1.4 on an opteron MB > with > > an HT1000 chipset and, although it seems to > work, > > the console is literally flooding with "stray > irq > > 7" messages. Freebsd at least suppressed > these > > after a few, but when is someone actually > going > > to FIX this in BSD? Someone told me years ago > > that this was an Intel chipset bug and there > was > > nothing that could be done, but clearly that > > isn't the case here. > > > > whats the workaround solution as the console > is > > unusable in its current state? > > > > DT > > Same as always: > > 1) ALT-F2 (3, 4, etc.) before logging in. > > 2) Edit /etc/syslog.conf to send soem/all > console messages elsewhere > - after which (1) is no longer necessary. > > Bill > Thats not really a solution as I don't want a system thats processing 100s of interrupts per second for no reason. I previously reported that these were gone, but now that I put another card in the box (a dual port intel ethernet), they're back. I know I've been told that its a bios configuration problem, however I don't get stray interrupts if I pop a FreeBSD disk on the exact same hardware. So why is it a misconfiguration in DFLY but not in FreeBSD? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: serialization (and other mumbo-jumbo)
--- walt <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > Just took a quick look at some ethernet > drivers > > in 1.5.3. Is there a write-up on how all this > > serialization stuff works?... > > Does this help any? (I don't pretend to > understand it...) > > http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00231.html > It does help to some extent, but I was hoping there might be a formal, organized write up, or at least an outline of the main subsytems. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Any serious production servers yet?
--- [EMAIL PROTECTED] wrote: > Danial Thom wrote: > > > > > > > That is the "Wall" for people who are on real > > networks. You could always count on the wall > > advancing as our buddies at AMD and Intel > > increased the GHZ. Now we're going sideways, > and > > many can't afford to have the wall regress to > > accommodate smoother audio performance. > > Danial > > this is the wall for *you* and only for you. Do > you want to know the truth > for me? I could not care less if you can route > gigabit links with BSD > and filter them with pf. If i was in the > situation to do that i would buy > dedicated hardware. But i care very much that > the software i am using runs > smoothly, and for that several processors give > a very considerable bonus. > With *my* present needs FreeBSD, DragonFly and > Linux give a > very good experience. There are certainly far > more machines running tomcat > or jboss servers with a lot of threads which > greatly and immediately benefit > from dual cores or more, than commodity > machines used to do the job of > dedicated hardware. > And yes, as Kris said, jemalloc works well at > present on FreeBSD. > Yeah, well the French don't care about much of anything now, do they? :) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
serialization (and other mumbo-jumbo)
Just took a quick look at some ethernet drivers in 1.5.3. Is there a write-up on how all this serialization stuff works? I can't find anything useful searching the lists. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Compiling: Whats the trick?
--- Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > On 02.06.2006, at 01:32, Danial Thom wrote: > > except it barfs pretty badly in DFLY. What's > the > > trick? > > just do it[tm]? works perfectly here. > besides, your error "report" > lacks major information, but I guess you know > that already. > > oh, of course except if you mean the return > value of ./hello_world. > that's a programming error then (no > return/exit()). I scaled the code to a minimum. It seems my disk was made by copying a disk and I guess some of the links didn't get set up right. The original disk works fine, even with the bad code. Thanks DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Any serious production servers yet?
--- James Mansion <[EMAIL PROTECTED]> wrote: > >A dual-core 2.6 Opteron is about US$1079. > whereas > >a single core is about $460. So for about > $200. > >more I can build 2 2.6Ghz systems that give me > a > >lot more bang for my buck than 1 dual-core > >system. > > Well, the bleeding edge is always at a premium. > But you mention a wall. A wall doing what? > Single threaded monte-carlo? Single postgres > query? > > Almost any real-world load that will stress > a modern server box comes from multiple > requests. > > As for pf performance - who the hell cares? > Are > you routing between two 10GBit LANs? Frankly I don't care about pf performance, but your comments indicate your ignorance as to how it performs under load. pf will barf on many real networks pushing a lot less than you think, depending on the complexity of the ruleset. > > If you're using that much CPU, then if you care > what OS you're using, your app is badly > written, > cos you should first avoid entering the kernel > anyway as much as you can. Ah, from the mouths of babes (or people who live in tiny caves)! If your network is pushing 300-500K pps its nice to have a firewall or security device or router that can handle it. And those filtering/network functions don't benefit much from MP. The "wall" is what such a box can handle with the fastest processor available. Typically MP doesn't scale well for such APPs, as the overhead associated with threading the kernel slows the raw performance more than is gained by having multiple processors. Getting past the wall would be good, but if the trade off is being able to do some other stuff with the box simultaneously, the capacity can't diminish too much, because once your traffic levels are past the wall you are in trouble. That is the "Wall" for people who are on real networks. You could always count on the wall advancing as our buddies at AMD and Intel increased the GHZ. Now we're going sideways, and many can't afford to have the wall regress to accommodate smoother audio performance. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Compiling: Whats the trick?
Ok, since the beginning of time, the following
has worked in every known unix:
/* hello_world.c */
#include "/usr/include/stdio.h"
main()
{
printf("hello world\n");
}
cc -o hello_world hello_world.c
except it barfs pretty badly in DFLY. What's the
trick?
DT
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Any serious production servers yet?
--- James Mansion <[EMAIL PROTECTED]> wrote: > >I guess I should have qualified my question. > If > >you're pushing less than 100Kb/s then there's > >really no reason to spend 3X the dollars on a > >multi-core system. So the only real value of > an > > >As of NOW, the price differential between a > >single core 2.6ghz Opteron and a dual-core one > is > >about 120%. I can't think of many applications > >that are going to push a 2.6Ghz opteron that > >justify spending more than twice as much. Of > > While I'd agree that in general CPUs today are > really pretty fast, I think this '3X' and > '120%' pitch suggests borked thinking, at least > for the case of whether to buy a dual core > socket 939 or 940 chip - because while the cost > differential is quite steep, its only the CPU > and > in effect you get a lot more bang for an > incremental change in system bucks - you don't > even need a pricey mobo. A dual-core 2.6 Opteron is about US$1079. whereas a single core is about $460. So for about $200. more I can build 2 2.6Ghz systems that give me a lot more bang for my buck than 1 dual-core system. Intel isn't quite in play yet, since a dual-core Pentium D doesn't give me the performance of a single 2.6Ghz Opteron, so there's no point in even considering it. Woodcrest/Conroe will change things, of course. Again, I'm talking about getting past the wall, so the lower end stuff doesn't buy me anything. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > On 01.06.2006, at 20:42, Danial Thom wrote: > > OK, it seems that enabling the printer got > rid of > > the messages. We usually disable the printer > port > > and remove the printer device and it seems > that > > DFLY doesn't like that too much. > > Now that you're talking about it: I also > experienced some of those > strange problems, and on my box i still get > stray ints (11 I think) > when switching virtual consoles or pressing any > *lock key (!?). > > It basically means: something fishy is > happening, DragonFly/FreeBSD > did notice that, continued working, but told > you. Maybe we can add a > sysctl which rate-limits those messages to a > reasonable amount? > > cheers >simon FreeBSD (4.9+ at least) quashes them after the first dozen or so. But I still don't get why ints are getting generated when no device on that irq has been enabled. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
OK, it seems that enabling the printer got rid of the messages. We usually disable the printer port and remove the printer device and it seems that DFLY doesn't like that too much. DT --- Danial Thom <[EMAIL PROTECTED]> wrote: > > > --- Matthew Dillon > <[EMAIL PROTECTED]> > wrote: > > > A flood of stray irq 7 messages is > > typically indicative of a BIOS > > SMP configuration problem. It usually > > means that the PIC is sending > > EXT interrupt acknowledgement requests to > > several cpus at once (or > > to one dual-core cpu), and the BIOS > hasn't > > setup the hardware to > > properly direct the interrupts to just > one > > cpu pin. > > > > What happens is that one cpu acks the > > interrupt and clears the pending > > bit, then the other cpu tries to ack the > no > > longer pending interrupt > > and gets the stray interrupt vector. The > > stray interrupt vector is > > typically an undocumented hardware vector > > number, usually 7 or 15. > > Hence stray irq 7's. > > > > If you are running dual-core cpu's you > can > > try adding this option to > > work around the BIOS misconfiguration: > > > > options CPU_AMD64X2_INTR_SPAM > > > > But it may not work on opterons. The > > problem is most commonly on > > systems with DUAL-CORE cpu's and BIOSes > > that don't quite configure > > them properly. > > This is a single core 100-series opteron. I > don't > have any dual-cores to test with at the moment. > > Its basically a GENERIC kernel (1.5.3-PREVIEW) > with smp disabled. > > DT > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > A flood of stray irq 7 messages is > typically indicative of a BIOS > SMP configuration problem. It usually > means that the PIC is sending > EXT interrupt acknowledgement requests to > several cpus at once (or > to one dual-core cpu), and the BIOS hasn't > setup the hardware to > properly direct the interrupts to just one > cpu pin. > > What happens is that one cpu acks the > interrupt and clears the pending > bit, then the other cpu tries to ack the no > longer pending interrupt > and gets the stray interrupt vector. The > stray interrupt vector is > typically an undocumented hardware vector > number, usually 7 or 15. > Hence stray irq 7's. > > If you are running dual-core cpu's you can > try adding this option to > work around the BIOS misconfiguration: > > options CPU_AMD64X2_INTR_SPAM > > But it may not work on opterons. The > problem is most commonly on > systems with DUAL-CORE cpu's and BIOSes > that don't quite configure > them properly. This is a single core 100-series opteron. I don't have any dual-cores to test with at the moment. Its basically a GENERIC kernel (1.5.3-PREVIEW) with smp disabled. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Erik Wikström <[EMAIL PROTECTED]> wrote: > On 2006-06-01 15:49, Danial Thom wrote: > > My tech tried firing up 1.4 on an opteron MB > with > > an HT1000 chipset and, although it seems to > work, > > the console is literally flooding with "stray > irq > > 7" messages. Freebsd at least suppressed > these > > after a few, but when is someone actually > going > > to FIX this in BSD? Someone told me years ago > > that this was an Intel chipset bug and there > was > > nothing that could be done, but clearly that > > isn't the case here. > > > > whats the workaround solution as the console > is > > unusable in its current state? > > Tried booting with ACPI disabled? > > Erik Wikström ACPI is disabled in the kernel. What causes this? Its been an issue since the beginning of time and only seems to occur in 'BSD. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Sascha Wildner <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > Surely it makes sense to begin developing O/S > > applications (which is what I need to do), > > however I need an OS that is production > ready, > > even if its not as good as its going to be, > > because I can't reasonably test the > performance > > of an application on an OS that can't handle > > production loads. > > *sigh* > > Is this going to be another of those > half-yearly "Danial vs. the rest" > threads? > > How about this: You restrain yourself from > stealing people's time with > your annoying discussion for discussion's sake > and I promise to get back > to you in personal email as soon as I think > that DragonFly has reached > the point where it could be interesting to you? > > Sascha I don't see that its me "vs" anything. I have to chose an MP OS for a big project and I just asked if the project is production-ready yet, and instead of getting an answer, I get a lot of pointers to personal web pages and routers that aren't even pushing a T1. A simple answer like "No, DFLY isn't ready for prime time yet, and we don't expect it will be until Sept '07". would have avoided wasting your time. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Argh, Stray interrupts 2006
My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with "stray irq 7" messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- "Kevin L. Kane" <[EMAIL PROTECTED]> wrote: > > So, 2-3 years tops, and there won't be > any more single-core offerings > > from AMD or Intel. Probably not even for > laptops. > > This is really already happening, ALL of > Apple's new latops are dual > core only and the only single core Intel based > mac is the cheapest > Mini. Apple is not really a great example, as they control the entire animal, and there's more margin in the high end. Here's a question for Matt, will dual-core designed chips (as opposed to chips with 2 independent cores on once chip) be used on an UP OS as a single core? Say if I wanted to use a dual-core chip on Freebsd 4.x in UP mode since SMP sucks wind? Or do the cores designed as dual-core with the shared caches require that both be used? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > Er. Well, if I were talking about today I > would be talking about today. > I'm talking about the near-future, 2-3 > years from now. It would be the > height of stupidity to have programming > goals that only satisfy the > needs of today. It might be the "height of stupidity", but it takes 2-3 years to convince people that you have something worth using, even if you have something great, so are you prepared to wait 4-5 to have a mainstream O/S? Once you get the groundwork done, you should ramp up to be production quality so you can get some noteworthy people using the O/S in real-world servers. Then you can keep it stable and work in your roadmap. We're approaching a critical point where a lot of companies are going to start looking to move into MP who haven't been there before. Saying you'll have something really great in 2 years isn't going to get people involved with the project. Your project will move ahead at an exponential pace once you get more funding and more important people working on it. You can't do that with an OS that can't be used by anyone with the money to contribute. You're thinking like an engineer, and not a marketeer. Its sort of like a kid going to college part-time trying to pay as he goes, earning $10/hr, while he could borrow the money and pay it off by making $50. an hour by graduating earlier. Its a backwards approach to product development. > > In 2-3 years single-core cpus will be > relegated to niche status. You > won't be able *BUY* Intel or AMD > single-core's at all for general purpose > computers. It won't matter a bit whether > the average consumer is able > use the extra computing power, it will be > there anyway because it doesn't > cost Intel or AMD any more to build it > verses building single-core cpu's, > it doesn't eat any more power either (in > fact, it eats less, for more > aggregate computing power). So regardless > of what you believe the > future is quite clearly going to become > permanently multi-core. > > In anycase, it's a mistake to assume that > the extra computing power > is wasted just because you can't think of > anything that can use it > right now. That mentality is what caused > Bill Gates to make the statement > that no computer would ever need more then > 640KB of memory. Nobody is saying that it can't be used, I'm just saying its not worth the $$$ today because the marginal cost of the hardware can't be utilized by the O/S and the applications that most use. So why buy MP today? Surely it makes sense to begin developing O/S applications (which is what I need to do), however I need an OS that is production ready, even if its not as good as its going to be, because I can't reasonably test the performance of an application on an OS that can't handle production loads. > > There are plenty of applications both > existing and on the horizon that > would be easily be able to use the > additional computing power. Even on a > fast machine today SSH can still only > encrypt at a 25-40MB/sec rate. > Filesystems such as ZFS are far more > computationally expensive then > what we use today, but what you get for > that price is an unbelievable > level of stability and redundancy. > Photo-processing? It takes my > fastest box 4 hours to run through the > fixups for one trip's worth of > photos. Since that workload is primarily > userland, it only takes > 2 hours on my dual-core box. Encryption, > Graphics, Photo-processing, > Database operations. Well I'm talking about servers here, because thats where the big $$$ are. With photoshop you're talking about saving some seconds here and there. Maybe productivity but most people do multiple things at once so its not really clear that being able to do something in 2 seconds instead of 5 matters. We're not talking floppy disks vs scsi raid here. The big picture issue is capacity. I don't really care if my server has 2ms or 4ms latency, I want it to be able to handle the load without barfing. At gigabit speeds filtering devices (like firewalls, soft routers, bandwidth management boxes) are pushing the envelope now. They can't relinquish capacity in order to have a smoother feel to the user interface. The capacity has to at LEAST be the same, or very close. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > Well, keep in mind, that in 2-3 years time > there won't *BE* any > single-cpu computers any more, at least not > for consumer offerings. > both Intel's and AMD's entire manufacturing > line is going to be > dual-core at a minimum, and higher-end > products will be at > least quad-core. > > Even as we speak Intel has begun repricing > its dual-core cpus to be > on par with their single-core cpus. AMD > has already dropped their > dual-core prices considerably, too. The > writing is on the wall. > As of NOW, the price differential between a single core 2.6ghz Opteron and a dual-core one is about 120%. I can't think of many applications that are going to push a 2.6Ghz opteron that justify spending more than twice as much. Of course that's all going to change in a few months when AMD loses their advantage. I don't see the point of using a dual-core 2.0 when I can get equal performance from a single 2.6 for less money. So the price drops so far are meaningless, given the OS's ability to utilize the cpus. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > Well, keep in mind, that in 2-3 years time > there won't *BE* any > single-cpu computers any more, at least not > for consumer offerings. > both Intel's and AMD's entire manufacturing > line is going to be > dual-core at a minimum, and higher-end > products will be at > least quad-core. > > Even as we speak Intel has begun repricing > its dual-core cpus to be > on par with their single-core cpus. AMD > has already dropped their > dual-core prices considerably, too. The > writing is on the wall. > > -Matt > I don't see that's a good reason to buy MP processors NOW, or to use an operating system that doesn't perform as well as a UP system NOW. I'm aware of the trends, which is why I keep asking about the progress. In the meantime what's the point of spending a lot of money for hardware that will be antiquated in 3 months, just to use an OS that can't (yet) fully utilize the available horsepower? Its all about bang for the buck. People that run big honking MP systems at 5% utilization are just wasting either their money or the money of their employers. The point of MP is to get past the wall of UP. When that's what the results are, then its time to start using it. Until then its just a lot of hype. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- "Justin C. Sherrill" <[EMAIL PROTECTED]> wrote: > On Tue, May 30, 2006 11:20 am, Danial Thom > wrote: > > > > I guess I should have qualified my question. > If > > you're pushing less than 100Kb/s then there's > > really no reason to spend 3X the dollars on a > > multi-core system. So the only real value of > an > > MP system is how it performs under heavy > load, if > > you're talking about a server and not a > desktop > > box. > > Is there a certain specific setup and threshold > you are looking for? > Like, performance of DragonFly with an MP > kernel on a multi-core processor > on a system acting as a firewall with traffic > at level X? (Guessing from > your writing above) > > At this point I'm looking for someone using it on *any* server running at levels that might justify using MP. The entire point of MP, on a server anyway, is to get better performance than you can on a UP server. So I guess the criteria is whether anyone is running a server that pushes the envelope of what a UP server can do, even if its just once and a while. Stability at 10% utilization and stability at 50-60% utilization are very different animals. Of course if you can tell me that its not really ready for a serious production environment then that's enough information right there, which was the general sentiment 6 months ago. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Any serious production servers yet?
--- Yiorgos Adamopoulos <[EMAIL PROTECTED]> wrote: > On 2006-05-29, Danial Thom > <[EMAIL PROTECTED]> wrote: > > Is anyone using DragonflyBSD in any serious > > production servers yet? Any feelings about > how > > it measures up in its current state > > performance-wise? > > We run firewalls on DragonFlyBSD with pf. We > are very pleased with the > performance and only had one small problem with > ftp-proxy which is resolved > as described here: > > http://www.dbnet.ece.ntua.gr/~adamo/howto/DragonFlyBSD/ftp-proxy.txt > > Apart from that we are very very happy! > -- > #include /* Yiorgos > Adamopoulos */ > And what kind of volume are you pushing through your firewalls peak, in terms of bandwidth and pps? I guess I should have qualified my question. If you're pushing less than 100Kb/s then there's really no reason to spend 3X the dollars on a multi-core system. So the only real value of an MP system is how it performs under heavy load, if you're talking about a server and not a desktop box. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Any serious production servers yet?
Is anyone using DragonflyBSD in any serious production servers yet? Any feelings about how it measures up in its current state performance-wise? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: NVIDIA driver
--- James Mansion <[EMAIL PROTECTED]> wrote: > > For further reference try > > playing a recent sony audio cd under windows. > > Soon you will only be > > able to play discs under windows > exclusively... > > What's wrong with that, precisely? So long as > there is no passing-off as a red-box compliant > product, then I can't see that Sony do not have > the right to do that. > > > people, stand in for your right, for your > freedom! > > When you say 'your freedom', you make it sound > like you have the freedom, and it is being > taken > away. I rather suspect that actually, for many > things, you never had the freedom that you may > think you did. > > In the UK, drivers are up in arms about new > speed > camera technology that WILL catch them when > they > exceed speed limits. They claim that this is > unfair and an impingement on their rights. > > I know I speed. > > But I also know that this will simply enforce > the > laws of the land, and I just got lazy about > assuming > that I'll get away with it. I'm not about to > lose > any freedom from the introduction of these > cameras. > I'll just have to be more rigorous about > obeying > the law. I can, after all, exercise my > democratic > right to try to get the law changed. www.phantomplate.com Its very popular here in the states. Its illegal but you can't see it with the naked eye, so how're they gonna catch you? :) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA driver
--- walt <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > > > --- Simon 'corecode' Schubert > > <[EMAIL PROTECTED]> wrote: > > > >> David wrote: > >>> So. What are those of us with Nvidia cards > to > >> do?... > > > I wonder if the open source weenies will ever > > figure it out? > > > They made a business decision that they have > more > > to lose by opening their interface to cloners > > then they have to gain by releasing source > and > > interface specs. Its not really that > complicated. > > That seems a realistic assessment to me. > > However: what happens when hardware > manufactures > like Nvidia are no longer subsidized by > monopolists > like MicroSoft? (No, not this year, or even > next > year ;o) > > Operating systems *will* become commodities in > the > fairly near future, just like memory chips, > disk > drives, and even CPU's. No they won't, because operating systems are not even close to being generic performers, and each has a focus that appeals to different market segments. dt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA driver
--- Emiel Kollof <[EMAIL PROTECTED]> wrote: > Op donderdag 16 februari 2006 01:42, schreef > Danial Thom: > > I know you are trolling again, but I'll bite > this time. Don't bother replying > to this as I don't have the desire to make this > another friggin' Thread From > Hell(tm). > > > I wonder if the open source weenies will ever > > figure it out? > > Figure what out? I think we have it figured out > better than you will ever do. you make such a strong case here its hard to even consider an answer. > > > They made a business decision that they have > more > > to lose by opening their interface to cloners > > then they have to gain by releasing source > and > > interface specs. Its not really that > complicated. > > It would be nice (and ideal), but they don't > have to. In nVidia's case, they > can have a lump of binary code (an object file) > that they can keep closed and > provide a glue that can be hacked to hell and > back (which is the case with > the kernel part of the nVidia driver). Would be > nice if this is the case with > the userland bits as well. I know it can be > done. I know for a fact that > Matrox used to ship a closed up binary lump > that would work in multiple > operating systems to enable the use of their > HAL feature in their cards in > X11/Xorg. And supporting this kind of implementation is worth the effort financially? Or are they just obligated to appease the handful of dudes on this project? > > What nVidia does is (IMHO) a dumb buisness > decision. It might work for them, > but they alienate people while they don't > really have to. Most "winners" alienate a lot of people. That's why democrats keep losing. They try to appease the masses and then they end up having nothing worthy to offer. What's "stupid" is trying to appeal to people who think that video board (or chipset) vendors are obligated to make their products available to every OS in creation simply because of the nature of the product they sell. They sell a product and they have drivers for the major OSes. They're as entitled to make that decision as you are to not support POLLING in the kernel. Companies are in business to maximize profits for their investors; not to make everyone in the entire world think that they're nice fellows. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA driver
--- Steve O'Hara-Smith <[EMAIL PROTECTED]> wrote: > On Wed, 15 Feb 2006 20:31:35 -0800 (PST) > Danial Thom <[EMAIL PROTECTED]> wrote: > > > You don't have a G-d given right to use other > > people's work without paying a fee for it. > > No but having paid for it I expect to be able > to use it without > unreasonable restrictions. I also expect to be > able to make backups so > that I don't have to pay for it again when the > media wears out. Again, another arrogant and ignorant stance. Somehow paying $99. for thousands of hours worth of work entitles you to manipulate the code in any way you want until the end of time? You're not "buying" the code. You don't own it. You're just "paying" for a license to use the code, at a significantly discounted price. Its expected, as part of the cheap price, that you'll need to buy another copy when Microsoft gets around to releasing another OS or you need to upgrade your hardware. Most companies survive on residuals more than they do finding new customers. Trying to keep this in the context of proprietary hardware drivers, there's a business case to be made to release your specs and let other people write drivers (in which case you're risking someone writing a bad driver (can you say template programmer Bill Paul?)) and blaming your hardware for problems, or you can invest corporate man hours and dollars in writing a really good driver and developing hardware that is a unique performer and guarantee that you are a leader in a particular market without having to worry that the Acme corp of Taiwan will make some piece of crap chip that has the same interface as yours and take away your market share. This happened to Western Digital back in the 80s when they had the best ethernet card on the planet and the taiwanese stole their concept and their designs and much of their market share with clone boards. Now they sell hard drives and not much else. NVIDA selected the second approach, and I'm sure that they are very glad they did; and I doubt that they care that the 24 guys running DFLY BSD have to use something else. If you want vendors to support your OS, then make your OS significant. Otherwise you're stuck with companies with mediocre products who are desparate to find someone to use them. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA driver
--- Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > On 16.02.2006, at 01:42, Danial Thom wrote: > >>> So. What are those of us with Nvidia cards > to > >> do? Install a different > >>> video card? > >> > >> - use text console or > >> - use xorg with vesa or nv driver > >> > >> - don't use 3d accellerated stuff > >> > >> - reverse engineer the hardware, or better > yet, > >> - get hardware companies to open their specs > > I wonder if the open source weenies will ever > > figure it out? > > > > They made a business decision that they have > more > > to lose by opening their interface to cloners > > then they have to gain by releasing source > and > > interface specs. Its not really that > complicated. > > I wonder how long it will take you to figure > out that this isn't our [= > society's] problem. I never asked for the > raisins they have, I know > them. I don't care why they don't open it. I > care *that* they don't. > This is a problem of our society. As soon as > all hardware is closed, > all software needs to be closed as well, > leading to an all-closed IT > infrastructure. This document? You may not > open [bad propaganda in > there, after all]. This email? You may not > encrypt [well of course, > but we will still be reading it]. This song? > You may not record from > the radio/your friends playing the guitar > [after all it's copyrighted > and you didn't pay the fee for it]. You don't have a G-d given right to use other people's work without paying a fee for it. You're not smart enough (apparently) to realize that the only reason that you have so many choices of incredibly inexpensive hardware to run your free software on is because of all of the money that microsoft has spent and EARNED to create markets that make it feasible for so many vendors to thrive in. You're like the typical liberal moron who complains about all the money the gov't spends on war while you bask in the freedom that the wars have made possible. Get a clue. You don't understand business or markets or anything that is important. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA driver
--- Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > David wrote: > > So. What are those of us with Nvidia cards to > do? Install a different > > video card? > > - use text console or > - use xorg with vesa or nv driver > > - don't use 3d accellerated stuff > > - reverse engineer the hardware, or better yet, > - get hardware companies to open their specs > I wonder if the open source weenies will ever figure it out? They made a business decision that they have more to lose by opening their interface to cloners then they have to gain by releasing source and interface specs. Its not really that complicated. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Wireless network cards
--- Bryan Berch <[EMAIL PROTECTED]> wrote: > I want to get a wireless network set-up in my > house using my gateway > box. Can any one give me a good choice in a > wireless network card for > my desktop box or is there a better way to do > it? > > If the network card route is fine, can there be > an antenna located in a > central location in the house using a cable > from the network card and to > the antenna? > > I'm new to wireless and any suggestions > appreciated. > > Bryan Get a linksys or d-link wireless router for $49. and enjoy whatever hair you have remaining. Just plug your DFLY box into a port and your wireless stuff will work out of the box. Note if they have a mail-in rebate offer don't expect to get anything back without a lot of complaining. How would one go about proposing a world-wide boycott of products with mail-in rebates? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: more dragonfly photos
--- Bob Bagwill <[EMAIL PROTECTED]> wrote: > Just in case you haven't seen this site: > > http://stephenville.tamu.edu/~fmitchel/dragonfly/index.html > -- > Bob > Its clear that Linux' substantial marketing lead over 'BSD is their choice of a cute, cuddly mascot in favor of the devilish/spiked fish/nasty bugs that BSDs insist on using. How about a smiling sheep or a puppy? At least we might get more chicks at the conventions... DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Hello from a new user and problems detecting rtl8139 PCI card
--- "Erik P. Skaalerud" <[EMAIL PROTECTED]> wrote: > Jose timofonic wrote: > > I know my PCI ethernet sucks, but I don't > have money > > for a good one ATM, but if not other > solution, I will > > buy one when having enough money for it. > Please say me > > a great PCI one (3COM?). > > Any new 3com or Intel-card should work > flawlessly. > Has DFLY fixed the 3com driver issue in which it puts the system into livelock as you approach bus saturation? You need to turn off the stats updates if not. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Would DF welcome a phpbb forum?
--- "Justin C. Sherrill" <[EMAIL PROTECTED]> wrote: > On Tue, January 17, 2006 5:03 am, Steve > O'Hara-Smith wrote: > > > NNTP is just a > > transport protocol for it > > How was the material in USENET slung around > before there was NNTP? > > > If a web forum is so vital (in some > minds[1]) for being > > trendy it's not hard to write a web based > threaded news reader with PHP > > or mod_perl or similar - there might even be > one available off the shelf > > :) > > This would seem to me to be a more useful > thing for the OP to do than > > setting up a disconnected forum which if > succesful may just cause people > > to need to track *both*. > > http://www.gmane.org/ is one example. Hmm... > > Mail forums are nice for immediate issues, but > there also needs to be a > resource for people that aren't continually > reading the mail. (plug) This > is why I have the DragonFly BSD Log ( > http://www.shiningsilence.com/dbsdlog ) and why > there's a searchable mail > archive ( > http://leaf.dragonflybsd.org/mailarchive ). > > If we didn't have the mailing lists, a bulletin > board system would be > handy - however, with the current size of the > user base, there isn't > enough "overflow". I haven't seen a lot of BB > traffic at bsdforums.org or > gobsd.org, for instance. If we could combine > the mail content and BB > interface, that's be great, since I think it's > the interface in which the > original poster is interested. Why not create a google list? Everyone can access it, you don't have to join to post a comment or questions, and you don't have to maintain a mailbox or use any resources. It also would greatly increase the readership and exposure of the OS in general. Its how things are done in the 21st century. Mailing lists and newsreaders almost seem archaic at this point. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Debugging device drivers
--- Brian Reichert <[EMAIL PROTECTED]> wrote: > On Wed, Jan 11, 2006 at 10:19:45PM +0100, > Francis GUDIN wrote: > > Hum... not exactly: my host is a 2xPPro > (200MHz). Rebuilding a kernel is > > about 1/4 hour. Rebooting globally lasts a > few minutes. Joy, joy, joy... > > Oh ! Also: i'd like to avoid launching X > everytime, firefox (s**t) and > > all over again. This *is* painful. This is > why i asked... > > VMware? Qemu? Bochs? > Uh, you don't have to rebuild the entire kernel source every time, sillyboy. Only the module you change will have to be recompiled. Its easy enough to stop x from launching. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Debugging device drivers
--- Francis Gudin <[EMAIL PROTECTED]> wrote: > Hi all, > > i'm trying to understand why my SB16 soundcard > isn't recognized by > DragonFly, though working alright under FBSD > 5.4: i already had a > long-standing problem with ips(4) and as i've > got no other controller to > boot from, i had to go through a painful cycle > (put printf everywhere, > rebuild on another host, scp & install the new > kernel, reboot, try > to understand anything at all...). > > As a sound card isn't that critical to the boot > process, i'd like to > know if an easier way of debugging exists: > would it be possible to > build a kernel without any sound support, > instrument and somewhat > hack bits of snd_sbc and friends and then use > kldload/kldunload to > investigate ? I mean: will the probe routines > get called as they would > during normal kernel initialization ? > > Thanks for any tips, > Francis. Trace code is your friend. Compiling a kernel is so fast these days, just compile and reboot. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: learning c programming
--- Terry Tree <[EMAIL PROTECTED]> wrote: > Anyone used these tapes before > http://www.mixsoftware.com/product/cvidfn.htm ? > I'm wondering if they are worth $299. What do > you guys think ? > > -- > Terry > > IMO there is only one way to learn to program; get yourself a project. You'll need a reference book or web site, but until you try to tackle something fairly difficult you'll never be any good. During your project you'll encounter things that you don't know how to do, and you'll research and experiment and you'll learn how to do it. To me, programming is like woodworking. You can read all the books and watch all the films in the world on how to sand, stain, topcoat and polish, and then you'll try to do it and you'll just have a big mess. The only way to learn is to try to build something, and keep at it until you've figured it out. Danial __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
Re: DP performance
--- Erik Wikström <[EMAIL PROTECTED]> wrote: > On 2005-12-11 15:47, Danial Thom wrote: > > you are completely wrong on every point. A > > computer is only deterministic if its running > one > > task. And if he doesn't understand the math > of > > the bus, then all of his conclusions will be > > faulty. and I promise you his math is wrong. > > A computer is always deterministic, but you are > correct in the sence > that when the complexity of the workload > increases and the interaction > with other entities the complexity makes it > very hard to correctly > perform a simulation. In these cases we can > instead procees with > statistical models. > > As to the question of the correctness of Matt's > claims it's still just > your word against his and I have yet to see any > facts backing up your > claims. > ah, but statistical models are only dead-on accurate when you have a completely accurate understanding of everything that can occur, which is almost never. Which is why the only valuable test is an empirical one. haha. My point is that "his word" has no backing because its just theory, and because his fundamentals are wrong. He refuses to grasp the fact that the PCI bus is a burst bus, and that you can't determine the transfer rate or cpu requirement with the A+B=C math that he uses. The number of bursts it takes (and thus # of setups and I/O operations) will vary with traffic levels. As the levels increase, the bursts become shorter, because bus contention increases. So you can't say that the math for transfering 1 packet is the same for 750K packets/second, because its just plain wrong to do so. What do you think "my word" is? My only point was that I use the usage level at which a machine starts dropping packets to determine its point of capacity. I don't see how I can be wrong about anything, since its hard to argue against that point. And what do you think Matt's point was? I don't even think its relevant. > PS. > What's up with your mail-client? Wrapping lines > at 50 characters is very > conservative, I'm quite convinced that there's > no (or sufficiently few) > computers/terminals that can not handle at > least 64 characters per line. > You also seem to have a problem when replying > to the list, the > References-field is not set. Its yahoo :-) Its more of a web page than a mail reader. Welcome to the 21st century. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
Why won't you answer any questions or provide details of your ideas? I keep asking, but you never actually say anything. --- "Martin P. Hellwig" <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > > Are you related to Edgar Allan Poe by some > > chance? > > > > I'm not sure I know which "topic" you're > > referring to, since all you do is make vague > > references to things that don't seem related > to > > anything. First you cited switch specs > without an > > example or what part of the spec made your > point, > > and then you made some vague reference to a > large > > organization that's in bed with Cisco, > without > > mentioning any specific test or what point > the > > test proves. I understand that the last time > you > > said something you were badly beaten down, so > > maybe you're just afraid to say anything as > it > > may tarnish your reputation as someone who > knows > > something? > > > You pretty fallen for it, by using the same > discussion technique as you > did, you reacted the same way you expects other > to react, normally when > that situation is created it is still needed to > poke a bit more before > the opposite party reveals enough information > to identify for sure, > however in your case two post where enough. > So without further reservation I may without > any doubt welcome back > "EM1897", this time with a valid AOL e-mail > account. > > -- > mph > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
--- "Martin P. Hellwig" <[EMAIL PROTECTED]> wrote: > Danial Thom wrote: > > --- "Martin P. Hellwig" <[EMAIL PROTECTED]> > > wrote: > > > > > >> > >> Okay so when your the expert on practical > >> implementation, what do you > >> make of the surfnet internet2 test results > >> (they did actually test > >> current "normal" hardware too) that prove > your > >> "practical" hypothesis > >> wrong? Or do you just deny the results and > >> continue on trolling? > >> > > > > What test are you referring to, and what do > you > > think it disproves? > > > > > Dear Danial, > > Your lack of knowledge on this topic is not a > valid excuse of being > irrational stubborn. Are you related to Edgar Allan Poe by some chance? I'm not sure I know which "topic" you're referring to, since all you do is make vague references to things that don't seem related to anything. First you cited switch specs without an example or what part of the spec made your point, and then you made some vague reference to a large organization that's in bed with Cisco, without mentioning any specific test or what point the test proves. I understand that the last time you said something you were badly beaten down, so maybe you're just afraid to say anything as it may tarnish your reputation as someone who knows something? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
--- "Martin P. Hellwig" <[EMAIL PROTECTED]> wrote: > > Okay so when your the expert on practical > implementation, what do you > make of the surfnet internet2 test results > (they did actually test > current "normal" hardware too) that prove your > "practical" hypothesis > wrong? Or do you just deny the results and > continue on trolling? What test are you referring to, and what do you think it disproves? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
--- "Martin P. Hellwig" <[EMAIL PROTECTED]> wrote: > > > What do you think the > > switch is going to do with the traffic? Its > going > > to dump it. > > The only argument you gave is false, read the > full specs of any modern > switch (ie all 1Gb switches) > > -- > mph If I relied on "specs" for my info I'd be in the same boat you guys are in, so I don't. Specs are a nice "upper limit" but you can hardly come to any conclusions based on specs alone. Why don't you post a snippet from one of your "specs" to illustrate how long you can flow control a switch before it starts dumping packets. And remember that a spec is the max a box can do, so thats with only 2 ports and large packets. So then you can interpolate out (assuming you want to use math to solve your problems) to much smaller packets and many more ports contending for bus bandwidth. Like I said, its time to get out of college-mode and get yourself a test bed. Its the only way to learn how things really work, rather than how they're supposed to work. The truth is that switches under load don't like to be flow controlled, and they drop packets when their queues are at relatively low watermarks. Christ, some switches drop packets at 300K pps when they're not flow controlled. Besides, flow control isn't part of the argument. "Performance" isn't about how gracefully you can fail to perform a task; its about being able to perform the task without having to resort to using flow control. To me, a box that is issuing flow control is no better than one that drops packets. Both have failed to do the job required. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
--- Erik Wikström <[EMAIL PROTECTED]> wrote: > On 2005-12-02 19:16, Danial Thom wrote: > > All of the empirical evidence points to Matt > > being wrong. If you still can't accept that > then > > DFLY is more of a religion than a project, > which > > is damn shame. > > > > DT > > Since I don't know anything about networking at > GigE-speed I find this > whole diskussion very interesting and I hope to > learn something new. > However, as always when two people both believe > they are right, it's > hard for me to really choos whom to trust. > > However Matt has provided some arguments that I > find very convincing > (calculations and reasoning). Now, since you > say that all empirical > evidence suggest that he is wrong I suppose > that you have some other > numbers (wouldn't be very empirical otherwise > would it?) that you could > show me (like benchmarking or such). Then I > might decide what to think > when I've seen both sides arguments. Matt admits that he's "not sure" how the PCI bus works, so why do you find his "calculations" convincing? He can't possibly do calculations if he doesn't understand the impact of the bus on the operations in question. Try profiling a kernel thats doing nothing but bridging packets. His arguement that hardly any CPU is used is foolish and wrong. There are millions of operations required to move a packet from one interface to another. You can't explain that in A+B=C math. You have to do real testing. Why do you think that flow-controlling a gigabit switch is an "ok" solution? What do you think the switch is going to do with the traffic? Its going to dump it. So you've moved the dropped packets from one box to another; the result is still packet loss. You've solved nothing. None of his answers address the original question, which is when will MP be as fast or close to as fast as UP. His answer is that networking takes no CPU cycles. Its the dumbest thing I've ever heard. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
Perhaps I have a stake in one of the "beta quality OSes" (FreeBSD 5.x+, Dragonfly, etc) actually becoming useful? Its very frustrating to see a strong solid OS with a strong management team fragment into a bunch of mini-teams, none of which have a wide-enough range of expertise to be ultimately successful. You obvioulsy have no-one on your "Team" than is strong in networking, because you don't even have the ability to understand the issues (apparently), much less come up with viable solutions. If the performance of Makeworld is your criteria, and you have no large network exposure (since you are in denial of packet loss and think that flow controlling a loaded gigE switch is a "solution"), I don't see how there is any chance for success beyond a being a "neat desktop OS". I'm feeling a bit like Charlton Heston in "The Planet of the Apes" here. Long Live Matt! Long Live Matt! --- Hiten Pandya <[EMAIL PROTECTED]> wrote: > Dude, if you have made and are making millions > of benjamins, I don't > a person in his right mind would be spending > his time arguing Gig-E > performance speeds on a mailing list for a > beta-quality OS. :-) > > If I was a person that made millions, I would > definitely be planning > on buying an AMG convertible and thinking of > buying some Cuban cigars. > > So please, lay off the shit of how much you > make and talk some sense > here. No, we don't think Matt is all singing > all dancing and knowing, > BUT, he does talk sense most of the times. > > Anyway, this feels like troll targeting a lot. > If you really think > Matt is right, or people who agree with his > viewpoints, then do > provide some numbers and we will take it from > there. > > Kind Regards, > > -- > Hiten Pandya > hmp at dragonflybsd.org > > Danial Thom wrote: > > I, on the other hand, have made millions of > $$ > > designing and selling network equipment based > on > > unix-like OSes, so I'm not only qualified to > > lecture on the subject, but I'm also > qualified to > > tell Matt that he's dead wrong about just > about > > everything he's said in this thread. If you > think > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DP performance
--- Hiten Pandya <[EMAIL PROTECTED]> wrote: > You obviously did not research on who Matthew > Dillon is, otherwise you > would know that he has plenty of real world > experience. The guy wrote > a packet rate controller inspired by basic laws > of physics, give him > credit instead of being rude. > > Time will tell whether he was wrong about his > arguments on PCI-X or not, > and whether our effort with DragonFly is just > plain useless; but there > is absolutely no need for animosity on the > lists. > > Should you wish to continue debating > performance issues then do so with > a civil manner. > > Kind regards, > > -- > Hiten Pandya > hmp at dragonflybsd.org > > Danial Thom wrote: > > You obviously have forgotten the original > premise > > of this (which is how do we get past the > "wall" > > of UP networking performance), and you also > > obviously have no practical experience with > > heavily utilized network devices, because you > > seem to have no grasp on the real issues. > > > > Being smart is not about knowing everything; > its > > about recognizing when you don't and making > an > > effort to learn. I seem to remember you > saying > > that there was no performance advantage to > PCI-X > > as well not so long ago. Its really quite > amazing > > to me that you can continue to stick to > arguments > > that are so easily provable to be wrong. > Perhaps > > someday you'll trade in your slide rule and > get > > yourself a good test bed. College is over. > Time > > to enter reality, where the results are > almost > > never whole numbers. > > > I know Matt very well, and he knows a lot about a lot of things. I generally have respect for his analysis. But he doesn't know everything, and he's particularly weak in networking. Judging by his comments on this thread, I'd say that he's a lot weaker than I expected. He admittedly doesn't even understand how PCI bursting works or how flow control works, and he's in complete denial about packet loss issues, so how can he lecture anyone on anything related to network processing? I, on the other hand, have made millions of $$ designing and selling network equipment based on unix-like OSes, so I'm not only qualified to lecture on the subject, but I'm also qualified to tell Matt that he's dead wrong about just about everything he's said in this thread. If you think that convincing 1000s of people to spend $1000s. on systems running a Free OS is not because of results (as opposed to conjecture), then you haven't tried to do it. Results trump theory every time. Research will show that DragonFLYBSD exists because Matt's peers in the FreeBSD camp disagreed with his ideas, so its not like he's Jesus Christ as you guys portray him. He created DFLY so he could again be the one-eyed man in the land of the blind. Lots of brilliant economists are wrong much of the time. Does dragonfly still use 10K as the default interrupt moderation for the em device? Wow, that means that just about everyone running Dragonfly with em devices is getting 1 interrupt per packet, since I doubt many of you are pushing more than 10K pps. What brilliance came up with RAISING the default of 8K to 10K? Faulty analysis by Matt is the answer. Google a thread with the subject "serious networking (em) performance (ggate and NFS) problem", and you'll see he's maintained the same, stupid position about packet loss a full year ago. He hasn't learned a friggin thing in a year, because he thinks he's already got the answer. That, my friend, is the definition of a fool. If you think that ANYONE is an auhority on every subject you are a fool. But here is Matt, who again and again admits that hes not "sure" about things like flow control and how the bus works, yet you follow his theories without question. Its absolutely mindless. All of the empirical evidence points to Matt being wrong. If you still can't accept that then DFLY is more of a religion than a project, which is damn shame. DT __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > Well, if you think they're so provably > wrong you are welcome to > put forth an actual technical argument to > disprove them, rather then > throw out derogatory comments which contain > no data value whatsoever. > I've done my best to explain the technical > issues to you, but frankly > you have not answered with a single > technical argument or explanation > of your own. If you are expecting > acolades, you are aren't going to > get them from any of us. The only accolades I need are in the form of $$. I'm hoping to find a suitable OS for the next generation of product, so that's my only goal. Fire X number of packets at a system bridging packets and the machine will go into livelock before it starts flow controlling, and as you increase the PPS volume you'll see buckets of packets dropped. The value of 'X' is different on every machine of course, and somewhat linear on the same machine with different CPUs. You can tune it until the cows come home, but there's nothing elegant about it. If you do in fact enter a flow controlled state, buckets of packets are lost in the process, by both the sending and receiving machines. Flow control merely shifts the losses; its not a solution, its a symptom that maans your machine isn't fast enough to handle the required load. You realize of course that by the time you have a ring breach and flow control is issued and you can catch up you've lost 1000s of packets at gigE speeds, right? Its hard to disprove something that is mindless, such as your claim that modern processors cannot be overrun. Its so patently ridiculous that its like proving that sand is squishy. It takes *some* amount of CPU to process a packet. Certainly over the years that amount has become less and less. But I really don't get your point, or how it related to making MP faster then UP. Are you saying that since processors are fast enough to handle huge network loads that there is no reason to make the OS better? So if you're not running 10gigE then there's no reason to use multiple processors? DT __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > :... > :wall a lot sooner with MP than with UP, > because > :you have to get back to the ring, no matter > what > :the intervals are, before they wrap. As you > :increase the intervals (and thus decrease the > :ints/second) you'll lose even more packets, > :because there is less space in the ring when > the > :interrupt is generated and less time for the > cpu > :to get to it. > : > :Flow control isn't like XON/OFF where we say > "hey > :our buffer is almost full so lets send some > flow > :control" at 9600 baud. By the time you're flow > :controlling you've already lost enough packets > to > :piss off your customer base. Plus flow > :controlling a big switch will just result in > the > :switch dropping the packets instead of you, so > :what have you really gained? > : > :Packet loss is real, no matter how much you > deny > :it. If you don't believe it, then you need a > :better traffic generator. > : > :DT > > Now you need to think carefully about what > you are actually arguing > about over here. You are making > generalizations that are an > incorrect interpretation of what features > such as interrupt moderation > and flow control are intended to provide. > > What I have said, several times now, is > that a reasonably modern cpu > is NO LONGER the bottleneck for routing > packets. In otherwords, there > is going to be *plenty* of cpu suds > available. The problem isn't cpu > suds, its the latency after new data > becomes available before the cpu > is able to clear the RX ring. > > But, and this is where you are > misinterpreting the features, the problem > is that there is ANY latency, it is simply > that there is too MUCH latency > *SOMETIMES*. The whole point of having a > receive ring and flow control > is to INCREASE the amount of latency that > can be tolerated before packets > are lost. > > This in turn gives the operating system a > far better ability to manage > its processing latencies. All the > operating system has to guarentee > to avoid losing packets is that latency > does not exceed a certain > calculated value, NOT That the latency has > to be minimized. There is > a big difference between those two > concepts. > > Lets take an example. Including required > on-the-wire PAD I think the > minimum packet size is around 64-128 bytes. > I'd have to look up the > standard to know for sure (but its 64 bytes > worth on 100BaseT, and > probably something similar for GigE). So > lets just say its 64 bytes. > That is approximately 576 to 650 bits on > the wire. Lets say 576 bits. > Now lets say you have a 256 entry receive > ring and your interrupt > moderation is set so you get around 12 > packets per interrupt. So your > effective receive ring is 256 - 12 or 244 > entries for 576 bits per > entry if minimally sized packets are being > routed. That's around 140,000 > bits, or 140 uS. > > So in such a configuration routing > minimally sized packets the > operating system must respond to an > interrupt within 140 uS to avoid > flow control being activated. > > If we take a more likely scenario... > packets with an average size of, > say, 256 bytes (remember that a TCP/IP > header is 40 bytes just in itself), > you wind up with around 550,000 bits to > fill the receive ring or > a required interrupt latency of no more > then 550 uS. > > 550 uS is a very long time. Even 140 uS is > quite a long time (keep in > mind that most system calls takes less then > 5 uS to execute, and many > takes less then 1). Most interrupt service > routines take only a few > microseconds to execute. Even clearing 200 > entries out of a receive > ring would not take more then 10-15 uS. So > 140 uS is likely to be > achievable WITHOUT having to resort to real > time scheduling or other > methods. > > If you have a bunch of interfaces all > having to clear nearly whole > rings (200+ entries) then it can start to > get a little iffy, but even > there it would take quite a few interfaces > to saturate even a single > cpu, let alone multiple cpus in an MP > setup. > > The key thing to remember here is that the > goal here NOT to minimize > interrupt latency, but instead to simply > guarentee that interrupt > processing latency does not exceed the ring > calculation. That's the > ONLY thing we care about. > > While it is true in one sense that > minimizing interrupt latency gives > you a bit more margin, the problem with > that sort of reasoning is that > the cost of minimizing interrupt latency is > often to be far less > cpu-efficient, which means you actually > wind up being able to handle > FEWER network interfaces instead of the > greater number of network > interfaces you thought you'd be able to > handle. > >
Re: DP performance
--- Marko Zec <[EMAIL PROTECTED]> wrote: > On Thursday 01 December 2005 22:19, Danial Thom > wrote: > > I see you haven't done much empirical > testing; > > the assumption that "all is well because > intel > > has it all figured out" is not a sound one. > > Interrupt moderation is given but at some > point > > you hit a wall, and my point is that you hit > a > > wall a lot sooner with MP than with UP, > because > > you have to get back to the ring, no matter > what > > the intervals are, before they wrap. As you > > increase the intervals (and thus decrease the > > ints/second) you'll lose even more packets, > > because there is less space in the ring when > the > > interrupt is generated and less time for the > cpu > > to get to it. > > Gig-E line rate is around 1.44 Mpps max. If > you set up the interrupt > coalescing timers to trigger interrupts with > max frequency of 15000 > int/s (a pretty standard setting), then the > maximum number of packets > buffered due to interrupt delaying will never > exceed 100. Given that > even the cheapest NICs have 256 RX slots or > more, it is evident that > the issue you are raising is non-existent. no box in existence can handle 1.44Mpps, so why are you arguing a case that can't possibly be made? > > > Flow control isn't like XON/OFF where we say > "hey > > our buffer is almost full so lets send some > flow > > control" at 9600 baud. By the time you're > flow > > controlling you've already lost enough > packets to > > piss off your customer base. > > No, flow control really works, if tresholds are > set up properly then > there's no reason for it to fail, i.e. loose > packets at all. Intel boxes don't send out flow control unless the bus has been saturated (ie doing gigE on a 32bit bus) or until the ring has been breached. In both cases its too late as you've lost 100s of packets. Flow control is not an issue here anyway; its a stupid point. The goal is to be able to handle the traffic without flow control. Its like saying that it doesn't matter how fast memory is because programs will wait. Its just plain stupid. > > > Plus flow > > controlling a big switch will just result in > the > > switch dropping the packets instead of you, > so > > what have you really gained? > > So what's your point? If a system cannot cope > with the incoming > traffic, _somewhere_ a certain amount of > packets will have to be > dropped. The real issue is how to make a > system more efficiently > handle the offered traffic, not to cry about > lost packets. The "point" is that if you are receiving some # of packets, it means that the device before you can handle it and you can't. It means that you are the bottleneck, and you don't belong in the path. It means that your device is unsuitable to be used as a networking device on such a network. Thats all it means. DT __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > :The issue is that RX is absolute, as you > cannot > :"decide" to delay or selectively drop since > you > :don't know whats coming. Better to have some > :latency than dropped packets. But if you don't > :dedicate to RX, then you have an unknown > amount > :of cpu resources doing "other stuff". The > :capacity issues always first manifest > themselves > :as rx overruns, and they always happen a lot > :sooner on MP machines than UP machines. The > LINUX > :camp made the mistake of not making RX > important > :enough, and now their 2.6 kernels drop packets > :all over the ranch. But audio is nice and > :smooth... > : > :How to do it or why its difficult is a > designer's > :issue. I've not yet been convinced that MP is > :something thats suitable for a network > intensive > :environment as I've never seen an MP OS that > has > :come close to Freebsd 4.x UP performance. > : > :DT > > RX interrupts can be hardware moderated > just like TX interrupts. > The EM device, for example, allows you to > set the minimum > delay between RX intrrupts. > > For example, lets say a packet comes in and > EM interrupts immediately, > resulting in a single packet processed on > that interrupt. Once the > interrupt has occured EM will not generate > another interrupt for N > microseconds, no matter how many packets > come in, where N is programmable. > Of course N is programmed to a value that > will not result in the RX > ring overflowing. The result is that > further RX interrupts may bundle > 10-50 receive packets on each interrupt > depending on the packet size. > > This aggregation feature of (nearly all) > GiGE ethernet devices reduces > the effective overhead of interrupt entry > and exit to near zero, which > means that the device doesn't need to be > polled even under the most > adverse circumstances. > > I don't know what the issue you bring up > with the Linux kernels is, > but at GigE speeds the ethernet hardware is > actually flow-controlled. > There should not be any packet loss even if > the cpu cannot keep up with > a full-bandwidth packet stream. There is > certainly no need to fast-path > the network interrupt, it simply needs to > be processed in a reasonable > period of time. A few milliseconds of > latency occuring every once in a > while would not have any adverse effect. I see you haven't done much empirical testing; the assumption that "all is well because intel has it all figured out" is not a sound one. Interrupt moderation is given but at some point you hit a wall, and my point is that you hit a wall a lot sooner with MP than with UP, because you have to get back to the ring, no matter what the intervals are, before they wrap. As you increase the intervals (and thus decrease the ints/second) you'll lose even more packets, because there is less space in the ring when the interrupt is generated and less time for the cpu to get to it. Flow control isn't like XON/OFF where we say "hey our buffer is almost full so lets send some flow control" at 9600 baud. By the time you're flow controlling you've already lost enough packets to piss off your customer base. Plus flow controlling a big switch will just result in the switch dropping the packets instead of you, so what have you really gained? Packet loss is real, no matter how much you deny it. If you don't believe it, then you need a better traffic generator. DT __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Re: DP performance
--- Marko Zec <[EMAIL PROTECTED]> wrote: > On Wednesday 30 November 2005 16:18, Danial > Thom wrote: > > --- Hiten Pandya <[EMAIL PROTECTED]> wrote: > > > Marko Zec wrote: > > > > Should we be really that pessimistic > about > > > > potential MP performance, > > > > even with two NICs only? Typically > packet > > > > flows are bi-directional, > > > > and if we could have one CPU/core taking > care > > > > of one direction, then > > > > there should be at least some room for > > > > parallelism, especially once the > > > > parallelized routing tables see the > light. > > > > Of course provided that > > > > each NIC is handled by a separate core, > and > > > > that IPC doesn't become the > > > > actual bottleneck. > > > > > > On a similar note, it is important that we > add > > > the *hardware* support > > > for binding a set of CPUs to particular > > > interrupt lines. I believe that > > > the API support for CPU-affinitized > interrupt > > > threads is already there > > > so only the hard work is left of converting > the > > > APIC code from physical > > > to logical access mode. > > > > > > I am not sure how the AMD64 platform > handles > > > CPU affinity, by that I > > > mean if the same infrastructure put in > place > > > for i386 would work or not > > > with a few modifications here and there. > The > > > recent untangling of the > > > interrupt code should make it simpler for > > > others to dig into adding > > > interrupt affinity support. > > > > This, by itself, it not enough, albeit > useful. > > What you need to do is separate transmit and > > receive (which use the same interrupts, of > > course). The only way to increase capacity > for a > > single stream with MP is to separate tx and > rx. > > Unless doing fancy oubound queuing, which > typically doesn't make much > sense at 1Gbit/s speeds and above, I'd bet that > significantly more CPU > cycles are spent in the "RX" part than in the > "TX", which basically > only has to enqueue a packet into the devices' > DMA ring, and recycle > already transmitted mbufs. The other issue > with having separate CPUs > handling RX and TX parts of the same interface > would be the locking > mess -> you would end up with the > per-data-structure locking model of > FreeBSD 5.0 and later, which DragonFly diverted > from. > > Cheers, > > Marko The issue is that RX is absolute, as you cannot "decide" to delay or selectively drop since you don't know whats coming. Better to have some latency than dropped packets. But if you don't dedicate to RX, then you have an unknown amount of cpu resources doing "other stuff". The capacity issues always first manifest themselves as rx overruns, and they always happen a lot sooner on MP machines than UP machines. The LINUX camp made the mistake of not making RX important enough, and now their 2.6 kernels drop packets all over the ranch. But audio is nice and smooth... How to do it or why its difficult is a designer's issue. I've not yet been convinced that MP is something thats suitable for a network intensive environment as I've never seen an MP OS that has come close to Freebsd 4.x UP performance. DT __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: DP performance
--- Hiten Pandya <[EMAIL PROTECTED]> wrote: > Marko Zec wrote: > > Should we be really that pessimistic about > potential MP performance, > > even with two NICs only? Typically packet > flows are bi-directional, > > and if we could have one CPU/core taking care > of one direction, then > > there should be at least some room for > parallelism, especially once the > > parallelized routing tables see the light. > Of course provided that > > each NIC is handled by a separate core, and > that IPC doesn't become the > > actual bottleneck. > > On a similar note, it is important that we add > the *hardware* support > for binding a set of CPUs to particular > interrupt lines. I believe that > the API support for CPU-affinitized interrupt > threads is already there > so only the hard work is left of converting the > APIC code from physical > to logical access mode. > > I am not sure how the AMD64 platform handles > CPU affinity, by that I > mean if the same infrastructure put in place > for i386 would work or not > with a few modifications here and there. The > recent untangling of the > interrupt code should make it simpler for > others to dig into adding > interrupt affinity support. This, by itself, it not enough, albeit useful. What you need to do is separate transmit and receive (which use the same interrupts, of course). The only way to increase capacity for a single stream with MP is to separate tx and rx. You'll still have higher latency than UP, but you may be able to increase capacity by dedicating cycles to processing the receive ring. If you can eliminate overruns then you can selectively manage transmit. DT __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > > :Should we be really that pessimistic about > potential MP performance, > :even with two NICs only? Typically packet > flows are bi-directional, > :and if we could have one CPU/core taking care > of one direction, then > :there should be at least some room for > parallelism, especially once the > :parallelized routing tables see the light. Of > course provided that > :each NIC is handled by a separate core, and > that IPC doesn't become the > :actual bottleneck. > > The problem is that if you only have two > interfaces, every incoming > packet being routed has to go through both > interfaces, which means > that there will be significant memory > contention between the two cpus > no matter what you do. This won't degrade > the 2xCPUs by 50%... it's > probably more like 20%, but if you only > have two ethernet interfaces > and the purpose of the box is to route > packets, there isn't much of a > reason to make it an SMP box. cpu's these > days are far, far faster then > two measily GigE ethernet interface that > can only do 200 MBytes/sec each. > > Even more to the point, if you have two > interfaces you still only have > 200 MBytes/sec worth of packets to contend > with, even though each incoming > packet is being shoved out the other > interface (for 400 MBytes/sec of > total network traffic). It is still only > *one* packet that the cpu is > routing. Even cheap modern cpus can shove > around several GBytes/sec > without DMA so 200 MBytes/sec is really > nothing to them. MBs/sec is not the relevant measure; its pps. Its the iterations that are the limiting factor, particularly if you are acting on the packet. The simplistic analysis of packet in / packet out is one thing; but the expectation is that *some* operation is being carried out for each packet, whether its a firewall check or something even more intensive. Its pretty rare these days to have a box that just moves bytes from one interface to another without some value-added task. Otherwise you just get a switch and you're not using a unix-like box. > > :> Main memory bandwidth used to be an > issue but isn't so much any > :> more. > : > :The memory bandwidth isn't but latency _is_ > now the major performance > :bottleneck, IMO. DRAM access latencies are > now in 50 ns range and will > :not noticeably decrease in the forseeable > future. Consider the amount > :of independent memory accesses that need to be > performed on per-packet > :... > :Cheers > : > :Marko > > No, this is irrelevant. All modern > ethernet devices (for the last decade > or more) have DMA engines and fairly > significant FIFOs, which means that > nearly all memory accesses are going to be > burst accesses capable of > getting fairly close to the maximum burst > bandwidth of the memory. I > can't say for sure that this is actually > happening without a putting > a logic analyzer on the memory bus, but I'm > fairly sure it is. I seem > to recall that the PCI (PCIx, PCIe, etc) > bus DMA protocols are all burst > capable protocols. Typically only 64 bytes are "burst" at a time max (if there are no other requests), so you're not always bursting the entire frame. As the bus becomes more saturated, you have shorter and shorter bursts. With 2 devices you're "realizable" bus bandwidth is about 2/3 for monodirectional traffic and 1/2 for bi directional. This puts PCI-X (~8Mb/s) just on the edge of being fully capable of full-duplex gigE. DT __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: DP performance
--- Steve Shorter <[EMAIL PROTECTED]> wrote: > On Mon, Nov 28, 2005 at 10:15:55AM -0800, > Matthew Dillon wrote: > > :What kind of "benefits" would be realized > for > > :systems being used primary as a > router/bridge, > > :given that its almost 100% kernel usage? > > : > > :DT > > > > Routing packets doesn't take much cpu > unless you are running a gigabit > > of actual bandwidth (or more). If you > aren't doing anything else with > > the machine then the cheapest AMD XP will > do the job. > > > > We've found the bottle neck for routers is CPU > cycles neccessary to > process NIC hardware interrupts. At least for > OBSD. Interupt mitigation, and > I suppose POLLING on Dragonfly may help but it > isn't supported on all > hardware AFAIK. Polling is pretty dumb with modern NICs, as most have built-in interrupt moderation that does the work of polling without all of the overhead (by generating interrupts with user-definable forced separation). At least Intels do; if others don't then thats enough reason not to use them. Doing 500K pps with a 10K interrupts/second setting is better than you could ever do with polling, and the results quite good. Dealing with the NICs (processing packets, I/Os, etc) is what uses the cycles, and the stack (a bridge machine can do twice as many packets as a "router" for example). For network processing true separation of transmit and receive is probably the only way to realize networking gains for non TCP/UDP operations. Slicing up the stack will only slow things down compared to UP (think of a full-speed relay race against a guy that doesn't get tired...the guy without the hand-offs will always win.) The best you can probably do is match the UP performance; but idealy have a bunch of cpu power left over. So maybe you'd have a UP machine that can do 800K pps and be on the edge of livelock, and a DP machine that can do 750K pps but is still usable at the user level. Danial __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > :What kind of "benefits" would be realized for > :systems being used primary as a router/bridge, > :given that its almost 100% kernel usage? > : > :DT > > Routing packets doesn't take much cpu > unless you are running a gigabit > of actual bandwidth (or more). If you > aren't doing anything else with > the machine then the cheapest AMD XP will > do the job. Then let's pretend that we are routing "lots" of packets, ok? Obviously the goal of a DP machine is to break the performance ceiling of a single processor machine, otherwise why would anyone spend the extra cash? __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
Re: DP performance
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > > :It seems most of the banter for the past few > :months is userland related. What is the state > of > :the kernel in terms of DP/MP kernel > performance? > :Has any work been done or is DFLY still in the > :cleaning up stages? I'm still desparately > seeking > :a good reason to move to Dual-core processors > : > :DT > > It's getting better but there is still a > lot of work to do. After > this upcoming release (middle of December) > I intend to bring in Jeff's > parallel routing code and make the TCP and > UDP protocol threads MP safe. > > Even in its current state (and, in fact, > even using the old FreeBSD 4.x > kernel's), you will reap major benefits on > a dual-core cpu. I have > been very impressed with AMD's Athlon X2 in > these Shuttle XPC boxes, > despite having to buy a PCI GiGE ethernet > card due to motherboard > issues. What kind of "benefits" would be realized for systems being used primary as a router/bridge, given that its almost 100% kernel usage? DT __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
DP performance
It seems most of the banter for the past few months is userland related. What is the state of the kernel in terms of DP/MP kernel performance? Has any work been done or is DFLY still in the cleaning up stages? I'm still desparately seeking a good reason to move to Dual-core processors DT __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: RELEASE officially updated to 1.2.6.
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > The 1.2 release has been officially bumped > to 1.2.6. > > -Matt > great. Is there any info on it since April 2005? __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Interesting ubench scores for FreeBSD 4.11, 5.4, 6.0beta3 and DFly-Preview
--- Kris Kennaway <[EMAIL PROTECTED]> wrote: > On 2005-09-03, Toma¾ Bor¹tnar > <[EMAIL PROTECTED]> wrote: > > Kris Kennaway wrote: > >>>Summary > >>>Latest DFly-preview has best Ubench AVG of > 106030, because of 2nd best memory score > (124353) and balanced CPU score > >>>(87707). Also good was FreeBSD 6beta3/amd64 > with Ubench AVG of 101448, because of > balanced CPU (102455) and memory > >>>score (100441). Seems like extra registers > in long mode help quite a bit. Third was > FreeBSD 5.4/i386 with Ubench AVG of > >>>94304 - mostly because of best memory > score (130602) and not so good CPU score > (58006). Hardly behind was FreeBSD 4.11 > >>>with Ubench AVG of 94296 - decent, but > slower CPU score (84431) and very nice memory > score (104161). FreeBSD 6beta3/i386 > >>>was severly behind all of them with Ubench > AVG of 55968 - with cpu of 59138 and memory of > 52799. > >>> > >>>I wish DFly had better CPU score :) But it > still has best score among 32bit OS systems! > >>> > >>>As usual, YMMV :) > >> > >> > >> Did you remember to disable the debugging > features in FreeBSD 6 > >> (WITNESS, INVARIANTS, malloc debugging)? If > not, you're incurring a > >> significant (usually >30%) performance > penalty, which is consistent > >> with your numbers. > > > > I checked FreeBSD 6beta3/i386 again - i > forgot to reboot with new > > kernel which I did this time. The only > visible change is much better > > memory score - 98040 this time(!), while CPU > was 59062. Almost 100% > > more from 52799 with GENERIC debug kernel! > But average score is > > still low compared to others - 78551. > > I did some tests on a UP pentium 3 machine, and > confirmed that most of > the difference between FreeBSD 4.x and later > versions is due to the > different compiler being used to compile the > code (gcc 2.95 vs 3.4). > gcc 3.x is known to have wildly different > performance characteristics > than 2.x (better on some code, worse on other). > When I retested 5.x > and above with a FreeBSD 4.x binary (statically > linked), I found > somewhat different results. > > I ran at least 10 tests on each platform and > then used the ministat > tool (/usr/src/tools/ministat on freebsd) to > perform a statistical > comparison. > > When using the same binary, the CPU scores are > statistically > indistinguishable between the different FreeBSD > versions. This makes > sense since there's little kernel involvment in > running userland > integer/FP computations. When running the gcc > 2.95 binary all > versions of FreeBSD were 31% *faster* on this > test than when running a > gcc 3 binary (both compiled with -O only). > > FreeBSD 5.x and above show a 6.3% drop on the > memory test relative to > 4.x (with the same 4.x binary). I reran ubench > with kernel profiling > enabled and found that this drop is mostly due > to the vm locking > present in FreeBSD 5 and above (via vm_fault). > This locking is also > responsible for the dramatic performance > increases on SMP machines > seen in other benchmarks, so it would be more > interesting to test on > SMP machines. I'm not set up to do this on my > hardware though. > > The memory test showed about a 14.6% benefit > from using the gcc 3 > binary vs gcc 2.95. This is presumably due to > better code generation > in e.g. memset/memcpy. > > In summary: the CPU test is a priori not very > useful for comparing > performance of different OSes, because it is > largely a test of the > code generated by the compiler (unless you can > eliminate this > variable). The lesson is that if your > application includes a lot of > CPU intensive code, you should carefully > benchmark its performance > with different compilers and optimizations to > see what works best. > Thus, the 'average' number is also not > meaningful as a point of > comparison since it is tainted by this fact. > > The memory test is a bit more meaningful since > it contains a kernel > component, but it's still influenced quite a > lot by the compiler, so > it's also hard to compare directly unless you > can eliminate that > variable. > > Kris While I agree with your conclusion generally, I think your logic is wrong here. Since the compiler version used to build an OS is a fundamental propery of the OS, I can't see how you can discount it as a factor in an OS being fast or slow. Its not practical to use something else. Using different optimizations is another matter; as that's a practical alternative for the average user. The problem with ubench is that its utterly useless in testing an OS, because it doesn't exercise the kernel, which is what makes or breaks the OS. It is also likely that it runs entirely in the CPU cache, which makes it even less than useless. And aren't memcpy and memset written in assembler? DT Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Interesting ubench scores for FreeBSD 4.11, 5.4, 6.0beta3 and DFly-Preview
--- Toma¾ Bor¹tnar <[EMAIL PROTECTED]> wrote: > I took some time to play with a machine and > test ubench scores on it for few OS. Machine is > AMD64/939 3000+ with 2GB RAM > (dual-channel). > > I took ubench, because it does not deal with > systems other than CPU and memory which usually > says something about > efficiency of OS. I tried to optimize things by > alwyas using flag "-O" and removing all debug > stuff from kernels. Since > this was all done on the same machine I think > we can kinda compare those results. I used > FreeBSD 4.11, FreeBSD 5.4/i386, > FreeBSD 6beta3/i386 and FreeBSD 6beta3/amd64 > in this test. > > Summary > Latest DFly-preview has best Ubench AVG of > 106030, because of 2nd best memory score > (124353) and balanced CPU score > (87707). Also good was FreeBSD 6beta3/amd64 > with Ubench AVG of 101448, because of > balanced CPU (102455) and memory > score (100441). Seems like extra registers in > long mode help quite a bit. Third was FreeBSD > 5.4/i386 with Ubench AVG of > 94304 - mostly because of best memory score > (130602) and not so good CPU score (58006). > Hardly behind was FreeBSD 4.11 > with Ubench AVG of 94296 - decent, but slower > CPU score (84431) and very nice memory score > (104161). FreeBSD 6beta3/i386 > was severly behind all of them with Ubench AVG > of 55968 - with cpu of 59138 and memory of > 52799. > > I wish DFly had better CPU score :) But it > still has best score among 32bit OS systems! > > As usual, YMMV :) > > Toma¾ > > > > - > > ubench > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Thu Sep > 1 21:01:43 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FAST > amd64 > Ubench CPU: 102455 > Ubench MEM: 100441 > > Ubench AVG: 101448 > > > > > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > DragonFly Preview-Preview DragonFly > Preview-Preview #0: F i386 > Ubench CPU:87707 > Ubench MEM: 124353 > > Ubench AVG: 106030 > > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 4.11-RELEASE FreeBSD 4.11-RELEASE #0: > Fri Se i386 > Ubench CPU:84431 > Ubench MEM: 104161 > > Ubench AVG:94296 > > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Fri > Sep 2 21:59:25 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > Ubench CPU:58006 > Ubench MEM: 130602 > > Ubench AVG:94304 > garac64-fbsd5# ubench > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Fri > Sep 2 21:59:25 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > Ubench CPU:58095 > Ubench MEM: 131309 > > Ubench AVG:94702 > > 192# ubench > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Fri Sep > 2 23:26:47 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > Ubench CPU:59138 > Ubench MEM:52799 > > Ubench AVG:55968 > 192# ubench > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk <[EMAIL PROTECTED]> > http://www.phystech.com/download/ubench.html > FreeBSD 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Fri Sep > 2 23:26:47 CEST 2005 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > Ubench CPU:59067 > Ubench MEM:52659 > > Ubench AVG:55863 > Interesting. Thats just about the opposite of what I've seen with empirical networking tests. Another example of the uselessness of benchmarks, since there is virtually no application that only uses what's tested with ubench. Danial __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ifconfig(8) syntax intuitiveness
--- Joerg Sonnenberger <[EMAIL PROTECTED]> wrote: > On Wed, Aug 24, 2005 at 03:26:17PM +0200, Erik > P. Skaalerud wrote: > > Joseph Garcia wrote: > > >I was using ifconfig when it occurred to me > how non-intuitive it is > > >having to use 255.255.255.255 as the netmask > when adding an address > > >that is on the same subnet as an address > already on the interface. For > > >example, if you already have 192.168.0.1/24 > on fxp0, then you should be > > >able to add the following address with this > command: > > > > > > ifconfig fxp0 add 192.168.0.2 netmask > 255.255.255.0 > > > > > >instead of: > > > > > > ifconfig fxp0 add 192.168.0.2 netmask > 255.255.255.255 > > > > > > > I second this. I had problems with this when > I first used IP aliasing on > > FreeBSD long time ago because I had the wrong > netmask set. (/24 instead > > of /32). > > It's not that easy. This has nothing to do with > the interface, but is a > restriction from the routing stack. Once that > restriction goes away, > there's no reason why aliases wouldn't allow it > too. > > > I second your thoughts about "delete". You > don't delete it, you remove it. > > You delete the route. > > > I have another suggestion for ifconfig > aswell. Show netmaskes in human > > readable format (decimal) instead of HEX. I > mean, who really thinks > > about netmasks in HEX formats? > > Me. Actually, decimal netmasks are *not* human > readable, because it is > much harder to determine the *binary* affect > they have. > > Joerg My opinion is, if you want to add another syntax, fine, but leave the old syntax also, because even though it may not seem intuitive, its familiar. The same reasoning goes for not changing "grep" to "search". Linux changed a lot of the ifconfig syntax and its confusing to new users who are familiar with something else, and it doesn't improve the experience. Better to have one arguably wrong syntax that 4 different ones that are marginally more correct. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DragonFly BSD marketing
--- Bob Bagwill <[EMAIL PROTECTED]> wrote: > On Tue, 16 Aug 2005 17:10:44 -0400, Chris > Pressey > <[EMAIL PROTECTED]> wrote: > > I agree strongly with your underlying theme, > although I'd characterize > > it slightly differently. It's not just about > marketing, which sounds > > sort of frivolous and underhanded... it's > actually about governance. > > Governance sort of implies that there are > agreed-upon principles that a > cohesive community shares. I think marketing > is a better fit for the > chaotic > open source bazaar. ;-) In a way, DragonFly is > trying to sell itself, > firstly, as > a neat project to work on, and secondly, as a > robust-yet-innovative > platform > for computing. I don't think DragonFly needs > to market itself in the > sense of > selling DragonFly-logo mousepads and tee-shirts > (although they'd probably > sell :-) ), > I think it needs to make clear why you would > want to a) choose to work on > it, and b) > choose to run it, over the alternatives. There is a theory in marketing that if you "build a better mousetrap, people will come". But the real trick is convincing people that your mousetrap is better. What I'd like to see is some sort of quantifiable metering of progress. Is anyone doing performance testing as changes are made? If so, it would be good to make the results available. If not, how do you know that your changes are positive? You can't just do a big project and then hope when you're done it performs better than when you started. Since the entire point of the project is to clean up FreeBSD to better support threads, multiprocessing, etc, its seems reasonable to expect some sort of performance plan, and some sort of map showing the gains or progress that have been made. "Marketing" is the process of convincing people that you have something that they want, in whatever form you present it. Outlining a lot of technical jargon that the average person can't understand without quantifiable results is only going to draw super-geeks that blindly agree with your ideas, which is at best a tiny slice of the universe. If you want to wait until you have a shiny, speedy vehicle to display at some super trade show that's one angle, but you'll have to do it all with very little support which may take a very, very long time. Danial Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
