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

20050518: ULM IDD latency

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: 20050518: ULM IDD latency
  • Date: Wed, 18 May 2005 15:38:53 -0600
>From: "Adam Taylor" <address@hidden>
>Organization: ULM
>Keywords: 200505182044.j4IKirP3020384 IDD latency

Hi Adam,

>Here at ULM (tornado.geos.ulm.edu) I have noticed for quite a while that
>were are no longer feeding from seistan.lrcc.lsu.edu.

The IDD relay machine at LSU was changed from seistan.srcc.lsu.edu
to pavan.srcc.lsu.edu a couple/three months back.  An announcement
was sent to ldm-users about the change, but it sounds like you
did not see it.

>Currently we are
>feeding from stokes.metr.ou.edu which is listed as our backup site in our
>ldmd.conf.  Our latency is horrible on all products coming in from them and
>has been for quite some time.

Try feeding from pavan.  First, make sure that you are enabled to feed
from pavan:

<as 'ldm'>

ldmping pavan.srcc.lsu.edu
notifyme -vxl- -f ANY -o 600 -h pavan.srcc.lsu.edu

If you get a listing of data that pavan is receiving, then you are
allowed to feed from it.

>I did a ping test for about an hours and got
>a 0% drop rate so I don't think it is the network.

A 'ping' is a good test to see if a machine is reachable by Ethernet,
but it is a bad test to see if you can move data through your
connection.  The classic example of when this is true is when there
is packet shaping being done on the local/campus network.

>Could you guys look into
>it and see what might be going on.  I already rebooted tornado and it didn't
>help any.

I would try switching to feed from pavan to see if that improves
the situation.  Before you do, however, I would review your
~ldm/etc/ldmd.conf entries.  The reason I say this is that I see
that you have requests to stokes for IDS|DDPLUS, HDS, and WMO.
WMO is a compound feedtype that should translate into the union
of products from IDS|DDPLUS and HDS.  Since your real time stats
are showing a feed of WMO, it must be the case that stokes is
creating a WMO feed that is no the "standard" IDD WMO feed.
Since we don't know what is in stoke's WMO feed, it is better
to turn off its request.

As soon as you can try feeding from pavan, I will have a better
idea if the problems being seen are at or near ULM or at or near
OU.

>Thanks

No worries.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.