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

Re: a couple of questions

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: a couple of questions
  • Date: Thu, 23 Sep 1999 13:20:25 -0600 (MDT)
On Thu, 23 Sep 1999, tomw wrote:

> Hi Rob:
> 
> I've been reading over your LDM/IDD/NOAAport report in prep for
> the User Comm meeting next week, and was hoping you could clarify
> a couple of items:
> 
> - for the UPC NOAAport receiver system:
>      - how much data is being "lost"?
Tom,

At this time none, our NOAAport card is now on a seperate machine verses
being on the same machine as the SSEC system.  I think both systems were
fighting for the same resources, that being eliminated the UPC card is
receiving all the data.  The UPC card does a direct insertion of the data
into the LDM verses writing to intermediate spool files as SSEC system
does. 



>      - are you decoding the data on the same machine?
> 
No, UPC doesn't decode the data on either the UPC ingest or the SSEC
ingest machines.


> - you mentioned a "new LDM architecture" to make the LDM scale
>   better.  Is there more background information I can read
>   on this issue? 

Our tests discovered that the LDM queue size over 1.5 gigabytes was having
trouble in queue maintenance. At this time, Russ is rewriting the the pq
library routines to solve the problem. This will make the LDM scale better
but is not a new achitecture.


 And is the conversion into Java seen as an
>   opportunity to do that...or as a separate issue?
> 
Currently the LDM consists of multiple co-operating processes that
interact with the LDM queue. If the LDM was rewritten in java, then it
problably be one server process with threads working on the queue. This
would eliminate the queue locking code needed by the co-operating
processes.  At this time, nothing is certain. Looking to the future.

Robb...



> Thanks!
> 
> tom
> 
> -- 
> Tom Whittaker (address@hidden)
> University of Wisconsin-Madison
> Space Science and Engineering Center
> Phone/VoiceMail: 608/262-2759
> Fax: 608/263-6738
> 

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