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

20031110: New System at UNI (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20031110: New System at UNI (cont.)
  • Date: Mon, 10 Nov 2003 10:24:25 -0700
>From: "Patrick O'Reilly" <address@hidden>
>Organization: UNI
>Keywords: 200310241337.h9ODbAOb017830 IDD node

Hi Patrick,

>Got the new machine set up.  It has been feeding from our current LDM
>machine and all is well.

Oh how I love to read emails that say "all is well" :-)

>The current machine only gets a subset of the IDD
>feed, though.  Since I want to test this machine's connectivity for relay
>node status, I should get the whole set of IDD products.  I was wondering if
>my request lines now are enough:
>
>request IDS|DDPLUS ".*"
>request HDS ".*"
>request NNEXRAD ".*"
>request NMC3 ".*"
>request MCIDAS ".*"

A few comments here:

- the "primary" name for the NMC3 feed is FNEXRAD.  NMC3 works fine, but
  FNEXRAD is more descriptive

- the "primary" name for the MCIDAS feed is now UNIWISC.  MCIDAS works fine,
  but UNIWISC better represents that the datastream is the Unidata-Wisconsin
  stream

- the feed that has the largest volume of data _by far_ is CONDUIT.  If
  your intention is to stress your setup to see if things keep working
  AND at the same time measure how much usable bandwidth you have, I
  would recommend attempting to ingest all of the CONDUIT data.  The
  best way to do this in a test mode is to do a five-way request split
  of the data from a machine here at the UPC:

request CONDUIT   "[05]$" emo.unidata.ucar.edu
request CONDUIT   "[16]$" emo.unidata.ucar.edu
request CONDUIT   "[27]$" emo.unidata.ucar.edu
request CONDUIT   "[38]$" emo.unidata.ucar.edu
request CONDUIT   "[49]$" emo.unidata.ucar.edu

  Please note that this is _not _ an operational machine, so you will
  not be able to feed from it for any extended length of time.

>or are there other feed types I would need to request?

CONDUIT and CRAFT will stress your system.

>Also, I have used
>the example pqact.conf entries given on Unidata's config pages for GEMPAK,
>NWX and MCIDAS....would these be sufficient to decode the entire set of data
>on the IDD?

If you included all of the patterns used by GEMPAK and McIDAS, including
actions to run the ldm-mcidas decoders, then yes, this should be sufficient.

>I am not requesting any NLDN, CONDUIT, profiler, ACARS or other
>data at this time.

The NLDN data is very low volume, so it won't help stress test your network
connection of IDD node.

>Thanks for the tips!

No worries.

Cheers,

Tom