Re: 20020917: CPU & Memory vs. Performance (LDM)

Hi Bunny, 

CPU resources can come into play if you are a relay site and are relaying
data feeds that generate many rpc calls. That increases overhead, that can
be helped by a faster CPU, and we experience this primarily with the
NNEXRAD and IDS|DDPLUS feeds...(many prods/hour).

Other than bandwidth we have hit on most resources needed to run the LDM
efficiently.. :)

Let me know if I can be of any other assistance.

Cheers,

-Jeff
____________________________                  _____________________
Jeff Weber                                    address@hidden
Unidata Support                               PH:303-497-8676 
COMET Case Study Library                      FX:303-497-8690
University Corp for Atmospheric Research      3300 Mitchell Ln
http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
________________________________________      ______________________

On Tue, 17 Sep 2002, Bunny Pfau wrote:

> Jeff--thanks for the confirmation of needing additional
> memory needs.  Actually, I hadn't seen in the archives
> about splitting the feeds--I tried it out on my own, in
> my own, blind fumblings.  THanks for verifying it, though.
> 
> If you know of any other tricks that would/could inprove
> transfer rates--please point me in that direction.
> Seems CPU power really doesn't have much to do with it.
> 
> Bunny Pfau
> -> Date: Tue, 17 Sep 2002 15:59:54 -0600 (MDT)
> -> From: Jeff Weber <address@hidden>
> -> To: Bunny Pfau <address@hidden>
> -> Cc: ldm-support <address@hidden>
> -> Subject: Re: 20020917: CPU & Memory vs. Performance (LDM)
> -> 
> -> Hi Bunny,
> -> 
> -> The optimal amount of memory is slightly larger than your queue.
> -> 
> -> The LDM will run "best" if the entire queue can reside in memory.
> -> 
> -> For example we have a 7GB queue on our feed machine and 8GB of memory.
> -> 
> -> Nice work splitting your feeds, as I am sure you noticed in the archives,
> -> that can increase performance by decreasing latencies.
> -> 
> -> Hope this helps!
> -> 
> -> Cheers,
> -> 
> -> -Jeff
> -> ____________________________                  _____________________
> -> Jeff Weber                                    address@hidden
> -> Unidata Support                               PH:303-497-8676 
> -> COMET Case Study Library                      FX:303-497-8690
> -> University Corp for Atmospheric Research      3300 Mitchell Ln
> -> http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
> -> ________________________________________      ______________________
> -> 
> -> On Tue, 17 Sep 2002, Unidata Support wrote:
> -> 
> -> > 
> -> > ------- Forwarded Message
> -> > 
> -> > >To: address@hidden
> -> > >From: Bunny Pfau <address@hidden>
> -> > >Subject: CPU & Memory vs. Performance (LDM)
> -> > >Organization: UCAR/Unidata
> -> > >Keywords: 200209171959.g8HJxk112107
> -> > 
> -> > 
> -> > Is there a document (I've been searching the UNIDATA web site)
> -> > that deals with suggested CPU, memory amount to help LDM 
> -> > run at its most efficient level?
> -> > 
> -> > I have an upstream server serving our own in-house data to
> -> > a couple of downstream servers---I mainttain them all.
> -> > I'm in the process of trying to squeeze out every last
> -> > ounce of speed I can. 
> -> > 
> -> > I'm on the Solaris 7 platform, on Sun SPARC hardware.
> -> > 
> -> > I increased my setup so that I have THREE downstream clients
> -> > running ldmd and saw that I could increase the data transfer
> -> > rate by doing that..
> -> > 
> -> > I've also read through the email archives, noting in some
> -> > emails that memory is VERY important.
> -> > 
> -> > Say I have my main, upstream server with a 600MB queue,
> -> > at any time finding it to have 400-600MB of data on it..
> -> > What would be the recommended ratio of memory to queue size
> -> > for a Solaris 7 server (currently it has a measley 128MB of
> -> > RAM on it and with three downstream clients requesting data,
> -> > I can get up to an 8.2MB/minute transfer rate).
> -> > 
> -> > Any help or referring me to the place in documentation which
> -> > might be helpful would be great.
> -> > 
> -> > Thanks,
> -> > Bunny
> -> > 
> -> > ---
> -> > 
> -> > Bunny Pfau                      National Center for Atmospheric Research
> -> > address@hidden                  High Altitude Observatory
> -> > tel: 303 497-1555               P.O. Box 3000
> -> > fax: 303 497-1589               Boulder, CO  80307-3000
> -> > 
> -> > 
> -> > 
> -> > 
> -> > 
> -> > 
> -> > ------- End of Forwarded Message
> -> > 
> -> > 
> 
>