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