20050309: Large latency of met_research3.nchmf.gov.vn

>From: Mai Nguyen <address@hidden>
>Organization: National Center For HydroMeteorological Forecasting, Hanoi, 
>Vietnam
>Keywords: 200503100444.j2A4inv2020321 IDD latency

Hi Mai,

I apologize for not being able to look into your problem before
now, but I was out of town at the end of last week.

>Could you please check for me the reason why our
>machine is so slow in getting data. I've checked on
>the IDD's realtime statistics site and saw our huge
>numbers of seconds in latency plots. Is it meant that 
>our clock is late? or we're late in getting data (for
>example because of slow traffic)?

I just looked at the latency plot for IDS|DDPLUS data and see
that the large latencies you were experiencing (varying around
12000 seconds) disappeared at about 4 UTC this morning.  Did
someone at your site make any networking changes today?  We
have not made any changes on our end, so whatever improvement you
are seeing is a direct result of some change between the
machine you are feeding from (currently idd.unidata.ucar.edu)
and your institution.

>We've put the timeupdating calls to
>timeserver.unidata.ucar.edu (which is
>zero.unidata.ucar.edu) in crontab every 15min.

Your clock being off (if it was) would not have caused
the large latencies you were seeing, but getting the
clock right is an important thing to do.  Since we first
talked we have come to the conclusion that it is much better
to set clocks using the NTP daemon, ntpd.  Setting the clock
every 'n' minutes using ntpdate is not sufficient when lots
of data is being ingested.  Since you are not ingesting
lots of data, I would say that changing from ntpdate to
ntpd is not imminently crutial, but it is something that
you should do in the coming days/weeks.

>Also we've noticed in ldm.log that we always can't
>connect to the server: atm.geo.nsf.gov. May we try
>another feeding node?

The commodity Internet connection to atm.geo.nsf.gov has
been configured to not allow LDM/IDD traffic.  This was done
to prevent the IDD from consuming all of the bandwidth available
when the NSF Internet2 link goes down.  If a 'traceroute' from
your machine to atm.geo.nsf.gov does not use the Internet2,
then you must feed from a different machine; we suggest you
continue using idd.unidata.ucar.edu AND remove all request
lines to atm.geo.nsf.gov from your ~ldm/etc/ldmd.conf file.
Please remember that after making any modification to ldmd.conf,
you have to stop and restart the ldm for the changes to take
effect:

<as 'ldm'>
ldmadmin stop
ldmadmin start

 -- or --

ldmadmin restart

>Thank you in advance and hope to hear from you soon.

It was good to hear from you.  Too bad our communication was
caused by a problem :-)

>Best regards, Mai
>*************************
>Nguyen Chi Mai
>Research & Application Divison
>National Center For HydroMeteorological Forecasting
>4 Dang Thai Than str., Hoan kiem, Hanoi, Vietnam
>Tel.: +84 4 9333130
>Fax.: +84 4 8254278
>Email: address@hidden

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.