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

Re: 19981223: idd: delayed metars & NOAAPORT (fwd)

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.

  • Subject: Re: 19981223: idd: delayed metars & NOAAPORT (fwd)
  • Date: Mon, 4 Jan 1999 10:11:15 -0700 (MST)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Wed, 23 Dec 1998 16:32:19 -0500 (EST)
From: Tom McDermott <address@hidden>
To: Robb Kambic <address@hidden>
Subject: Re: 19981223: idd: delayed metars & NOAAPORT


On Wed, 23 Dec 1998, Robb Kambic wrote:

> That's a lot of disconnects. It's also the reason for the late data,
> surprizing that your site is not loosing more data. Here's what I think
> what is happening. Before, NOAAport Brockport was almost running close to
> it's network capacity, now it's saturated. That's the reason for the
> disconnect( time outs) and the LDM RECLASS statements. I would contact
> your network people to see if they can arrange a solution and further
> restrict the incoming data.  You also could check the status of your
> machine to see if it cpu loaded, disk loaded, etc.  

I suspected that network capacity might be the problem.  I happen to know
that our campus's bandwidth saturates at certain times.  The last time I
spoke with our network person, he said they were going to be installing a
2nd T1 line, but I don't know when.

I think I can rule out cpu, disk as the problem.  Vortex is a
SparcStation-10 with dual 75-mhz cpus.  The only time the loading
spikes up is when certain of the gempak decoders startup or become
active. The 'disk' the ldm data is written to is a partition striped over
6 physical drives.  Anyways, nothing has changed recently to cause it
except the switch to NOAAPORT.  This would be consistent with your
speculation of a borderline situation pushed way over the edge by
NOAAPORT.

In the meantime, I suppose the best thing we can do until we get more
network capacity would be to keep the NOAAPORT filter in place?

Tom
------------------------------------------------------------------------------
Tom McDermott                           Email: address@hidden
System Administrator                    Phone: (716) 395-5718
Earth Sciences Dept.                    Fax: (716) 395-2416
SUNY College at Brockport