Ed, You might want to check out the following URL:
http://www.vm.ibm.com/perf/tips/z890.html
A couple random thoughts:
* The new box should have enough extra processor
to make up for the loss of I/O Assist.
* You have enough memory to get around the paging
possibility of V=V.
* You might want
Ed
What level of VSE are you on?
Check the Z890 Buckets for VSE PTF's
We did this same processor migration about 12 months ago. mp3k/h30 to
z890(2086) 160. 210 MIPS is great... We were bale to have both systems on the
floor and operating so the cut over was pretty painless..
We kept our
3) Could you (would you) elaborate on DIMM exploitation? DATA
spaces
Or what else?
For VSE, virtual disk in storage (both in VSE and VM) might
be worth exploring. I'm not familar enough with various VSE
DIM options in terms of buffers and such. And MDC is tied back
to the dedicated DASD
If you check Bustech Inc site, you can install a Netshuttle or a Man and
never more change from OSA to Internal nics or reconfigure OSA when move
again. They are Escon control units and all you will need is to unplug from
escon port in old machine and plug it in new one. Ahhh and of course build a
Hello Eric,
Thanks for the info. I have all the Z890 VSE/ESA bucket ptfs on
and
Being tested (BETA-SYS, TEST, and VSE261 systems). I should be moving
over to PROD soon.
I am more worried about the OSA-Express GbE SX (2 cards for 4
ports) and the OSA-Express 1000Base-T Ethernet
Hello Bodra,
We have a Bus-Tech with the Escon channels working for z/VM and
my Beta-Sys. Still only 100 mb.
More Power, Scotty! We need more power!
Ed Martin
Aultman Health Foundation
330-588-4723
[EMAIL PROTECTED]
ext. 40441
-Original Message-
From: The IBM
Ed,
There are in Bustech site an info about 10/100/1000 MAN and NETSHUTLE
devices.
-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de Edward M. Martin
Enviada em: quinta-feira, 25 de maio de 2006 14:20
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re:
On 5/24/06, Edward M. Martin [EMAIL PROTECTED] wrote:
Could you explain this a little better. please?
Oh, and have a look at what you're using expanded storage for right
now. Make sure not to set MDC not to use expanded storage, but use it
for paging only.
With current 64-bit z/VM in
On 5/24/06, Bill Bitner [EMAIL PROTECTED] wrote:
One of the caveats of using MDC and Xstore is whether your
workload is CMS or VSE based vs. Linux. Many of the traditional
Another big one I learned was that before z/VM 5.2 the code path
caused the virtual machine page go under the bar even
Hello Everyone,
Thank you all for the info about XSTORE, paging, MDC, and the
like.
I would like your opinions on what I am doing planning right now.
We are running a MP3000 with 2gig total, no Xstore defined. One
V=R,
2 V=F, and bunches of V=V machines.
Paging is near
Sounds good to me. But, because of that silly HSA you won't actually have
anything close to 8GB available, it will likely be closer to 7GB. But you're
allocation idea is sound.
On Wednesday 24 May 2006 11:02 am, Edward M. Martin wrote:
Hello Everyone,
Thank you all for the info about
z/VM still uses expanded storage for multi-tiered paging. It is suggested to
allocate expanded storage for a smoother VM paging experience (in the event
VM actually has to do any paging).
On Tuesday 23 May 2006 12:44 pm, Robert Payne wrote:
Since we implemented z/VM 5.2 about a month ago, I
Yes, but since our page rate is 1 I'm wondering if what we
may gain with 8G main would be more than lost during those
rare occasions that it does really have to page to DASD which
in this case is a shark (ESS 2105). Maybe splitting hairs.
Thanks Rich.
-Original Message-
From: The IBM
Title: z/VM 5.2 on z800 with 8G of memory
Since we implemented z/VM 5.2 about a month ago, I changed the memory
configuration to 6G main and 2G xstore. With our typical workload,
the page rate is 1 per second. We run 2 VSE guests normally, but the
last few weeks I've also had a 3rd
On 5/23/06, Robert Payne [EMAIL PROTECTED] wrote:
Yes, but since our page rate is 1 I'm wondering if what we
may gain with 8G main would be more than lost during those
rare occasions that it does really have to page to DASD which
in this case is a shark (ESS 2105). Maybe splitting hairs.
So
I'd be inclined to go with Rich's suggestion. While it's true that your
z/VM isn't paging much now, there will almost certainly come a time when it
will. Rather than suffering erratic response time due to paging directly to
DASD (even the Shark's cache is on the wrong end of the channel cable)
How about a system that is paging with 16G currently divided 12/4 and is
z/VM 5.2. Would it be happier on say 14/2 split? It depends huh...
Whenever I look it seems to be paging at 500 per sec to xstor and
100-500 to DASD.
Marcy Cortes
This message may contain confidential and/or privileged
Thanks for all the replys. It may just be a case of me not
leaving well enough alone :)
I may try 7G main and 1G XSTORE just for grins.
Thanks,
Bubba
On 5/23/06, Marcy Cortes [EMAIL PROTECTED] wrote:
How about a system that is paging with 16G currently divided 12/4 and is
z/VM 5.2. Would it be happier on say 14/2 split? It depends huh...
Whenever I look it seems to be paging at 500 per sec to xstor and
100-500 to DASD.
Most likely your
Since your paging to DASD at that rate, I'd be inclined to say no (more
knowledgable answers may prevail, though). More xstor (10/6, 8/8) may
increase your xstor rate, but will it reduce your DASD rate? (I don't expect
you to answer, that's more of a Marty question).
On Tuesday 23 May 2006
On 5/23/06, Robert Payne [EMAIL PROTECTED] wrote:
I may try 7G main and 1G XSTORE just for grins.
Sure... if you expect stock to go down tomorrow, you only spend half
of your savings to buy some so you will not lose all your money ;-)
Rob
21 matches
Mail list logo
