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

[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.

> address@hidden ~]$ date
> Tue Jan 17 15:54:31 EST 2012
> address@hidden ~]$ su -
> Password:
> address@hidden ~]# 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
> address@hidden ~]#
> 
> 
> -bash-3.2$ date
> Tue Jan 17 15:54:35 EST 2012
> -bash-3.2$ su -
> Password:
> address@hidden ~]# 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
> address@hidden ~]#

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


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.