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

19990803: no imagery (cont.)

>From: "David J. Travis" <address@hidden>
>Organization: University of Wisconsin-Whitewater
>Keywords: 199907301755.LAA07700 IDD

David,

re: clock is not set
>Even before I went in and reset the clock I noticed that fresh images had
>started coming in around the time that Don had logged in.  So maybe he
>inadvertently fixed the problem (maybe by stopping and restart the LDM?).

Don did stop and restart the LDM, but this will not cure the problem of
your clock being off.  The problem with an incorrect clock setting
is that your system may be:

o asking for data that is older than what is in the upstream sites
  queue
o asking for data that is in the futue

>Anyway, I went ahead and reset the clock and have discussed setting our
>clock via NTP with my Linux assistant.  Should be no problem.  

Good.

>Regarding the imagery problem...I seem to recall that SSEC had a problem
>sending out images for a period around June 25 which just so happened to be
>the day we stopped receiving fresh images.  Even after they fixed their
>problem we still did not get any new images until I contacted you late last
>week.  Is this a coincidence or should I consider rebooting (or stopping
>and starting the LDM) each time after SSEC has an extended problem sending
>out their images?  

I think that a number of things were happening right around that time.
The coincidences were there, but there were so many of them that it is
hard to say exactly what was _the_ cause.

>The reason I'm contacting you about this is that it seems this has happened
>before.  On our OS/2 machine we got into a regular routine of shutting down
>and robooting each time after Madison had an extended problem (one that
>lasted 3-4 hours or more).  Otherwise, we wouldn't receive any imagery
>(even after they fixed the problem at their end).  Thought you might want
>to know...

Unix/Linux systems typically do not need to do this.  Some times, however,
an LDM queue can get corrupted.  At this point, one has to shut down the
LDM, delete the queue, remake the queue, and then restart the LDM.  This
is _not_ a procedure that should be done on a regular basis.  The reason?
When you delete and remake the queue and then restart the LDM with no
special flags, your system requests an hour's worth of data from the
upstream site.  If this is what is wanted, fine; if not, you end up getting
data that may duplicate what you already have on your system.

Tom