[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HELP

Christina A Ostrander wrote:
> 
> Anne,
> I will define local to be what hardware/software is located at the radar 
> site.  The
> machine would be for relay, only.  Local will host LDM and BZIP residing on a
> dedicated machine, independent of keyboard and display. Intermediary I'll use 
> to
> refer to what hardware/software is located inbetween the radar and NCDC 
> located in
> Ashville, NC, where multiple radars are bringing in data to be passed on to 
> the
> network and/or provided to real time users. Termination I will define as NCDC 
> located
> in Ashville, NC.
> 
> To my knowledge no one has completed a network analysis based on actual 
> traffic
> measurements. I plan to perform a network analysis, but we don't have links 
> in place
> across all the regions right now.  Today, its looks like there is only a 
> small amount
> of data to be passed on per site.  One file/site is being received at the 
> termination
> point, NCDC, about every 20 seconds and the files on average are about 
> 10KBytes.
> 
> For the 120 NWS radar sites, it works out to be 480Kbits/second.  This is 
> today's
> average.  For 158 total radars (long term planning) it works out to be about
> 650Kbits/second. So, if I look at potentially the worst case intermediary
> requirement, a hub connected to 24 sites, (Tulsa, Little Rock, Memphis, 
> Shreveport,
> Lake Charles, Houston, Austin, Dallas/ForthWorth, Corpus Christi, Midland, San
> Angelo, Brownsville, Amarillo, Lubbock, Pueblo, Goodland, Topeka, Dodge City,
> Wichita, Cannon AFB, Holloman, El Paso, Dyess AFB, Vance AFB, Laughlin AFB) 
> we're
> looking at a pass through of 96Kbits/second.  Since we haven't hit storm 
> season, I
> expect the 96Kbits/second to be a min rather than a max, but again, I haven't 
> taken
> actual measurements, yet.
> 
> Currently, if I were to design a network based on what the NWS already has in 
> place,
> the max number of intermediary equipment locations would be 12.  Otherwise, 
> if I was
> to design a network based on what Kelvin Droegemeir has previously 
> documented, the
> maximum number of intermediary equipment locations  would be 7 .
> If we look at 12 intermediary locations, using the NWS (AWIPS) NETWORK, we're 
> looking
> at intermediary equipment at:  Kansas City, Fort Worth, Tulsa, Salt Lake City,
> Sacramento, Portland, Minneapolis, New Orleans, Cincinnati, State College, 
> Boston,
> Atlanta
> If we look at 7 intermediary locations, using Kelvin's documentation and the 
> Abilene
> NETWORK, we're looking at intermediary equipment at:  Oklahoma City or Tulsa, 
> Denver,
> Seattle, Los Angeles, Atlanta, Chicago, Pittsburg.
> 
> In my mind, the local hardware/software at the site will be for relay only.  
> No one
> would not have any access to the local position.  It would be strictly handle,
> compress and pass it on to the intermediary.
> 
> Again, in my mind, the intermediary machine, would ingest multiple radar data 
> sets
> and either 1) pass through for distribution by NCDC) or 2)  provide 
> distribution to a
> specific maximum number of  users including NCDC.  I will ask Jason Levit to 
> tell me
> how many users are obtaining data from CAPs and see if it's a multitude and 
> there's
> no problem.  I do not know if there is a max number of recipients.
> 
> Minimum requirements on local and intermediary hardware/software, is what I'm
> interested in.  Also, if you can tell me which universities and and other 
> users you
> think will want this data, that will be really helpful with the network 
> analysis.
> 
> Thank you very much.
> 
> Christina

Hi Christina,

The factors that we use in determining what an ldm can handle include
the number of products, plus the number of incoming feeds and the number
of outgoing feeds.

Your current volume sounds relatively low.  With a low cost Intel box we
think you would have no trouble distributing products from ten to
fifteen radars.  For example, if a hub handles 15 radars and each site
sends a 10,000 byte product every 20 seconds, the LDM has to handle
15*(3600/20) = 2700 products/hour and 2700*10000 = 27 Mbytes/hour. 
These are both small compared with what we can handle on our desktop
machines now, which is why we think a cheap desktop machine will work.

If you were to feed 24 other sites, that's a relatively high number. 
One of our main servers (motherlode.ucar.edu) feeds about that many
sites, plus running a bunch of decoders and doing lots of other work,
but it's an exceptionally powerful machine.  If you want to stay with
low cost hardware, I suggest trimming down the number of outgoing
feeds.  This is an estimate, but I'd say most of our small sites feed
three to six other sites.  But, they are also often running decoders,
which are much greater CPU hogs than the LDM.  The LDM is pretty
efficient with respect to CPU usuage.  Usually, disk speed is the
limiting factor.  The fact that you will not be using the machines for
anything else but relaying the data, and that you will not be filing the
data, will keep your hardware needs low.  

We'd recommend running Solaris.  Linux is a possibility, but Solaris
seems more stable, more secure, easier to administer and is low cost (or
free) for educational sites.

How long do you want to be able to keep the data?  That will affect how
big you should make your product queue, and thus how much memory you
need.   The 27Mbyte/hour rate calculated above is small - many sites
keep 300 - 500Mbytes/hour.  We tell sites they can get by with 128Mbytes
of RAM, but I would recommend more for you especially if you expect the
network and volume of data to grow.  I'd say get a minimum of 256Mbytes.

Regarding who is interested in the data, we're thinking that to start
maybe 15 of our universities would want it.  I would expect that number
to grow as people learn more about the data.  Also, there are several
groups here at NCAR that will likely be interested, along with groups at
FSL, NRL, and Lincoln Labs.

Hope this helps.  Let me know if I can provide further information for
you.

Anne

-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************