Conference ssag::ask_ssag

You have down-rev console software. I heard of this problem a few months back
and the kzpsc folk told me that this problem with LOOONNNG init times is a
AlphaStation console firmware fix. You may want to post a note in
WRKSYS::ALPHASTATION

roger.

    I double checked the SRM FW to be 6.3-11 (3.8CD). I upgraded to 6.4-3
    from the 3.9CD. No help. All seven of my machines seem to exhibit this
    behavior. KZPSC-XA rev D / Standalone RCU V3.2 / Config util 3.11 /
    SWXCR FW 2.36 / 4mb cache / no battery / "write-thru" mode. Moved a
    second module into the box; no help. Started init & saw following:
    	20 minutes	11% complete
    	60 minutes	21% complete
    	90 minutes	26% complete
    The time seems to lengthen with progression. The led's seem to indicate
    an RTZ is being performed between writes, as opposed to a spiral write.
    This would account for worsening times. I will cross-post in the
    ALPHASTATION notesfile. Systems are PB560 (Alphastation 500/400mhz).
    
    Thank you,
    Dennis

I noticed the additional time needed to initialize a given percentage of a
KZPSC raidset on an Alphaserver 1000A/5/300. The initialization progress was
linear for approximately the first 10%, but then slowed down with (almost)
every percent initialized. (I left after an hour, where the Raid5 with
5 RZ29B-VW's was at about 20-25% done. 4MB cache, write-back enabled)

�tzi

    Are you using a VT terminal as the console, or a graphics terminal?
    If VT, are you running SRLMGR instead of SWXCRMGR? If using a VT and
    SWXCRMGR, you spend a great deal of time 'painting' the screen.
    
              Mark d.

    Very interesting (SRLMGR); I didn't know such a program was available.
    I learned the painful way to use ESC, TAB, & CR, carefully in SWXCRMGR.
    I will try SRLMGR tomorrow. When SWXCRMGR is running the init, it
    "seems" to only be updating the %-done, but perhaps more is happening.
    
    Thank you,
    Dennis

    Dennis,
      I think it only updates the % done, but repaints or respositions to
    each character position on the terminal. I believe using SRLMGR will
    cut the init time substantially.
    
                   Mark d.
    

    The total-time-to-init this two-mamber stripeset did decrease
    slightly under SLRMGR. But only 1 hour or so. It still took over
    20 hours to complete! A new developement ... the customer added a
    third drive to one of these configurations and the new three-member
    stripeset init's in 1 hour ... go figure!
    

    if you enable writethrough prior to the initialization, it will speed
    up the process..  Remember you need to unenable it when completed.
    
    chet

re: 6418.9:

> if you enable write-through prior to the initialization, it will speed
> up the process..  Remember you need to unenable it when completed.

other way around - write-through is the default.  if you enable
write-back, it speeds up the initialization quite a bit. Leave
it set to write-back ONLY if you have a battery back-up unit
installed on the KZESC, KZPSC or KZPAC, or else you're liable
to lose data in event of unexpected power loss.  If no BBU is
installed on the controller, remember to reset to write-through
before you exit the utility. 
 
 

    I'm not familiar with the details, but my understanding is that there's
    an issue with long RAID init times on platforms that use AlphaBIOS vs.
    the original ARC consoles. I know the AlphaServer 4100/4000 is one such
    animal because that's what I work on (SRM console). I believe Corelle
    is another. Not sure about AlphaStations (AlphaBIOS vs ARC).
    
    Perhaps all cases reported in prior replies are due to this AlphaBIOS /
    RCU issue? One of the members of our system integration qual team did
    some experimentation with like HW configs between AlphaServer 2100 and
    the 4100. The 2100 (Sable) uses ARC console. The init time difference
    was huge.
    
    Finally, I believe Matthew Buchman (OLEUM::BUCHMAN) in DECwest got
    ahold of the RCU sources a couple months ago. If I have the story
    correct, he discovered the issue and fixed the problem with a change
    to RCU. Not sure whether Mylex has released a new version with the 
    fix yet. Matt should know..
    
    And, yes, serial versus graphics only adds to the long init times.
    And using write-back will speed up the process. Still, you may want
    to pursue the updated RCU angle if initializing on an AlphaBIOS-based
    platform.

    The Alphastation 500('s) on which I saw this scenario all had
    write-thru caching enabled.As previously stated, I tried both swxcrmgr
    and srlmgr; srl cut perhaps 1/2 hour off the near-24 hour init time.
    I feel I tried write-back caching, but this was some time ago now. I
    have experienced the writeback/writethru-thing before & was aware; I
    just don't remember my attack, now. All I can say is there indeed is a
    HUGE init time with a 2 volume init. I attempted to present this as
    a problem to a storage-architect at a recent symposium, but there 
    seemed little interest. The moral of this story is sell only 3+ vol
    stripesets on a Mylex ... at least for now!
    
    Dennis

    
    
  >  seemed little interest. The moral of this story is sell only 3+ vol
  >  stripesets on a Mylex ... at least for now!
    
    Total nonsense. You will loose sales and/or get dissapointed customers
    for no good reason. We use 8 member stripe sets here all the time!
    
    The moral is NOT to init stripe sets if you do not have the time for it.
    Why bother? Is there any self-repsecting Operating system / Application
    that will allow you to read data from a block it has not previously
    written to? If so, why bother writting zeroes first when no application
    will ever see them (except perhaps after critical OS failure?)
    
    The second moral is to use write-back caching.
    If need be, just use it during the init. (I do not understand 
    why Mylex corp does not simply use WB caching during init whether
    you tell it to or not).
    My advise would actually be to inititialy set up WB caching for
    both the SWXCR INIT and the OS INIT and the first file loads.
    Then when the data is all there, you may or may not want to revert
    back to write thru if you can stand it.
    Just the NEWFS alone will make having WB caching around a little 
    longer worth the reboot.
    
    Hein.