[Fwd: Re: [Rtibm-dev] [RFC] SLES HZ setting for "soft-realtime"]

[Fwd: Re: [Rtibm-dev] [RFC] SLES HZ setting for "soft-realtime"]

[Nivedita Singhvi]

Mike,

This was Novell's response.  It's not looking good for
HZ=1000 in vanilla SLES train.

If that's the case, what is going to be the customer
impact, from what you can tell?  And for Websphere
Soft Real Time going forward?

thanks,
Nivedita



-------- Original Message --------
Subject: Re: [Rtibm-dev] [RFC] SLES HZ setting for "soft-realtime"
Date: Sat, 27 Jun 2009 15:25:18 +0200
From: Matthias G. Eckermann <mge@novell.com>
Reply-To: marc.ruehrschneck@novell.com, Thomas Staudt <tstaudt@de.ibm.com>, rtibm-dev@forge.novell.com
To: Alex Tsariounov <alext@novell.com>, marc.ruehrschneck@novell.com,  Thomas Staudt <tstaudt@de.ibm.com>
CC: niv@linux.vnet.ibm.com, rtibm-dev <rtibm-dev@forge.novell.com>
References: <4A456A05.5020701@us.ibm.com> <1246063597.6101.68.camel@zuul.thistledown>

Hello Alex and all @IBM,

On 2009-06-26 T 18:46 -0600 Alex Tsariounov wrote:
> On Fri, 2009-06-26 at 17:38 -0700, Darren Hart wrote:
> > IBM has recently announced a beta version of WebSphere
> > Realtime (the rt JVM)  with "soft real-time" support running
> > on 32 and 64 bit x86 platforms with standard enterprise
> > distributions.  It just came to my attention that this
> > product requires either HZ=1000 or NOHZ in order to meet its
> > timing requirements.  As the SLES 10 SP2 kernel has HZ=250,
> > I wanted to raise the issue with the Novell devs and get
> > their take on it.
> > 
> > At this point in the SLES10 life cycle, I assume that a
> > change to HZ=1000 is unlikely and targetting SLES11 as a
> > supported platform would be the preferred course of action.
> > Can someone at Novell please comment?
> > 
> > Note: I understand this is not SLE-RT related, but it is
> > real-time related, and I thought the recipients would know
> > where to best direct this question if this isn't the right
> > place.
> 
> Yes, SLES runs at 250 Hz and it is in fact too late for SLES11
> as it has been released for a while.  
> 
> I can see how it would be advantageous for SLES to support
> WebSphere Soft Realtime however.  So, in this light I've CC'ed
> Matthias Eckermann who is our Product Manager for SLES to get
> his take on the possibility of changing the HZ value that SLES
> is built with and when such a change could possibly be made.

without going into technical details today to much, please let
me introduce Marc Rührschneck (Technical Accound Manager for IBM
with Novell) and Thomas Staudt (LTC Distro Architect for
Novell/SUSE with IBM). All communication regarding feature
requests for SUSE Linux Enterprise should be coordinated by
Thomas and Marc.

According to the rules we jointly (IBM and Novell) have in place for
SUSE Linux Enterprise (Marc and Thomas, please jump in here with
explaining those rules to the teams!), and looking at the negative
impact (mainly regarding throughput) other (non-Novell) Linux Systems
are suffering from with their switch to HZ=1000, HZ=250 will remain
for SUSE Linux Enterprise Server 11 also with SP 1 and later in the
default kernel, as far as I can say. ( But we have enable CONFIG_NO_HZ
in SLES 11 - isn't that sufficient? )

so long -
	MgE

-- 
Matthias G. Eckermann
Senior Product Manager - SUSE® Linux Enterprise  - Server Product Line
Phone: +49 30 44315731 - Mobile: +49 179 2949448 - E-Mail: mge@novell.com
SUSE  LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
_______________________________________________
rtibm-dev mailing list
rtibm-dev@forge.novell.com
http://forge.novell.com/mailman/listinfo/rtibm-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Fwd: Re: [Rtibm-dev] [RFC] SLES HZ setting for "soft-realtime"]

[Nivedita Singhvi]

Nivedita Singhvi wrote:
> Mike,
> 
> This was Novell's response.  It's not looking good for
> HZ=1000 in vanilla SLES train.

EEEEEK!!

I beg your pardon, this was meant to go to another
mailing list altogether, as you might guess.

thanks,
Nivedita (sigh)...