Re: hyper threading.
If you think that then you are either a fool or an old fool.. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 06:43:59 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: And the circumstances that you have described have nothing to do with modern computing, so as I said, its irrelevant. The circumstances have not changed in modern computing. That's one reason why 30-year-old operating systems like UNIX remain popular. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Thats because you seem unable to grasp modern concepts. If you think that performance criteria of modern controllers and processors are the same as 30 years ago, then you are incapable of commenting on anything modern. Every controller/processor is different and has its own advantages and inefficiencies. The fact that you can make ignorant statements like I proved polling is faster because 20 years ago I wrote a driver, then you think that you know things that you don't. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 21:02:40 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: If you think that then you are either a fool or an old fool.. I've never encountered a situation in which experience was a disadvantage. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
You are wrong about just about everything, I unsubscribed because dragonfybsd is more than a year away from being usable in a commercial environment and memory fails when you shock it with a heavy load. And I'm pretty sure my email exists. My goal is to seek intelligent life. Its a long journey. -Original Message- From: Guillermo Garcia-Rojas [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 14:03:15 -0600 Subject: Re: hyper threading. Stop feeding this troll, he has been banned from de DragonFly BSD list for his stupid comments, his e-mail address doesn't even exist. His only goal is make the longest thread of messages in history. Stop him! On Tue, 29 Mar 2005 14:54:30 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thats because you seem unable to grasp modern concepts. If you think that performance criteria of modern controllers and processors are the same as 30 years ago, then you are incapable of commenting on anything modern. Every controller/processor is different and has its own advantages and inefficiencies. The fact that you can make ignorant statements like I proved polling is faster because 20 years ago I wrote a driver, then you think that you know things that you don't. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 21:02:40 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: If you think that then you are either a fool or an old fool.. I've never encountered a situation in which experience was a disadvantage. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- --- Guillermo García Rojas Covarrubias Director General SoloBSD http://www.solobsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
No, I think the biggest changes are that 1) Processor speed is rarely the key limiting factor and 2) Memory efficiency is much less a concern. In the old days if you weren't a very good programmer you did something else. Today anyone can crank out code that works (linux anyone?). And processors are so fast that most people don't notice, as is evidenced by this thread. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 22:20:31 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Thats because you seem unable to grasp modern concepts. None were under discussion. If you think that performance criteria of modern controllers and processors are the same as 30 years ago, then you are incapable of commenting on anything modern. The principles of modern controllers are surprisingly similar to those of old controllers. The biggest change is that the PC world is only now discovering what mainframe designers knew 40 years ago. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anthony's drive issues.Re: ssh password delay
More supurb technical analysis from that wiz, Jerry. Nicely done! You know if you guys spent half the time debugging code as you spend cutting down people who've found stuff that doesn't work there might not be a reason to complain. Too bad all of the real developers are off scratching their heads as to why the damn slab allocator is so dreadfully slow. -Original Message- From: Jerry McAllister [EMAIL PROTECTED] To: Dick Hoogendijk [EMAIL PROTECTED] Cc: freebsd-questions freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 17:50:42 -0500 (EST) Subject: Re: Anthony's drive issues.Re: ssh password delay On 29 Mar Bart Silverstrim wrote: You should go out and reinstall Windows on that server and leave this list in peace. He won't do that. I told this weeks ago. He comes off on this shit he writes. You won't win this game. Why? 'Cause all of you use arguments and Anthony simply is /not/ He talks sh*t, knows it and will keep on talking sh*t. No matter what you do or say. Let's leave him. Won't do any harm if left alone. For the record everything has been said. So, why not silence him. Let him be happy. Leave him alone. Mostly true.But, in the more recent posts he seems to be doing less name calling and paying a small amount more attention to technical information.So, who knows - some people just take a long time to grow up. Generally the adult community just puts up with infants during those years like the terrible two-s believing against all current evidence they will grow out of it. So, maybe that will happen here in this case too. Anyway, I have found the letter 'd' to be a quite convenient way to manage the situation. Deleting almost all of the posts in those threads and only looking in to one every couple of days makes it a lot easier to handle. jerry -- dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 4.11 ++ FreeBSD 5.3 + Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
I guess that depends on how you define performance. The MAX_INTS setting in the em driver essentially does what polling does (in reducing interrupts) without the overhead. So there is really no way that polling could be better. With polling you have a lot of unnecessary overhead. Setting MAX_INTS properly has zero overhead for the O/S -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Mon, 28 Mar 2005 06:03:00 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Polling is simply unecessary in most cases. You could get better performance using an em driver and setting max ints to whatever is optimal for your system. Polling adds latency and over head for no good reason. Polling often provides better performance, at the expense of higher overhead. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Things have changed a bit since then, so I doubt that proof has any relevance. All polling does , in the context of device polling, is make networking low-priority. You are adding latency to save CPU cycles. You could argue that higher latency is lower performance. Interrupt hold offs are a much better way to reduce interrupts without poisoning your system with extra overhead. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Mon, 28 Mar 2005 16:49:20 +0200 Subject: Re: hyper threading. Boris Spirialitious writes: If you understood what I said, then you wouldn't say what you said, because its just plain wrong. I've written code that proves it right. Someone once told me that a 80286 couldn't handle ordinary terminal communications at speeds of 38400 bps. I proved that it could, but the comm program I wrote to do so used polling rather than interrupts to accomplish it. It was impossible to handle such high speeds with interrupt-driven I/O. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Do you know how MAX_INTS and Device Polling work? I can tell that you don't so why are you blabbering about how you kludged an ancient operating system to work-around poorly designed hardware? First of all, with original 8250 PC serial ports, polling wouldn't have worked because there was no buffering. So there were no chunks to deal with. Which is why someone probably told you it was impossible. If your MB had a later design, such as a 16550, then you could poll and gain some efficiency. HOWEVER, modern controllers have much buffering, and the ability to moderate interrrupts. With polling you have a minimum constant overhead, even with no traffic. Using interrupt moderation, you get the best of both worlds, because the contollers will only interrupt at a pre-set safe interval, and there is no additional overhead. And when there is no traffic there are no interrupts. So if you have good hardware, polling has negative effects on performance. It ads overhead for no additional benefit. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Mon, 28 Mar 2005 20:14:52 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Things have changed a bit since then, so I doubt that proof has any relevance. The principles haven't changed at all. Servicing interrupts is an extremely high-overhead activity. There's a minimum amount of time it takes, no matter how short the interrupt routine. There comes a point when just the inherent cost of the context switch is responsible for most of the overall cost of the interrupt service, and with a large number of interrupts, the processor(s) can spend a great deal of time just switching contexts. Polling eliminates this overhead by simply checking for I/O to service when it is convenient for the OS. As long as polls occur frequently enough not to miss any pending I/O, it's faster than interrupt-driven I/O. The total number of instructions executed is often greater, because the OS tends to spin on its polling tasks, but the absolute time required to respond to a given I/O event can be much shorter. In my case, I divided all the work of the comm program into small bits that could be done in tiny chunks. Each time a chunk was completed, I polled the serial port. Since chunks never exceeded a certain size, I always managed to poll the port in less time than it took to receive a character, even at 38,400 bps. The system was busier than it would be with interrupts driving it, but it responded more quickly to incoming traffic, and there were no transfer timeouts, whereas with interrupts, the system was less busy, but it timed out very consistently at high communications rates. By using more processor but evening out the use of processor so that it was more consistently distributed, very high communication rates could be handled by the program. All of this remains permanently applicable today, and it is why some high-speed applications poll instead of waiting for interrupts. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
And the circumstances that you have described have nothing to do with modern computing, so as I said, its irrelevant. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Tue, 29 Mar 2005 00:03:07 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Do you know how MAX_INTS and Device Polling work? I know how device polling works. MAX_INTS is the sort of identifier that probably occurs in seven trillion lines of code in the world, so I have no idea what it means. I can tell that you don't so why are you blabbering about how you kludged an ancient operating system to work-around poorly designed hardware? I didn't say anything about an operating system. First of all, with original 8250 PC serial ports, polling wouldn't have worked because there was no buffering. No buffering was necessary. Even the oldest devices held the most recent character latched in the register, and that's what I picked up. It wasn't necessary to buffer the characters, as I picked them up as soon as they came in ... even at 38,400 bps. So there were no chunks to deal with. The chunks I had in mind had nothing to do with the incoming serial data. They were outstanding tasks divided into small blobs that could be handled between two polls of the serial port. Most of them involved things like writing data to the display, scrolling or clearing the display, and emptying and processing the keyboard buffer, not to mention transmitting outgoing data as required. Which is why someone probably told you it was impossible. They thought it was impossible because they had never thought of just polling the port. With interrupt-driven I/O, it _was_ impossible. But I just decided to stop using interrupts to eliminate that problem. If your MB had a later design, such as a 16550, then you could poll and gain some efficiency. I allowed for buffered input, as I recall, but the PCs I used it on didn't have that, and it would work without it. HOWEVER, modern controllers have much buffering, and the ability to moderate interrrupts. With polling you have a minimum constant overhead, even with no traffic. That's right, but it's a low overhead, compared to the overhead of interrupt service. Using interrupt moderation, you get the best of both worlds, because the contollers will only interrupt at a pre-set safe interval, and there is no additional overhead. And when there is no traffic there are no interrupts. I'm sure that's appropriate in some cases. In my case, it wasn't necessary. So if you have good hardware, polling has negative effects on performance. It ads overhead for no additional benefit. Polling improves performance in the circumstances I've described. The extra overhead is irrelevant as long as the system is less than 100% busy. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Right. Thats what I said. You'll killl your networking. So you don't want HT or SMP on a Server. Thats what most MP machines are used for. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sun, 27 Mar 2005 12:33:36 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: You can argue the technical theory all you want, but the measurements say otherwise. You have to ensure that you're doing the right measurements. FreeBSD 4.9 - Load: 38% (I put this in for fun :-) Freebsd 5.4-Pre UP (no HT) - Load: high 55-60% range FreeBSD 5.4-Pre SMP/HT - Load: 70-80% (much more jumping around) You'll find that the total CPU time required from start to finish for a single thread is ALWAYS higher for SMP than for a UP environment, even if you have separate physical processors. Several things happen when you move from a uniprocessor environment to an environment with two or more processors: - The total CPU time for each thread increases. - The total system load on a per process basis increases. - The total throughput of the system improves if there is more than one independent process running in the system. - Each of the processors runs more slowly than it would if it were the only processor running in a UP environment. If you run a single-thread benchmark on a MP system, you'll find that it runs more slowly than it does on a UP system. If you run multiple single-thread independent benchmarks on a MP system, you'll find that total CPU time for each benchmark increases over that required in a UP system--but the elapsed time required to complete all benchmarks substantially diminishes. To properly gauge the performance of a multiprocessor system, you must run a realistic mix of tasks on the system and measure overall throughput. If you do this, you'll find that you always come out ahead with multiple processors, even HT processors. Hyperthreading is just a special case of multiprocessing that imposes some additional restrictions. HT is much more sensitive to similarities in instruction mix across processes, because the actual processor hardware is being shared. With a sufficiently heterogenous instruction mix across multiple execution threads, this isn't a problem; but if you are running a single-threaded benchmark, or a series of identical single-threaded benchmarks, it can seriously distort your measurements. Although adding physical processors diminishes the performance of each processor, it still adds overall processing power, up to a certain point. The increment is never equal to the actual number of processors added, though; that is, if you go from one to two processors, you never get a doubling of effective processor power--it's more like 70-80%. The percentage increment gets worse with each additional processor, until you reach a point at which performance actually starts to decline (the point at which this happens is extremely hardware dependent, but it's always well beyond two processors). Hyperthreaded processors should not diminish in performance just because HT is turned on, because the hardware contention that diminishes performance in conventional MP systems is largely absent in a HT microprocessor. However, since you are really still only sharing a single processor with HT, the overall increment is much lower than it would be with two physical processors, and it is very sensitive to the instruction mix. this shows that you really are a bit foggy. Did you miss the part where with 2 processors you actually do have 2 processors? I actually read what Intel had to say on how the architecture works, and I spent years measuring systems the hard way (with hardware monitors and probes), so I know somewhat whereof I speak. Multiprocessing was always a significant hot-button issue with customers, as they always wanted to know how much they really gained with multiple processors (as opposed to what they had been promised). I can make an argument that networking with 1 processor on 5.4 is better than with 2. For example, with a test similar to the above, with 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before it hits 500Kpps unless you increase the interrrupts/second, which of course increases the system load. And even with the dropped packets (which should reduce the load because it doesnt have to receive and transmit the packet), the load is still higher than for 4.x with a single processor. Load is not a problem, as long as it's below 100%. Since individual processors slow down in MP configurations, anything that depends on raw processor speed will suffer in an MP configuration. However, overall system throughput is greatly enhanced by running with several processors. At the same time, the total processor time required to complete all tasks is greater in an MP environment than it would be in a UP environment--it's the fact that things can run in parallel that improves the throughput. Moral: if you want to avoid dropping
Re: hyper threading.
Test it yourself. I made a comment about making sure you test before you assume that HT is helpful. I don't feel compelled to convince you. Do what you want. -Original Message- From: John Pettitt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 17:23:40 -0800 Subject: Re: hyper threading. Well you've proven than if you pick your benchmark you can get the result you want. So what that says it that the kernel network code doesn't get any benefit from HT - given that HT is supposed to benefit diverse user tasks and no multiple copies of the same code this is not big news - since you have a HT box how about running a less system code intensive and more diverse test? John [EMAIL PROTECTED] wrote: You can argue the technical theory all you want, but the measurements say otherwise. You guys have done it once again. Baited me into firing up a test that I already know the results of: Setup: Bridging em0 to em1 Load: 500Kpps, 60 bytes 3.4Ghz P4 1MB Cache FreeBSD 4.9 - Load: 38% (I put this in for fun :-) Freebsd 5.4-Pre UP (no HT) - Load: high 55-60% range FreeBSD 5.4-Pre SMP/HT - Load: 70-80% (much more jumping around) The bottom line is that if you don't test things to get real world results, you don't know crap. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. this shows that you really are a bit foggy. Did you miss the part where with 2 processors you actually do have 2 processors? I can make an argument that networking with 1 processor on 5.4 is better than with 2. For example, with a test similar to the above, with 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before it hits 500Kpps unless you increase the interrrupts/second, which of course increases the system load. And even with the dropped packets (which should reduce the load because it doesnt have to receive and transmit the packet), the load is still higher than for 4.x with a single processor. You and many others regulary say things like SMP is obviously faster, or Opterons are noticably faster, but those statements are only true for certain applications. I've tested an Opteron 2.0Ghz against a 3.4Ghz P4, and the results are pretty interesting. For raw performance, ie interrupts/second handling, the P4 wins easily. The P4 wins out of the cache. But once you grow out of the cache and get more memory intensive, the Opteron beats it handily. So which is really faster? You could argue both depending on what benchmark you use. You have to test it in the environment where you plan to use it. Because the answer is almost never black and white. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 23:45:21 +0100 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Yes, the theory is very nice; you've done a nice job reading Intel's marketing garb. I haven't read their marketing materials. I'm simply going by the technical descriptions I've read of the architecture. However if you don't have a specific hyperthreading-aware scheduler and particularly well-written, threaded applications, you'll lose more than you'll gain. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. Since FreeBSDs network stack isn't particularly well threaded, nor is the scheduler optimized for hyperthreading, you get a big mess at the kernel level. Nothing needs to be specially optimized for hyperthreading. All you need is at least two threads available for dispatch, with reasonably heterogenous instruction mixes that can use different parts of the processor hardware at the same time. Real-world instruction mixes are often in this category in general-purpose operating systems. So if you have a nice application that does a lot of threaded math operations, you might think you've achieved something, Heavily math-oriented applications (or any group of applications that contains similar instruction mixes) are among the least likely to benefit from hyperthreading, because they will tend to use the same processor logic at the same time, effectively rendering hyperthreading moot. But what you've missed is that the overhead to manage the better utilization of the dual-pipelines created by HT costs more than it gains. Unless FreeBSD is very poorly written indeed, the gain from hyperthreading should still exceed the slight increase in overhead incurred by multiprocessing logic. Hence, the loss of performance. Where can I see this loss of
Re: A Riddle
WRONG on all counts! Firstly, anyone who uses their own server for lists is a complete idiot. Are you trying to insult everyone who has found AOL or Yahoo or Gmail to be more convenient for not clogging their server with lists traffic? Or do you just feel important because you laid out the $20 for your own domain? And YES, they do default to top posting. You hit reply, and you get this (see below). Its not really conducive to bottom posting, and when you do a google search and hit a long thread you read the answer you want first, rather than having to page down 200 times. If you're over 50 and once used a pdp11 then you may argue the opposite, but times are a-changing, so get with it. -Original Message- From: Fabian Keil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 21:59:59 +0100 Subject: Re: A Riddle [EMAIL PROTECTED] wrote: --- Chris [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hmm, I wonder if the lack of performance, or the unwanted emails were more heavily weighted in the decision? If there was any intelligent life on the list you could counter what you call Trolls with solid technical arguments. This reminds me of the old bsdi list. A bunch of half-wits who are just happy to belong to something and have other half-wits to correspond with. FreeBSD used to have open discussions between users and developers and it used to be real good. Now it sucks and the developers are detached, off in their own little world. See a pattern? But with a user base from places like gnu-rox.org and makeworld.com, what do you expect I guess? Please have a look at your own email address. As an aside, all of the major web mail providers default to top posting. Google (ever hear of them?) only shows the top N lines of a post. So if you bottom post, you don't see the message you want to see without having to make an effort. So when are you troglodytes going to climb out of your 1994 hibernations and get with the times? They don't default to top posting, they put the cursor on top, so you can read the whole message and cut irrelevant parts before replying. If Google doesn't display the whole message, the interface is crap. That's not the fault of anybody on this list. You may prefer one over the other, but its hardly a capital offense to do otherwise. Most of us have evolved out of our unix newsreaders. If you want to be read by as many people as possible on this list, the easiest way is to write well formed mails. Unfortunately, you are not only top posting, your mailing software also inserts line breaks where there shouldn't be any and makes it hard to see who wrote what. Have a look at the beginning of this mail. Your quotation is a mess. Anyone with a brain is using web mail for mailing lists these days: no more whining about spam or wasted bandwidth. Having a brain is good, but using it is even better. If the web interface produces garbage, changing the interface could be a smart move. Just my two brainless cents. Fabian -- http://www.fabiankeil.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
Apparently you can't read. I didn't say you were an idiot for running your own server. Only that you were an idiot to use your server to download tons of crap from lists that you don't want to read when for free you can have it stored elsewhere. I have a server, and a domain (several) and lots of other cool stuff. I got tired of wasting cpu cycles and disk space, considering that maybe 1 out of 20 messages actually interests me. You guys always complain about wasted bandwidth. Well if you use yahoo or gmail or aol then you don't waste any bandwidth of your own. You just read what you want to read. -Original Message- From: Chris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED] Sent: Sun, 27 Mar 2005 10:31:58 -0600 Subject: Re: A Riddle [EMAIL PROTECTED] wrote: -Original Message- From: Fabian Keil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sat, 26 Mar 2005 21:59:59 +0100 Subject: Re: A Riddle [EMAIL PROTECTED] wrote: --- Chris [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hmm, I wonder if the lack of performance, or the unwanted emails were more heavily weighted in the decision? If there was any intelligent life on the list you could counter what you call Trolls with solid technical arguments. This reminds me of the old bsdi list. A bunch of half-wits who are just happy to belong to something and have other half-wits to correspond with. FreeBSD used to have open discussions between users and developers and it used to be real good. Now it sucks and the developers are detached, off in their own little world. See a pattern? But with a user base from places like gnu-rox.org and makeworld.com, what do you expect I guess? Please have a look at your own email address. As an aside, all of the major web mail providers default to top posting. Google (ever hear of them?) only shows the top N lines of a post. So if you bottom post, you don't see the message you want to see without having to make an effort. So when are you troglodytes going to climb out of your 1994 hibernations and get with the times? They don't default to top posting, they put the cursor on top, so you can read the whole message and cut irrelevant parts before replying. If Google doesn't display the whole message, the interface is crap. That's not the fault of anybody on this list. You may prefer one over the other, but its hardly a capital offense to do otherwise. Most of us have evolved out of our unix newsreaders. If you want to be read by as many people as possible on this list, the easiest way is to write well formed mails. Unfortunately, you are not only top posting, your mailing software also inserts line breaks where there shouldn't be any and makes it hard to see who wrote what. Have a look at the beginning of this mail. Your quotation is a mess. Anyone with a brain is using web mail for mailing lists these days: no more whining about spam or wasted bandwidth. Having a brain is good, but using it is even better. If the web interface produces garbage, changing the interface could be a smart move. Just my two brainless cents. Fabian -- http://www.fabiankeil.de *** Formatted correctly for ease of reading *** [EMAIL PROTECTED] wrote: WRONG on all counts! Firstly, anyone who uses their own server for lists is a complete idiot. So - according to YOU, most all of us that run our own servers are idiots. Yanno what? You sound like the type that is forced to use his parents PC, Forced to use AOL, and forced to use web mail. So - since YOU can't have what most of us can and do have, you feel the need to lash out and verbally abuse. This is a classic case of the have-nots are beside them selfs over the haves. It's one thing to say something like: It's my opinion that (insert rhetoric here) Then to make a sweeping generalization as you just did. Shows us what kind a man (or boy) you are. Grow up - show some respect, don't insult - you will live longer when you do join society. And, as I said before - even tho you may bash us, think you are superior to us - we still love you anyways. Oh, and have a great day! -- Best regards, Chris If on an actuarial basis there is a 50 50 chance that something will go wrong, It will actually go wrong nine times out of ten. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
You know, you spout all of this wonderful theory without considering the quality of the implementation. Everything is implementation. And a key point that you consistently overlook is that FreeBSD 5.x is a particularly poor implementation of SMP. Linux and Dragonfly get 80% improvement in performance with a 2nd processor, and FreeBSD doesn't. Theory is meaningless if the implementation sucks, which is more than just part of the point. The concept that the kernel is poorly implemented by userland is well done is just not an assumption that you can make. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sun, 27 Mar 2005 12:33:36 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: You can argue the technical theory all you want, but the measurements say otherwise. You have to ensure that you're doing the right measurements. FreeBSD 4.9 - Load: 38% (I put this in for fun :-) Freebsd 5.4-Pre UP (no HT) - Load: high 55-60% range FreeBSD 5.4-Pre SMP/HT - Load: 70-80% (much more jumping around) You'll find that the total CPU time required from start to finish for a single thread is ALWAYS higher for SMP than for a UP environment, even if you have separate physical processors. Several things happen when you move from a uniprocessor environment to an environment with two or more processors: - The total CPU time for each thread increases. - The total system load on a per process basis increases. - The total throughput of the system improves if there is more than one independent process running in the system. - Each of the processors runs more slowly than it would if it were the only processor running in a UP environment. If you run a single-thread benchmark on a MP system, you'll find that it runs more slowly than it does on a UP system. If you run multiple single-thread independent benchmarks on a MP system, you'll find that total CPU time for each benchmark increases over that required in a UP system--but the elapsed time required to complete all benchmarks substantially diminishes. To properly gauge the performance of a multiprocessor system, you must run a realistic mix of tasks on the system and measure overall throughput. If you do this, you'll find that you always come out ahead with multiple processors, even HT processors. Hyperthreading is just a special case of multiprocessing that imposes some additional restrictions. HT is much more sensitive to similarities in instruction mix across processes, because the actual processor hardware is being shared. With a sufficiently heterogenous instruction mix across multiple execution threads, this isn't a problem; but if you are running a single-threaded benchmark, or a series of identical single-threaded benchmarks, it can seriously distort your measurements. Although adding physical processors diminishes the performance of each processor, it still adds overall processing power, up to a certain point. The increment is never equal to the actual number of processors added, though; that is, if you go from one to two processors, you never get a doubling of effective processor power--it's more like 70-80%. The percentage increment gets worse with each additional processor, until you reach a point at which performance actually starts to decline (the point at which this happens is extremely hardware dependent, but it's always well beyond two processors). Hyperthreaded processors should not diminish in performance just because HT is turned on, because the hardware contention that diminishes performance in conventional MP systems is largely absent in a HT microprocessor. However, since you are really still only sharing a single processor with HT, the overall increment is much lower than it would be with two physical processors, and it is very sensitive to the instruction mix. this shows that you really are a bit foggy. Did you miss the part where with 2 processors you actually do have 2 processors? I actually read what Intel had to say on how the architecture works, and I spent years measuring systems the hard way (with hardware monitors and probes), so I know somewhat whereof I speak. Multiprocessing was always a significant hot-button issue with customers, as they always wanted to know how much they really gained with multiple processors (as opposed to what they had been promised). I can make an argument that networking with 1 processor on 5.4 is better than with 2. For example, with a test similar to the above, with 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before it hits 500Kpps unless you increase the interrrupts/second, which of course increases the system load. And even with the dropped packets (which should reduce the load because it doesnt have to receive and transmit the packet), the load is still higher than for 4.x with a single processor. Load is not a problem, as long as it's below 100%. Since individual processors slow down in MP configurations, anything that
Re: hyper threading.
Polling is simply unecessary in most cases. You could get better performance using an em driver and setting max ints to whatever is optimal for your system. Polling adds latency and over head for no good reason. As I've said before, the FreeBSD team is patently clueless. They're grasping at straws. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sun, 27 Mar 2005 20:04:16 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Right. Thats what I said. You'll killl your networking. Beyond a certain network load, you have to increase the number of timer interrupts per second no matter how fast your processors are or how many of them you have, if you are polling your I/O interfaces instead of being driven from interrupts. I don't like the idea of routinely running 1000 timer interrupts per second, but I note that FreeBSD 6.x apparently is moving to this number (?). I'd prefer that it be readily configurable. There are other options but I'm not sure how well x86 hardware supports them. Having a very accurate, very high resolution elapsed-time counter on the processor(s) can help lower overhead by allowing the OS to get accurate time information without waiting for an interrupt and with execution of only a single instruction. Having programmable, very high resolution timers would help, too. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
and who do you think cares what you do? -Original Message- From: Dev Tugnait [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sun, 27 Mar 2005 12:41:37 -0500 Subject: Re: A Riddle I sticky this thread as retarded. * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Apparently you can't read. I didn't say you were an idiot for running your own server. Only that you were an idiot to use your server to download tons of crap from lists that you don't want to read when for free you can have it stored elsewhere. I have a server, and a domain (several) and lots of other cool stuff. I got tired of wasting cpu cycles and disk space, considering that maybe 1 out of 20 messages actually interests me. You guys always complain about wasted bandwidth. Well if you use yahoo or gmail or aol then you don't waste any bandwidth of your own. You just read what you want to read. -Original Message- From: Chris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED] Sent: Sun, 27 Mar 2005 10:31:58 -0600 Subject: Re: A Riddle [EMAIL PROTECTED] wrote: -Original Message- From: Fabian Keil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sat, 26 Mar 2005 21:59:59 +0100 Subject: Re: A Riddle [EMAIL PROTECTED] wrote: --- Chris [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hmm, I wonder if the lack of performance, or the unwanted emails were more heavily weighted in the decision? If there was any intelligent life on the list you could counter what you call Trolls with solid technical arguments. This reminds me of the old bsdi list. A bunch of half-wits who are just happy to belong to something and have other half-wits to correspond with. FreeBSD used to have open discussions between users and developers and it used to be real good. Now it sucks and the developers are detached, off in their own little world. See a pattern? But with a user base from places like gnu-rox.org and makeworld.com, what do you expect I guess? Please have a look at your own email address. As an aside, all of the major web mail providers default to top posting. Google (ever hear of them?) only shows the top N lines of a post. So if you bottom post, you don't see the message you want to see without having to make an effort. So when are you troglodytes going to climb out of your 1994 hibernations and get with the times? They don't default to top posting, they put the cursor on top, so you can read the whole message and cut irrelevant parts before replying. If Google doesn't display the whole message, the interface is crap. That's not the fault of anybody on this list. You may prefer one over the other, but its hardly a capital offense to do otherwise. Most of us have evolved out of our unix newsreaders. If you want to be read by as many people as possible on this list, the easiest way is to write well formed mails. Unfortunately, you are not only top posting, your mailing software also inserts line breaks where there shouldn't be any and makes it hard to see who wrote what. Have a look at the beginning of this mail. Your quotation is a mess. Anyone with a brain is using web mail for mailing lists these days: no more whining about spam or wasted bandwidth. Having a brain is good, but using it is even better. If the web interface produces garbage, changing the interface could be a smart move. Just my two brainless cents. Fabian -- http://www.fabiankeil.de *** Formatted correctly for ease of reading *** [EMAIL PROTECTED] wrote: WRONG on all counts! Firstly, anyone who uses their own server for lists is a complete idiot. So - according to YOU, most all of us that run our own servers are idiots. Yanno what? You sound like the type that is forced to use his parents PC, Forced to use AOL, and forced to use web mail. So - since YOU can't have what most of us can and do have, you feel the need to lash out and verbally abuse. This is a classic case of the have-nots are beside them selfs over the haves. It's one thing to say something like: It's my opinion that (insert rhetoric here) Then to make a sweeping generalization as you just did. Shows us what kind a man (or boy) you are. Grow up - show some respect, don't insult - you will live longer when you do join society. And, as I said before - even tho you may bash us, think you are superior to us - we still love you anyways. Oh, and have a great day! -- Best regards, Chris If on an actuarial basis there is a 50 50 chance that something will go wrong, It will actually go wrong nine times out of ten. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___
Re: hyper threading.
I've never seen any measurements. And most of your theories are clearly incorrect for FreeBSD. So what good is it? You claim to have done measurements, so what do you have to refute it? Being a fool is a choice. Its easily turned. The problem is when you can't get more hardware. When you are pushing the envelope, then you run out of choices. There is also a price/performance consideration. You make a choice to spend an extra 30% for certain hardware. But if you can get the same performance using lesser hardware with different settings or a different version of the OS, then you are wasting your money. If you don't need much, or you are spending someone else's money, then everything is moot. Just use whats cool. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sun, 27 Mar 2005 20:01:57 +0200 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: You know, you spout all of this wonderful theory without considering the quality of the implementation. Somethings can be derived directly from theory. If you know the design of the hardware, you can predict that two processors will provide x% increment of throughput over a single processor, even if you don't actually measure them. In my case, I cite both theory and my own experience in measuring actual systems. The general principles of behavior of multiprocessor systems are well understood, although specific implementations vary. It is clear, based even on design data alone, that hyperthreading will generally improve throughput and should never diminish it (disregarding OS overhead). It is equally clear that the gain won't be as great as having physically independent processors, but the idea of putting more of the idle processor logic to work is a good one. And a key point that you consistently overlook is that FreeBSD 5.x is a particularly poor implementation of SMP. Linux and Dragonfly get 80% improvement in performance with a 2nd processor, and FreeBSD doesn't. I'd need to see measurements to substantiate this. In general, when it comes to optimization, it's best not to fret too much over how many percentage points of processor power or throughput you gain or lose with specific configuration or implementation choices. If your system is running so close to the wire that five percent makes the difference between 100% busy and less than 100% busy, you need more hardware in any case. The concept that the kernel is poorly implemented by userland is well done is just not an assumption that you can make. Actually, it's not something that I spend a lot of time thinking about. Right now, my production system is never more than 0.4% busy. And if it were 99% busy, I'd be looking at faster hardware, no matter what OS or HT/MP options I might have implemented. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
Hmm, I wonder if the lack of performance, or the unwanted emails were more heaviliy weighted in the decision? If there was any intelligent life on the list you could counter what you call Trolls with solid techical arguments. This reminds me of the old bsdi list. A bunch of half-wits who are just happy to belong to something and have other half-wits to correspond with. FreeBSD used to have open discussions between users and developers and it used to be real good. Now it sucks and the developers are detached, off in their own little world. See a pattern? But with a user base from places like gnu-rox.org and makeworld.com, what do you expect I guess? -Original Message- From: Xavier Maillard [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 12:43:35 +0100 Subject: Re: A Riddle On 25 Mar 2005, Chris wrote: If we're to prove a point to those that name call, are rude, troll, and all the other recent events, we must do so on our level. Allow them to spew what ever it is they spew, and we must simply either ignore it (the correct way imho) Kill em with kindness, OR, reply in such a fashion that the user has no idea what we're saying. Let's stop the erosion of this list now before it goes too far. Over and out... I totally agree. This plus other things are the reasons why I chose to switch to another OS. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
--- Chris [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hmm, I wonder if the lack of performance, or the unwanted emails were more heavily weighted in the decision? If there was any intelligent life on the list you could counter what you call Trolls with solid technical arguments. This reminds me of the old bsdi list. A bunch of half-wits who are just happy to belong to something and have other half-wits to correspond with. FreeBSD used to have open discussions between users and developers and it used to be real good. Now it sucks and the developers are detached, off in their own little world. See a pattern? But with a user base from places like gnu-rox.org and makeworld.com, what do you expect I guess? -Original Message- From: Xavier Maillard [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 12:43:35 +0100 Subject: Re: A Riddle On 25 Mar 2005, Chris wrote: If we're to prove a point to those that name call, are rude, troll, and all the other recent events, we must do so on our level. Allow them to spew what ever it is they spew, and we must simply either ignore it (the correct way imho) Kill em with kindness, OR, reply in such a fashion that the user has no idea what we're saying. Let's stop the erosion of this list now before it goes too far. Over and out... I totally agree. This plus other things are the reasons why I chose to switch to another OS. Users that Insult people that offer help (good or bad) says much about that user. The tactic at hand (at least with the user that top posts) is to do nothing more then what it is hoping to do - incite anger *Sigh* Oh well - most of us are certainly above that. I don't agree. The spread of disinformation is like allowing a cancer to go untreated. There are a lot of people recommending a very poorly implemented OS because of the propaganda disseminated here. People's jobs and businesses are at stake. People waste a tremendous amount of time (me included) based on the ridiculously inaccurate comments made by people on this list. And like with alchoholism, the first step is admitting that you have a problem. If you're going to keep RA-RAing this effort, then you are part of the problem. You can make a person Angry by calling him a loser. But if the shoe fits, it may very well need to be said to get him off his butt. As an aside, all of the major web mail providers default to top posting. Google (ever hear of them?) only shows the top N lines of a post. So if you bottom post, you don't see the message you want to see without having to make an effort. So when are you troglodytes going to climb out of your 1994 hibernations and get with the times? You may prefer one over the other, but its hardly a capital offense to do otherwise. Most of us have evolved out of our unix newsreaders. Anyone with a brain is using web mail for mailing lists these days: no more whining about spam or wasted bandwidth. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
This is the kind of disinformation I have been referring to You'll get much better performance with 1 processor in UP mode. I suggest you do some testing. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 19:28:11 +0100 Subject: Re: hyper threading. Perttu Laine writes: I have 3,4ghz ht processor and freebsd shows up only one processors. I suppose it should show two in ht models? so, GENERIC kernel doesn't support it? but should I add to kernel config to enable it? by reading config examples I think this should be enough: options SMP Yes, that's all you need. Just add that line, rebuild and reinstall the kernel, and you're all set. Works great. Hyperthreading doesn't buy you as much as truly separate processors, but it helps you get more bang for the buck out of your single processor (depending on the type of workload you run). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
I am offerring the correct information. Turning on SMP on an HT machine will kill the systems performance much more than hyperthreading will gain. I told him to test. The degradation is easily measurable. -Original Message- From: Chris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 13:49:53 -0600 Subject: Re: hyper threading. [EMAIL PROTECTED] wrote: This is the kind of disinformation I have been referring to You'll get much better performance with 1 processor in UP mode. I suggest you do some testing. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 19:28:11 +0100 Subject: Re: hyper threading. Perttu Laine writes: I have 3,4ghz ht processor and freebsd shows up only one processors. I suppose it should show two in ht models? so, GENERIC kernel doesn't support it? but should I add to kernel config to enable it? by reading config examples I think this should be enough: options SMP Yes, that's all you need. Just add that line, rebuild and reinstall the kernel, and you're all set. Works great. Hyperthreading doesn't buy you as much as truly separate processors, but it helps you get more bang for the buck out of your single processor (depending on the type of workload you run). If you feel someone is in error - feel free to jump in and offer what you feel to be correct information. Sometimes sitting back and not correcting someone is far worse then someone offering information based on what they know, experience, or what have you. In this case, by NOT offering the correct information, YOU are just as much to blame for what you say is going on. For those of us that don't answer, we either don't know (as is the case wit myself) OR, they have not had a chance to read the thread. -- Best regards, Chris It is a simple task to make things complex, but a complex task to make them simple. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Yes, the theory is very nice; you've done a nice job reading Intel's marketing garb. However if you don't have a specific hyperthreading-aware scheduler and particularly well-written, threaded applications, you'll lose more than you'll gain. Since FreeBSDs network stack isn't particularly well threaded, nor is the scheduler optimized for hyperthreading, you get a big mess at the kernel level. So if you have a nice application that does a lot of threaded math operations, you might think you've achieved something, But what you've missed is that the overhead to manage the better utilization of the dual-pipelines created by HT costs more than it gains. Hence, the loss of performance. The poblem is not at the application level, but at the kernel level. The SMP overhead is so substantial, and the OS is working thinking it has 2 processors, that process switching and interrupt handling slow down considerably. A machine with a 50% load UP will run 65-70% load with HT/SMP running. Like I said, its easily measurable. Thats at the kernel level (say routing or bridging performance). Now if the machine isn't a server, it may be just fine. Thats why I suggested testing. But for a network server HT is bad. Very Bad. Not only that, but FreeBSD 5.x actually has a higher capacity network-wise with 1 processor than 2, and I'm sure you can theorize why 2 processors should be faster than one. The theory only matters if you have well written code to handle it properly. FreeBSD is a long way off from that. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 22:06:38 +0100 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: You'll get much better performance with 1 processor in UP mode. I suggest you do some testing. Where can I see the results of your own exhaustive tests? The purpose of hyperthreading is to keep all hardware on the microprocessor working. Many instructions use only certain parts of the chip, leaving other parts idle. By allowing two execution contexts to be maintained simultaneously, hyperthreading makes it possible to better utilize hardware that might otherwise sit idle. The ideal case would be two threads executing completely different instruction sequences that use very different parts of this chip. I don't have exact figures but I'd guess that in ideal situations you might get 20%-30% extra out of a single processor in this way--enough to negate the greater overhead of the SMP logic. A situation in which hyperthreading would _not_ help would be any type of parallel processing, in which multiple threads execute very similar instructions. These instructions are likely to require the same parts of the microprocessor at the same time, so it's unlikely that they will be able to execute in parallel--one will have to wait for the other (because the microprocessor has logic areas that can function independently and simultaneously, but these areas don't do the same things, so they are not redundant logic). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
Uh, thats not the correct load average to use. Use the numbers obtained from top or systat. Those loads will show Zero load when you're routing 100K pps. It doesnt measure kernel load. -Original Message- From: Paul A. Hoadley [EMAIL PROTECTED] To: John Pettitt [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Sun, 27 Mar 2005 09:53:25 +0930 Subject: Re: hyper threading. Hello, On Sat, Mar 26, 2005 at 03:54:06PM -0800, John Pettitt wrote: Paul A. Hoadley wrote: I note a slight difference in the 10 minute load average in favour of the uniprocessor run (0.00 vs 0.10 in the hyperthreading run), though I doubt this alone could account for a 15% difference in total score. Notice the HT run had load on the box (0.31) when it started. If you're going to run benchmarks you need to start with a clean reboot before each run and make sure all the background daemons have been killed and and the load is zero. You are absolutely right, and I did note the difference in load averages. I'm not making any claims---someone asked for measurements, and I happened to have these handy. -- Paul. w http://logicsquad.net/ h http://paul.hoadley.name/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hyper threading.
You can argue the technical theory all you want, but the measurements say otherwise. You guys have done it once again. Baited me into firing up a test that I already know the results of: Setup: Bridging em0 to em1 Load: 500Kpps, 60 bytes 3.4Ghz P4 1MB Cache FreeBSD 4.9 - Load: 38% (I put this in for fun :-) Freebsd 5.4-Pre UP (no HT) - Load: high 55-60% range FreeBSD 5.4-Pre SMP/HT - Load: 70-80% (much more jumping around) The bottom line is that if you don't test things to get real world results, you don't know crap. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. this shows that you really are a bit foggy. Did you miss the part where with 2 processors you actually do have 2 processors? I can make an argument that networking with 1 processor on 5.4 is better than with 2. For example, with a test similar to the above, with 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before it hits 500Kpps unless you increase the interrrupts/second, which of course increases the system load. And even with the dropped packets (which should reduce the load because it doesnt have to receive and transmit the packet), the load is still higher than for 4.x with a single processor. You and many others regulary say things like SMP is obviously faster, or Opterons are noticably faster, but those statements are only true for certain applications. I've tested an Opteron 2.0Ghz against a 3.4Ghz P4, and the results are pretty interesting. For raw performance, ie interrupts/second handling, the P4 wins easily. The P4 wins out of the cache. But once you grow out of the cache and get more memory intensive, the Opteron beats it handily. So which is really faster? You could argue both depending on what benchmark you use. You have to test it in the environment where you plan to use it. Because the answer is almost never black and white. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 23:45:21 +0100 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Yes, the theory is very nice; you've done a nice job reading Intel's marketing garb. I haven't read their marketing materials. I'm simply going by the technical descriptions I've read of the architecture. However if you don't have a specific hyperthreading-aware scheduler and particularly well-written, threaded applications, you'll lose more than you'll gain. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. Since FreeBSDs network stack isn't particularly well threaded, nor is the scheduler optimized for hyperthreading, you get a big mess at the kernel level. Nothing needs to be specially optimized for hyperthreading. All you need is at least two threads available for dispatch, with reasonably heterogenous instruction mixes that can use different parts of the processor hardware at the same time. Real-world instruction mixes are often in this category in general-purpose operating systems. So if you have a nice application that does a lot of threaded math operations, you might think you've achieved something, Heavily math-oriented applications (or any group of applications that contains similar instruction mixes) are among the least likely to benefit from hyperthreading, because they will tend to use the same processor logic at the same time, effectively rendering hyperthreading moot. But what you've missed is that the overhead to manage the better utilization of the dual-pipelines created by HT costs more than it gains. Unless FreeBSD is very poorly written indeed, the gain from hyperthreading should still exceed the slight increase in overhead incurred by multiprocessing logic. Hence, the loss of performance. Where can I see this loss of performance documented? The poblem is not at the application level, but at the kernel level. The SMP overhead is so substantial, and the OS is working thinking it has 2 processors, that process switching and interrupt handling slow down considerably. How much is so substantial? Where can I see this documented? A machine with a 50% load UP will run 65-70% load with HT/SMP running. Like I said, its easily measurable. Then you can show me the measurements. Where are they? A 40% increase in system load just because of multiprocessing is enormous. Where did you get this figure? Thats at the kernel level (say routing or bridging performance). But the kernel is only a small fraction of overall processor utilization. Now if the machine isn't a server, it may be just
Re: hyper threading.
When you get your machine running without a kernel let me know. The kernel is the key to the O/S. If you don't need networking and don't have many interrupts, then it probably doesnt matter that much. -Original Message- From: John Pettitt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 17:23:40 -0800 Subject: Re: hyper threading. Well you've proven than if you pick your benchmark you can get the result you want. So what that says it that the kernel network code doesn't get any benefit from HT - given that HT is supposed to benefit diverse user tasks and no multiple copies of the same code this is not big news - since you have a HT box how about running a less system code intensive and more diverse test? John [EMAIL PROTECTED] wrote: You can argue the technical theory all you want, but the measurements say otherwise. You guys have done it once again. Baited me into firing up a test that I already know the results of: Setup: Bridging em0 to em1 Load: 500Kpps, 60 bytes 3.4Ghz P4 1MB Cache FreeBSD 4.9 - Load: 38% (I put this in for fun :-) Freebsd 5.4-Pre UP (no HT) - Load: high 55-60% range FreeBSD 5.4-Pre SMP/HT - Load: 70-80% (much more jumping around) The bottom line is that if you don't test things to get real world results, you don't know crap. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. this shows that you really are a bit foggy. Did you miss the part where with 2 processors you actually do have 2 processors? I can make an argument that networking with 1 processor on 5.4 is better than with 2. For example, with a test similar to the above, with 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before it hits 500Kpps unless you increase the interrrupts/second, which of course increases the system load. And even with the dropped packets (which should reduce the load because it doesnt have to receive and transmit the packet), the load is still higher than for 4.x with a single processor. You and many others regulary say things like SMP is obviously faster, or Opterons are noticably faster, but those statements are only true for certain applications. I've tested an Opteron 2.0Ghz against a 3.4Ghz P4, and the results are pretty interesting. For raw performance, ie interrupts/second handling, the P4 wins easily. The P4 wins out of the cache. But once you grow out of the cache and get more memory intensive, the Opteron beats it handily. So which is really faster? You could argue both depending on what benchmark you use. You have to test it in the environment where you plan to use it. Because the answer is almost never black and white. -Original Message- From: Anthony Atkielski [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 23:45:21 +0100 Subject: Re: hyper threading. [EMAIL PROTECTED] writes: Yes, the theory is very nice; you've done a nice job reading Intel's marketing garb. I haven't read their marketing materials. I'm simply going by the technical descriptions I've read of the architecture. However if you don't have a specific hyperthreading-aware scheduler and particularly well-written, threaded applications, you'll lose more than you'll gain. If that were true, then it would be equally true of systems with actual multiple physical processors. In practice, multiple processors provide an obvious performance gain, and hyperthreading does, too, although it's much more modest than the gain obtained from physically independent processors. Since FreeBSDs network stack isn't particularly well threaded, nor is the scheduler optimized for hyperthreading, you get a big mess at the kernel level. Nothing needs to be specially optimized for hyperthreading. All you need is at least two threads available for dispatch, with reasonably heterogenous instruction mixes that can use different parts of the processor hardware at the same time. Real-world instruction mixes are often in this category in general-purpose operating systems. So if you have a nice application that does a lot of threaded math operations, you might think you've achieved something, Heavily math-oriented applications (or any group of applications that contains similar instruction mixes) are among the least likely to benefit from hyperthreading, because they will tend to use the same processor logic at the same time, effectively rendering hyperthreading moot. But what you've missed is that the overhead to manage the better utilization of the dual-pipelines created by HT costs more than it gains. Unless FreeBSD is very poorly written indeed, the gain from hyperthreading should still exceed the slight increase in overhead incurred by multiprocessing logic. Hence, the loss of
A Riddle
Q: Why are FreeBSD users like Liberals? A: They panic and start to call you names when you tell them the truth. -Original Message- From: Subhro [EMAIL PROTECTED] To: [EMAIL PROTECTED]; freebsd-questions@freebsd.org Sent: Thu, 24 Mar 2005 21:37:12 +0530 Subject: RE: AMD64 much slower than i386 on FreeBSD 5.4-pre -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 24, 2005 20:53 To: freebsd-questions@freebsd.org Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre I think that warning people that the good name of FreeBSD is being tainted by the current band of clowns is very productive. Its more like a religion now; I've never seen so many people in total denial that their snip OH NO!!! ANOTHER AOLer. One more entry added to my kill list. THIS IS MY EARNEST REQUEST TO ALL THE LIST MEMBERS. BANDWIDTH IS VERY COSTLY HERE SO PLEASE PLEASE PLEASE DO NOT WASTE BANDWIDTH AND TIME BY FEEDING TROLLS. Best Regards S. Indian Institute of Information Technology Subhro Sankha Kar Block AQ-13/1, Sector V Salt Lake City PIN 700091 India ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
-Original Message- From: Boris Spirialitious [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Fri, 25 Mar 2005 08:24:31 -0800 (PST) Subject: Re: A Riddle --- Duo [EMAIL PROTECTED] wrote: On Fri, 25 Mar 2005 [EMAIL PROTECTED] wrote: Q: Why are FreeBSD users like Liberals? A: They panic and start to call you names when you tell them the truth. Q: Why are AOL users like Religious Neo-Conservatives? A: They like to pay a high price for their service, despite lower cost alternatives, and will tell you, their way is the only way. AOL web mail is free, you know-nothing idiot. Which not only confirms the riddle, but explains about why you are so wrong about just about everything you've said in the last week. You are a downright riot actaully! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A Riddle
There are 2 kinds of people in America, Jerry. The Rich and those who complain about the Rich. The difference here as opposed to some other countries is that which group you belong to is a personal choice. I respect your choice. You seem very happy in your ignorance of virtually every subject. You taking a shot at me is about as entertaining as it gets, Jerry. It really, really is. -Original Message- From: Jerry McAllister [EMAIL PROTECTED] Q: Why are FreeBSD users like Liberals? A: They panic and start to call you names when you tell them the truth. Last I knew that was a technique most perfected by the right wing especially when they begin noticing that reality does not correspond to their need to support sagging egos. Sorry about clogging the bandwidth. Could resist taking a shot at a troll. Jerry ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
If you haven't used amd64 then why are you qualified to comment on the subject? If he's using the same settings for i386 and amd64, then the results should be balanced. I think the point here is that the same settings, which are probably the defaults, run a lot slower on amd64 than i386. And I don't see that you have any insight to provide. I hope FreeBSD hasn't become linux; in that it doesnt work out of the box and you have to selectively kludge it to show good results in any particular benchmark? Thats what made FreeBSD good historically. It was just good in general. -Original Message- From: Nick Pavlica [EMAIL PROTECTED] To: Boris Spirialitious [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Wed, 23 Mar 2005 19:05:59 -0700 Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre Hi Boris, I haven't had an opportunity to work with any AMD64 hardware yet, but have had good results with 5.4.? on i686. I can relate to your frustration, but can say that I was able to greatly improve 5.x performance with some effort. For example I went from a maximum sustained disk write of 15Mb/s to 90Mb/s on a file server. That said, to help you get a better response to your question I would suggest trying these things: - Document and post your testing procedures and results. This will allow others to get a much clearer picture of what may be happening. As I'm sure you know support via e-mail is very difficult because there is so much information that is missing. - You may want to try the performance list if you don't get any answers from this list. - File a problem report so that the developers are aware of your situation. I don't think that they spend allot of time on this list. (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/index.html) I hope this helps! --Nick What optimizations have you done to this point? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
I think that warning people that the good name of FreeBSD is being tainted by the current band of clowns is very productive. Its more like a religion now; I've never seen so many people in total denial that their beliefs are completely wrong. A lot of people are wasting a lot of time because of this propaganda. The cluelessness in the performance list is a good indication. -Original Message- From: jason henson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org; [EMAIL PROTECTED] Sent: Thu, 24 Mar 2005 00:57:58 -0500 Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre [EMAIL PROTECTED] wrote: The answer, Boris, is that the team has no idea what they're doing. Check out some of the threads on performance testing. They tune little pieces here and there, and break 10 other things in the process. Matt Dillon determined that 10,000 ints/second was optimal. Of course if you're passing 10Kpps that means you get an interrupt for every packet. They're playing pin the tail on the donkey. You could understand what he was saying? I wanted to help but was unsure of what he was asking. I also seem to remember that discussion you are referring too. IIRC, 10,000hz for pooling was the setting they ere talking about. But on it would very a little, and with the fxp based card polling hurt a little because the card was already ding its own thing in hardware. So that setting was redundant, it was best to leave it alone. He also seemed to say the network bandwidth was constant, and system load rose with an 64bit system. This right? If he was using GENERIC on a smp system he was only using 1 cpu with out a recompile. There is just so much that could be wrong and he gives no information on his system or settings. Doess he have 2 amd64 pcs with 2 different installs of 5.3, or a single machine that he ran both versions on? The router, is that a third machine that was an amd64 system, or something else? He says i386, but an up to date 5.3 world doesn't support 386 with out a work around. The least commom setting is now 486, but a build for 686 would be better. Did he tell you if he had polling on? So I guess it is a good thing you were able to help him, because I couldn't. Not to mention the flame bait you through out, well, that would be wrong. ___ - Previous Message No, thats not what I was talking about. They were tuning the MAX_INTS parameter for the em driver, which can hold off interrupts to reduce system overhead. Instead of minimizing the load, they were focused on squeezing a few extra bits out of iperf, which is not how you tune performance. If you get 700Kb/s and have a 95% load and can get 695Kb/s with 60% load, which is better? Plus they were testing with a regular PCI bus, so they were hitting the wall on the bus throughput, which changes all the timings, so it was just a stupid test in general. I would say 60% load. Now I completely understand what you were saying. I'm not 100% sure of what he was saying, but I've seen the same thing. I take an i386 disk and pop on an amd64 disk with the same settings, except for the 3 or 4 required differences, and the i386 machine has WAY less network load. So maybe your buildworld runs faster, but the whole interrupt/process switching mechanism runs like crap, so you likely have a slower machine. I haven't seen any test that shows otherwise, just a bunch of swell guys swearing that one thing is faster than another. I understand that you don't want to hear the truth, so flame away. But its not going to make things any better. Ahh! More flame bait! I just didn't like you platitudinal and unproductive message that I believe would just drive Boris onto linux and leave a possible open problem on FreeBSD for some one else to discover latter. It's not that I don't want to hear the truth, you were just not saying anything worth his time. But atleast now we can get some where to help him and the amd64 port. I also had the idea that Boris was just trolling because he has not responded, just said FreeBSD was bad and left us to duke it out. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] So the whole interrupt/process switching mechanism runs like crap with the amd64 build? Since I don't have a amd64 system, and you might hav access to atleast 1, how about getting a little info on the irqs? Look at systat -vmstat or vmstat -i under load? aybe report it back? I wonder if the irq rates are changing, or irqs are taking longer to service. Either there is a problem. Ofcourse some hardware info would be nice, chipset and cpu? Maybe you script vmstat -i for a log, and use netperf too? I like Nick's followup. I would
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
Maybe you shouldn't prejudge. Its clear than no one with their own addresses has any answers. -Original Message- From: Subhro [EMAIL PROTECTED] To: [EMAIL PROTECTED]; freebsd-questions@freebsd.org Sent: Thu, 24 Mar 2005 21:37:12 +0530 Subject: RE: AMD64 much slower than i386 on FreeBSD 5.4-pre -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 24, 2005 20:53 To: freebsd-questions@freebsd.org Subject: Re: AMD64 much slower than i386 on FreeBSD 5.4-pre I think that warning people that the good name of FreeBSD is being tainted by the current band of clowns is very productive. Its more like a religion now; I've never seen so many people in total denial that their snip OH NO!!! ANOTHER AOLer. One more entry added to my kill list. THIS IS MY EARNEST REQUEST TO ALL THE LIST MEMBERS. BANDWIDTH IS VERY COSTLY HERE SO PLEASE PLEASE PLEASE DO NOT WASTE BANDWIDTH AND TIME BY FEEDING TROLLS. Best Regards S. Indian Institute of Information Technology Subhro Sankha Kar Block AQ-13/1, Sector V Salt Lake City PIN 700091 India ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
I think the point of a list is so that someone can say oh yes, I had problems with the em driver in amd64 also; try card X. But instead you get a lot of people with no real idea trying to explain away the problem, as if there is no chance that the amd64 implementant just plain sucks wind. If someone who actually has an amd64 build could post some usage/load numbers, or someone who did some testing with various hardware, that might be useful. So far what we have is like a bunch of Mothers trying to defend their children without having any viable answers or evidence than amd64 is any good at all. Only a people who say nonsensical things like my opteron blows away any P4, like a kid bragging about his mustang or something. The em driver has a standard hold-off of 8000 ints/second, so thats not likely the problem. Its likely to be the same in both i386 and amd64, so its a control. snippage So the whole interrupt/process switching mechanism runs like crap with the amd64 build? Since I don't have a amd64 system, and you might hav access to atleast 1, how about getting a little info on the irqs? Look at systat -vmstat or vmstat -i under load? aybe report it back? I wonder if the irq rates are changing, or irqs are taking longer to service. Either there is a problem. Ofcourse some hardware info would be nice, chipset and cpu? Maybe you script vmstat -i for a log, and use netperf too? I like Nick's followup. I would guese Boris may have a problem with proper hardware support. I can't really said it is bad hardware if speeds are the same, just high load(right?). Maybe the driver he is using is not good for 64bit as it is for 32bit? I think if Boris studies the thread I like to below he will be alright. Check this out: http://www.atm.tut.fi/list-archive/freebsd-stable/thrd66.html http://docs.freebsd.org/cgi/mid.cgi?200502171636.10361.drice Inparticular: http://www.atm.tut.fi/list-archive/freebsd-stable/msg19651.html http://www.atm.tut.fi/list-archive/freebsd-stable/msg19679.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network Interface Card Setup
man driver, such as 'man em' for the em driver -Original Message- From: Dixit, Viraj [EMAIL PROTECTED] To: freebsd-questions@freebsd.org Sent: Wed, 23 Mar 2005 09:47:49 -0800 Subject: Network Interface Card Setup Hi, I have got a mismatch Duplex problem. Can someone confirm these commands to use with sysinstall. I want to change various options for the network card or where can I find these commands. * media 100baseTx mediaopt autoselect * media 100baseTX mediaopt full-duplex Thanks, VJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
The answer, Boris, is that the team has no idea what they're doing. Check out some of the threads on performance testing. They tune little pieces here and there, and break 10 other things in the process. Matt Dillon determined that 10,000 ints/second was optimal. Of course if you're passing 10Kpps that means you get an interrupt for every packet. They're playing pin the tail on the donkey. : Am Mittwoch, 23. März 2005 01:19 schrieb Boris Spirialitious: -- Emanuel Strobl [EMAIL PROTECTED] wrote: Am Mittwoch, 23. März 2005 00:38 schrieb Boris Spirialitious: I have opteron 246 system with 2 port intel em card. We have test bed with about 200Kbs traffic and we route through 5.3/i386 system. Load is about 50%. With same settings, amd64 system run with 85% load. How could be so slow? What tuning extra is needed for amd64 kernels? 200kB/s sounds like misconfigured duplex/negotiation mode. But why don't you try FreeBSD 5.4-BETA1? Many performance improvements were achieved and stability is given in the -STABLE branch (BETA1 is a relese of FreeBSD 5-STABLE) I am sorry, I mean 200Mb/s. It is a controlled stream Unfortunately that's a not so uncommon result with em and 5.3. There are tuning methods but they won't give the big kick. Like mentioned, try 5.4 (BETA1), depending on your employment you'll see tremendous improvement, I don't have values handy nor can I confirm that for amd64, but you really wnat to try out, especially if this box isn't productive yet, which it isn't if I understood correctly. I am running 5.4-Pre now. Its the same. Everyone always say try new version, but it always the same. i compare em to em, only difference is amd64 vs i386. So amd64 O/S is this much slower than i386? So why anyone use? Is like nobody know what is going on with this OS. Before, people tell me Opteron on i386 no good. But now that I test, its much better than amd64. Why is there always excuse with FreeBSD 5? Always try next version. Always same slow result? Boris __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 much slower than i386 on FreeBSD 5.4-pre
The answer, Boris, is that the team has no idea what they're doing. Check out some of the threads on performance testing. They tune little pieces here and there, and break 10 other things in the process. Matt Dillon determined that 10,000 ints/second was optimal. Of course if you're passing 10Kpps that means you get an interrupt for every packet. They're playing pin the tail on the donkey. You could understand what he was saying? I wanted to help but was unsure of what he was asking. I also seem to remember that discussion you are referring too. IIRC, 10,000hz for pooling was the setting they ere talking about. But on it would very a little, and with the fxp based card polling hurt a little because the card was already ding its own thing in hardware. So that setting was redundant, it was best to leave it alone. He also seemed to say the network bandwidth was constant, and system load rose with an 64bit system. This right? If he was using GENERIC on a smp system he was only using 1 cpu with out a recompile. There is just so much that could be wrong and he gives no information on his system or settings. Doess he have 2 amd64 pcs with 2 different installs of 5.3, or a single machine that he ran both versions on? The router, is that a third machine that was an amd64 system, or something else? He says i386, but an up to date 5.3 world doesn't support 386 with out a work around. The least commom setting is now 486, but a build for 686 would be better. Did he tell you if he had polling on? So I guess it is a good thing you were able to help him, because I couldn't. Not to mention the flame bait you through out, well, that would be wrong. ___ - Previous Message No, thats not what I was talking about. They were tuning the MAX_INTS parameter for the em driver, which can hold off interrupts to reduce system overhead. Instead of minimizing the load, they were focused on squeezing a few extra bits out of iperf, which is not how you tune performance. If you get 700Kb/s and have a 95% load and can get 695Kb/s with 60% load, which is better? Plus they were testing with a regular PCI bus, so they were hitting the wall on the bus throughput, which changes all the timings, so it was just a stupid test in general. I'm not 100% sure of what he was saying, but I've seen the same thing. I take an i386 disk and pop on an amd64 disk with the same settings, except for the 3 or 4 required differences, and the i386 machine has WAY less network load. So maybe your buildworld runs faster, but the whole interrupt/process switching mechanism runs like crap, so you likely have a slower machine. I haven't seen any test that shows otherwise, just a bunch of swell guys swearing that one thing is faster than another. I understand that you don't want to hear the truth, so flame away. But its not going to make things any better. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x Opteron Question
You sound more like a politician than an engineer, Nick. I'm not a guinea pig, and I have a business to run,and I'm not going to spend an extra $400. per system to to get the same speed as with 4.x just to be one of the fellas. I have no obligation to care about their plight, just as they've informed me that they have no obligation to care about the needs of anyone in their user base. As for leadership, the FreeBSD developers told everyone that 5.3 was da bomb, and that 5.4 would be better, but if you get Robert Watson in a choke-hold he'll admit that its going to be the 6.x before they are where they should be now. The truth is that the model they chose for 5.x just plain doesn't work. If you get a charge out of playing follow the bozos, good for you. But I have a car, and when the new model comes out I might test drive it, and if it sucks I'll either keep my old car or buy something else. For now I'm slapping a coat of wax on 4.x and hoping that someone figures it out shortly. I chose freeBSD initially over linux not because there's a bunch of good guys on the project, but because it was good. I'll stick with 4.x for the same reasons. Personally I think its going to be a long, long time before FreeBSD is any good anymore. And I don't have that kind of time. The entire point of the project is to improve SMP performance, and several years in its worse than it was before. What evidience is there that there is an end to this ridiculous tunnel? -Original Message- Hello, On Fri, 18 Mar 2005 22:16:05 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -Original Message- From: Nick Pavlica [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Fri, 18 Mar 2005 19:45:44 -0700 Subject: Re: FreeBSD 4.x Opteron Question :em1897, : I'm curious how you are testing. In my testing, the 5.4 pre IP :stack performed very well. I was able to get 100% more throughput :than Linux (2.6.10 FC3) under heavy load on the exact same hardware. :I was actually surprised at the difference because I have been a Linux :Zellot for years. I didn't see any packet loss in my tests, but I do :have good quality networking gear and servers. I was happy enough :after my testing that I'm going to move my 4.x servers to 5.4 when :it's released. I haven't tested dragonfly yet, but get all the :performance I need out of FreeBSD. : :--Nick on a side note, I thought top posting was a no-no? I see gmail has the same issues as AOL. Or are the issues with the old farts with their newsreaders? :-) I don't get your logic. You are converting your servers from 4.x to 5.4 because you've found that 5.4 is faster than linux? Is that some sort of riddle? FreeBSD has always been faster than linux; I'm comparing FreeBSD 4.x to 5.4, so I'm not sure what linux has to do with anything here. I guess I was a little vague :). I brought up Linux because you mentioned it in your earlier post, and wanted to share my results with it. Additionally, I have used Linux in many projects over the years and like to use it as a baseline of comparison. The point that I was trying to make was that I was getting good results with 5.4 in my tests. I have been pitting 4.x against 5.x since I began using FreeBSD for my projects. The 4.x series does have an excellent performance record that can't be questioned, however, 5.x gets the job done for me. What you can get in terms of throughput doesn't always give you the right answer. My tests measure kernel performance; as I'm interested in routing/packet-processing performance. Sockets add a tricky variable. But I take the IP stack out of the equation altogether by bridging packets through a box, and I prefer to use a 50% load as timings sometimes change when you start to saturate things unnaturally. You won't be running your machine at 100% load, so it makes no sense to test it that way. For the latest test I have a 3.06Ghz xeon bridging 486,000pps. For FreeBSD 4.9, this is a 50% load. The load under 5.4 is 65%. It tests interrupt and process switching performance, which for a networking device is a key performance indicator. (I think) that the 5.4 kernel is threaded, so there are latencies that are very difficult to overcome. Linux has been threaded for a long time, and always has been a poor Uniprocessor performer. 5.4 is better than linux with one processor, but if you are UP then 4.x is clearly the way to go. Linux kills 5.4 with dual processors; in fact 5.4 seems to have higher network performance with 1 processor than 2. They still have a lot of issues to work out. DragonflyBSD has done a nice job with MP, but their performance is still a work in progress. For UP, their performance is dismal so its not quite where it needs to be, but its promising. My tests are focused around simple network I/O and saturate all the other subsystems before making the kernel break a sweat, MP or UP. Curiously, all of my tests have never caused excessive CPU utilization
Re: FreeBSD 4.x Opteron Question
You are a strange bird, Nick. Do what you want with your life, but don't preach your BS to others. No one cares how hard anyone works or how much they are paid if the work is crap. And if you're dumb enough to think that they really do it for free, then you've been completely bamboozled and deserve what you get. If you think these guys work at a hardware store all day and then slave over FreeBSD by candlelight you really don't get anything. Most of them work or consult for corporate sponsors or do the work on their companies time, and their companies get features they want prioritized. They do what they want in the order they want to do it and use the user base as guinea pigs so Yahoo doesn't have to test stuff for them. Get a clue. -Original Message- I'm happy to see that I'm not the only one working on Saturday. I understand the business aspect of things, I have business that rely on this technology as well. The developers Robert W don't owe us anything because we are not paying them. We didn't marry into there family, and didn't pull them out of a burning building. Without the free work that they have contributed, the work that I have contributed, and the thousands of others that have donated there time and money we wouldn't be able to exploit there work for our gain. I feel that it's important to give back, and clearly you do as well or you wouldn't be helping people on this list. I believe that this is reason enough to help the 5.x effort. We could choke everyone of the developers, but the fact remains that they are the developers of FreeBSD, and they are moving forward with these technologies. There is absolutely nothing wrong with staying on 4.x, and I know that you have to do what is right for you. What I'm advocating is that 5.x currently performs well enough to meet the performance needs for many organizations and can be used in production systems. It's also important to work on the problems at hand so that when 6.x is release it's what you and many others are expecting from it. I may sound like a politician, but as an Engineer and a Businessman I have grown accustom to looking at the bigger picture. When you test drive a car you are looking at more than how fast you can go from stop light to stop light. What is the fuel mileage, warranty, cost, color, etc. This is precisely how/why I got involved with this community and moved away from my RedHat roots. The funny thing is that I was making the exact same argument that you are against 5.x a few months ago to my team after comparing the disk I/O performance between 4.11 and 5.3. With some help from members of this community I was able to improve performance dramatically on 5.3 and noticed further improvement on 5.4. FreeBSD will continue to improve, but it isn't going to magically happen. It's likely that we will not completely agree with each other on this topic, but enjoy the being able to discuss both perspectives. --Nick On Sat, 19 Mar 2005 18:59:02 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You sound more like a politician than an engineer, Nick. I'm not a guinea pig, and I have a business to run,and I'm not going to spend an extra $400. per system to to get the same speed as with 4.x just to be one of the fellas. I have no obligation to care about their plight, just as they've informed me that they have no obligation to care about the needs of anyone in their user base. As for leadership, the FreeBSD developers told everyone that 5.3 was da bomb, and that 5.4 would be better, but if you get Robert Watson in a choke-hold he'll admit that its going to be the 6.x before they are where they should be now. The truth is that the model they chose for 5.x just plain doesn't work. If you get a charge out of playing follow the bozos, good for you. But I have a car, and when the new model comes out I might test drive it, and if it sucks I'll either keep my old car or buy something else. For now I'm slapping a coat of wax on 4.x and hoping that someone figures it out shortly. I chose freeBSD initially over linux not because there's a bunch of good guys on the project, but because it was good. I'll stick with 4.x for the same reasons. Personally I think its going to be a long, long time before FreeBSD is any good anymore. And I don't have that kind of time. The entire point of the project is to improve SMP performance, and several years in its worse than it was before. What evidience is there that there is an end to this ridiculous tunnel? -Original Message- Hello, On Fri, 18 Mar 2005 22:16:05 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -Original Message- From: Nick Pavlica [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Fri, 18 Mar 2005 19:45:44 -0700 Subject: Re: FreeBSD 4.x Opteron Question :em1897, : I'm curious how you are testing. In my testing, the 5.4 pre IP :stack performed very well. I was able to get 100% more throughput
Re: FreeBSD 4.x Opteron Question
:Boris, : I would agree that my initial impression of 5.3 was that it was slow :compared to 4.x. After some tuning, I now have 5.3 running at an :acceptable performance level. You may want to start testing the newer :versions of 5 current. I have noticed improved performance on my test :servers and believe that 5.4 will demonstrate an improvement in :performance. I know that the guys on the performance list would like :to get some good feedback if you find any specific bottlenecks with it :as well. : :--Nick FYI, I recently testing bridging/network performance on 5.4-pre and its about the same as 5.3: 25 to 30% more CPU load for the same traffic levels than 4.x. SMP drops packets at about 60% load and seems to have a lower capacity than UP. I'm sure some things are faster, but networking is a large component for most people I think. Threaded network stacks just don't seem to perform well, certainly not on UP. Linux MP works much better, but with 2 CPUs it has the capacity of FreeBSD 4.x with 1. So its hard to justify. FWIW, its quite a bit better with UP than DragonFLY, but dragonfly is much better with 2 processors. On Wed, 16 Mar 2005 14:51:43 -0800 (PST), Boris Spirialitious [EMAIL PROTECTED] wrote: --- cyb [EMAIL PROTECTED] wrote: http://www.freebsd.org/platforms/amd64.html Looks like you will need to use 5.3-release (or 5.3-stable/5.4-prerelease if you have more than 4GB). Why can you not use 5.3? 5.3 is too slow, and we have custom code. Why use faster hardware just to use slower version of O/S? Please don't start with flames. This is what I feel. I don't need so much RAM, so 4.x will work with 1 or 2GB of RAM? Boris On Wed, 2005-03-16 at 09:43 -0800, Boris Spirialitious wrote: --- Boris Spirialitious [EMAIL PROTECTED] wrote: When opteron support start for Freebsd? I have 4.9. is supported? Or 4.11 better? I can't use 5.x. Will a i386 disk boot on opteron system? Can I use same disk image for intel and amd MBs? Any big problems? Thanks, Boris Does anyone know answer please? Someone must use Opteron here Boris -- GnuPG key : 0xD25FCC81 | http://cyb.websimplex.de/pubkey.asc Fingerprint: D182 6F22 7EEC DD4C 0F6E 564C 691B 0372 D25F CC81 __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x Opteron Question
-Original Message- From: Nick Pavlica [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Fri, 18 Mar 2005 19:45:44 -0700 Subject: Re: FreeBSD 4.x Opteron Question :em1897, : I'm curious how you are testing. In my testing, the 5.4 pre IP :stack performed very well. I was able to get 100% more throughput :than Linux (2.6.10 FC3) under heavy load on the exact same hardware. :I was actually surprised at the difference because I have been a Linux :Zellot for years. I didn't see any packet loss in my tests, but I do :have good quality networking gear and servers. I was happy enough :after my testing that I'm going to move my 4.x servers to 5.4 when :it's released. I haven't tested dragonfly yet, but get all the :performance I need out of FreeBSD. : :--Nick on a side note, I thought top posting was a no-no? I see gmail has the same issues as AOL. Or are the issues with the old farts with their newsreaders? :-) I don't get your logic. You are converting your servers from 4.x to 5.4 because you've found that 5.4 is faster than linux? Is that some sort of riddle? FreeBSD has always been faster than linux; I'm comparing FreeBSD 4.x to 5.4, so I'm not sure what linux has to do with anything here. What you can get in terms of throughput doesn't always give you the right answer. My tests measure kernel performance; as I'm interested in routing/packet-processing performance. Sockets add a tricky variable. But I take the IP stack out of the equation altogether by bridging packets through a box, and I prefer to use a 50% load as timings sometimes change when you start to saturate things unnaturally. You won't be running your machine at 100% load, so it makes no sense to test it that way. For the latest test I have a 3.06Ghz xeon bridging 486,000pps. For FreeBSD 4.9, this is a 50% load. The load under 5.4 is 65%. It tests interrupt and process switching performance, which for a networking device is a key performance indicator. (I think) that the 5.4 kernel is threaded, so there are latencies that are very difficult to overcome. Linux has been threaded for a long time, and always has been a poor Uniprocessor performer. 5.4 is better than linux with one processor, but if you are UP then 4.x is clearly the way to go. Linux kills 5.4 with dual processors; in fact 5.4 seems to have higher network performance with 1 processor than 2. They still have a lot of issues to work out. DragonflyBSD has done a nice job with MP, but their performance is still a work in progress. For UP, their performance is dismal so its not quite where it needs to be, but its promising. I just wish that they had done a 64-bit version of 4.x. Because at the moment it seems that there is no way to utilize the opteron fully without having to use a slow version of the OS, which negates the gains. Its a real shame. On Fri, 18 Mar 2005 18:55:14 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: :Boris, : I would agree that my initial impression of 5.3 was that it was slow :compared to 4.x. After some tuning, I now have 5.3 running at an :acceptable performance level. You may want to start testing the newer :versions of 5 current. I have noticed improved performance on my test :servers and believe that 5.4 will demonstrate an improvement in :performance. I know that the guys on the performance list would like :to get some good feedback if you find any specific bottlenecks with it :as well. : :--Nick FYI, I recently testing bridging/network performance on 5.4-pre and its about the same as 5.3: 25 to 30% more CPU load for the same traffic levels than 4.x. SMP drops packets at about 60% load and seems to have a lower capacity than UP. I'm sure some things are faster, but networking is a large component for most people I think. Threaded network stacks just don't seem to perform well, certainly not on UP. Linux MP works much better, but with 2 CPUs it has the capacity of FreeBSD 4.x with 1. So its hard to justify. FWIW, its quite a bit better with UP than DragonFLY, but dragonfly is much better with 2 processors. On Wed, 16 Mar 2005 14:51:43 -0800 (PST), Boris Spirialitious [EMAIL PROTECTED] wrote: --- cyb [EMAIL PROTECTED] wrote: http://www.freebsd.org/platforms/amd64.html Looks like you will need to use 5.3-release (or 5.3-stable/5.4-prerelease if you have more than 4GB). Why can you not use 5.3? 5.3 is too slow, and we have custom code. Why use faster hardware just to use slower version of O/S? Please don't start with flames. This is what I feel. I don't need so much RAM, so 4.x will work with 1 or 2GB of RAM? Boris On Wed, 2005-03-16 at 09:43 -0800, Boris Spirialitious wrote: --- Boris Spirialitious [EMAIL PROTECTED] wrote: When opteron support start for Freebsd? I have 4.9. is supported? Or 4.11 better? I can't use 5.x. Will a i386 disk boot on opteron system? Can I use same disk image for intel and amd MBs? Any big
