Am Mittwoch 06 August 2008 05:59:07 schrieb Michael Folsom:

Also, unless my test results are very wrong there is some differences in the kernel - notably the scheduler and the ability to mange lots of cores.

As md5sum will tell you, the SLES and SLED kernels are binary identical Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

On Wed, Aug 6, 2008 at 12:15 AM, Anders Johansson wrote: Am Mittwoch 06 August 2008 05:59:07 schrieb Michael Folsom:

...

Also, unless my test results are very wrong there is some differences in the kernel - notably the scheduler and the ability to mange lots of cores.

As md5sum will tell you, the SLES and SLED kernels are binary identical

Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

--

On Thu, Aug 7, 2008 at 10:43 AM, Michael Folsom wrote:

Wow - now that's interesting -

Let me explain why I made that statement - I have a Uniwide 3546 with 4 quad core 2.3 GH opterons, 32 gb of ram, and a 3ware 9550sx sata card with 6 500GB sata drives in a level 5 raid.

When I built it with SLES10 x86-64 SP1 (patched to the latest & greatest) I saw lots of i/o issues - the system would simply hang for literally 20 to 30 seconds at a time however when I rebuilt the same box with SLED10 x86-64 SP1 (again the latest & greatest patches) those "hangups" disappeared (note this occurred during the course of a day or two so the kernel release was the same). Since nothing else changed save the type of OS I assumed that there was some diff in some part of the kernel (the scheduler, i/o mgmt, etc-) that caused the problem.

Now I am really perplexed!

Michael

I fixed your top posting so this thread might remain intelligible. Never top post to a mailing list. Hangs of this nature plagued multi-core machines for quite a while. Some users would get them, others not, but it seemed most prevalent in X86_64. I don't see this sort of thing much anymore. The fact that the kernels are identical between SLES and SLED is not really that important, because there are many many settings that can affect operation. Many of these hangs could be attributed to processor internal clocks, and clock-drift between the two cores, and timer sources. Slowly the kernels improved and most of these problems went away. Some of these could be prevented with the "nohpet" boot parameter, which forced the use of alternate timer sources. I still run with nohpet, even tho I have not verified it is even honored or necessary since the last new kernel. Google will reveal thousands of hits on these 30 second freezes, under various names, and all sorts of "try this" solutions are recommended. It was a real mess for a long time and you still occasionally find people posting about it here, so its not totally fixed. -- ----------JSA--------- There are 10 kinds of people in this world, those that can read binary and those that can't. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Sorry for the confusion, yes - you are correct - I first ran SLED on it then changed it to SLES and things improved. Michael On Wed, Aug 6, 2008 at 2:07 PM, John Andersen wrote:

On Tue, Aug 5, 2008 at 8:59 PM, Michael Folsom wrote:

...

I put SLED10 x86-64 of a 4 processor quad core opteron system, i.e. it has 16 cores, and it was a strange experience indeed. Putting SLED10 x86-64 on it helped restore some sanity.

Something's wrong with those two sentences.

Did you mean to say "Putting SLES10 on helped"?

-- ----------JSA--------- There are 10 kinds of people in this world, those that can read binary and those that can't. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org