AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090113201313.66d26a0b@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<jonathan.goldick@onstor.com>,<dl-designreview@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	2779531E7C760D4491C96305019FEEB5176334C548@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 13 Jan 2009 20:14:11 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Jonathan Goldick <jonathan.goldick@onstor.com>
Cc: dl-Design Review <dl-designreview@onstor.com>
Subject: Re: TuxRx Functional Spec
Message-ID: <20090113201411.4080c3aa@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5176334C548@exch1.onstor.net>
References: <20090106152711.76b59d5d@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5176334C548@exch1.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

New versions available here:

http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_spec.pdf

http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_spec.doc

Comments not covered in the changes replied to inline
(section 5. c,d,f):



On Wed, 7 Jan 2009 11:47:32 -0800 Jonathan Goldick
<jonathan.goldick@onstor.com> wrote:

> 1. Section 5:
>   a. How will memory change for the ACPU?  Will we have just as much
> available for NFS/CIFS as before?  Will we get more memory back
> because of increased efficiencies or lose some due to new overheads?

> b. Will core dumps work the same way since now there will also be
> user-space processes that didn't exist in EEE that could also crash?
> Will they still go to the management volume and have the same names
> as before?  Analyzing a Linux core will have a new procedure.

> c. Will the system boot faster/slower/same?

I would say about the same.  It seems to me that the cumulative time
for TXRX image to load and for it to become "ready" is about 20 seconds
(for production build) and I expect it to be about that for TuxRx.

> d. Will we still need to use wd_kick for watchdog support in the ACPU
> or is Linux handling that in a new way?

Really an implementation detail that hasn't been decided yet.
Probably will be based on what gives the best functionality.

> e. Does the ACPU performance profile change now that you are probably
> using the default Linux scheduler instead of our current model of
> polling routines with a maximum number of work items before returning
> to the main loop.  This question edges on design but has an external
> manifestation of performance.

> f. In general, this section has too little detail about what
> workflows will change, especially around diagnostics and support.

Agreed.  I will try to be watchful to update the document as they occur
to me.

> 2. Section 6
> a. I suspect that the UI for rcon and the associated console commands
> will likely change. This will in turn impact diagnostic procedures we
> use in the field. For example, the 'eee' command is how we look at
> memory utilization and that will be completely different in Linux.
> You should say something about these commands, especially ones like
> 'req trace on' which is the debug ACPU command that traces the
> CIFS/NFS states.
> b. Do we have to login to yet another root account, this time for the
> TXRX?
> 
> 3. Section 10, you can probably get a better estimate by how much
> head room is available on the ACPU and FP processors today at maximum
> spec load.  Since your changes will not be increasing their
> performance in the first incarnation, which is a pretty good
> estimator assuming that you are not also changing the useable memory
> and scheduler for the ACPU.
> 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, January 06, 2009 3:27 PM
> To: dl-Design Review
> Subject: RFC: TuxRx Functional Spec
> 
> Please review and comment on the TuxRx Project Functional Spec:
> 
> http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pdf
> 
> http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pages
> 
> Thanks,
> 
> a
