[McIDAS #IWJ-443798]: MCIDAS Software Upgrade at NGC

Hi Martha,

re:
> I understand what you are saying about time, but both systems
> are running NTPD and are synchronized to the same timeservers

OK, your listings below convince me that the clocks should be
synchronized.

> ldm@noaapnew ~]$ date
> Tue Jan 17 15:54:31 EST 2012
> [ldm@noaapnew ~]$ su -
> Password:
> [root@noaapnew ~]# ntpq -p
> remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> *va026-r-3226-mp 192.5.41.41      2 u  408 1024  377  231.916    3.983
> 8.880
> +ma118-r-1261-mp 192.5.41.41      2 u  418 1024  377  205.773  -25.307
> 19.640
> LOCAL(0)        .LOCL.          10 l   24   64  377    0.000
> 0.000   0.001
> [root@noaapnew ~]#
> 
> 
> -bash-3.2$ date
> Tue Jan 17 15:54:35 EST 2012
> -bash-3.2$ su -
> Password:
> [root@noaapxcd ~]# ntpq -p
> remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> *va026-r-3226-mp 192.5.41.41      2 u  492 1024  377    2.044    3.842
> 0.255
> +ma118-r-1261-mp 192.5.41.41      2 u  481 1024  377   21.060   -3.682
> 0.301
> LOCAL(0)        .LOCL.          10 l   46   64  377    0.000
> 0.000   0.001
> [root@noaapxcd ~]#

re:
> So I don't think it possible for one system to lose its time for some
> long period then catchup because NTPD is polling the servers continually AFAIK

I wasn't thinking that the clocks would get unsynchronized and then synchronize
suddenly.  I was considering the possibility that there was a time difference
between the two that was consistent.  This is the only way that I could make
sense out of the delta(t) being reported in log lines like:

Jan 17 18:41:31 noaapxcd pqact[12612] DEBUG: pq_sequence(): 
time(insert)-time(create): 2920.5981 s

2900 seconds difference between system clocks would account for the delay
in delivery of products when you changed the output directory specification
in the pqact.conf_nnexrad_file pattern-action file.  And yet, that difference
seems to be in the wrong direction.

Hmm... when was the last time that the LDM queue on noaaportxcd was deleted and
remade?

re:
> Randy has said that other data is also stopping them starting,

OK, this is new information for me.

re:
> and we do
> see the RPC errors in the ldmd.log files so I have to think that too is
> an issue.

Yes, the RPC errors are indicative of some sort of a networking problem.

Still some sleuthing to be done!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: IWJ-443798
Department: Support McIDAS
Priority: Normal
Status: Closed