AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080930134610.7c4bb9a2@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.stark@onstor.com>,<warren.gale@onstor.com>,<bill.fisher@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E0BC63677@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 30 Sep 2008 13:46:21 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>, "Bill Fisher"
 <bill.fisher@onstor.com>
Subject: Re: primary vs recovery prom's on cougar SSC
Message-ID: <20080930134621.3121a65b@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0BC63677@onstor-exch02.onstor.net>
References: <48E190D3.3070401@onstor.com>
	<BB375AF679D4A34E9CA8DFA650E2B04E0BC63677@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So in other words, we want both.  We can take what you have now for the
1.0.9 prom "release".  The other method shouldn't take more than a
couple-three more days to implement, if I understand correctly.

On Tue, 30 Sep 2008 10:57:31 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Bill,
> 
> Excellent news.  I would advocate that we take a phased approach --
> take the changes you have now into the next release of PROM and then
> work on the PIO approach.  I suspect that reworking the wdc code will
> take some time, and we have a pending PROM release that we could
> target for the delay loop changes.  A 2x improvement over what we
> have now is a great story.
> 
> 
> Brian
> 
> 
> -----Original Message-----
> From: William Fisher [mailto:bfisher@onstor.com] 
> Sent: Monday, September 29, 2008 7:37 PM
> To: Warren Gale; Brian Stark; Andy Sharp
> Cc: Bill Fisher
> Subject: Re: primary vs recovery prom's on cougar SSC
> 
> Warren Gale wrote:
> 
> >Bill,
> >
> >  Ok we have a blade set up for you to work on.
> >Console port is 
> >   10.1.1.100 2011
> >   There is already an IP set up which is 10.1.1.131
> >  There is a tftpboot server in the lab  which is 10.1.1.189
> >This blade is running from recovery proms.  (sibyte_cg.bin)
> >
> >Copy your file to the tftpboot server   ie 
> >  "scp -p <path to file>/sibyte_cg.bin
> >guest@10.1.1.189:/tftpboot/sibyte_cg.binBF"
> >
> >To upgrade the recovery prom image on SSC
> >  At the ssc prom prompt:
> >   "prom upgrade 10.1.1.189 sibyte_cg.binBF"
> >
> >Then a reboot afterwards.
> >
> >Have Fun.
> >Questions? Ext 3135 or 3511 
> >I have a Dr's appmt @ 3  will be out 2:50 to 3:30.
> >
> >Warren
> >
> >
> >-----Original Message-----
> >From: Brian Stark 
> >Sent: Monday, September 29, 2008 1:58 PM
> >To: William Fisher; Warren Gale
> >Cc: Bill Fisher; Andy Sharp
> >Subject: RE: primary vs recovery prom's on cougar SSC
> >
> >Bill,
> >
> >I just talked with Warren, and he will point you to a machine in the
> >Pleasanton lab that you can use.  Let him know if you have questions
> >with upgrading the PROMs.
> >
> >
> >Brian
> >
> >
> >-----Original Message-----
> >From: William Fisher [mailto:bfisher@onstor.com] 
> >Sent: Monday, September 29, 2008 11:49 AM
> >To: Warren Gale; Brian Stark
> >Cc: Bill Fisher; Andy Sharp
> >Subject: primary vs recovery prom's on cougar SSC
> >
> >Warren:
> >
> >Is the approved algorithm to update the "primary" SSC prom and if
> >that breaks then reboot using the recovery prom?
> >
> >I have added some timing buffers and reduced the wdc spin loop
> >values and would like to try this out.
> >
> >Also, I  need a machine to use, to test this code.
> >Andy's machine is in use and has very old hardware and prom code.
> >
> >Thanks,
> >
> >-- Bill
> >
> >  
> >
> Ok, IU have hacked the various micro-second delay loops timess in the 
> wdc_XXX
> code, which resides in two places.
> 
> It now autoloads in approximately 48 seconds. I measured the average
> time to read a 512 byte sectors from the CF and the values  center 
> around 400 microseconds
> per 512 bytes.
> 
> I also re-ran Warren's load time and the numbers, via a stop watch
> are about 2X
> faster than using the default values of 100-200 microseconds on the 
> delay loops.
> 
> I will rework the load code to add the time values and byte counts.
> 
> I think we are getting closer to the Linux kernel's 2 MB/second from
> the CF using PIO, since that is about 2-3 faster than this scheme.
> 
> If you want to go faster, then we need to ditch the controlled spin
> loops
> and rework the wdc_XXX code to do more PIO's without delay loops.
> 
> How fast do you want to do, maximum hardware speed using PIO's?
> Later,
> 
> -- Bill
> 
> 
