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

20030922: Request for information re: LDM



Janet,

>Date: Mon, 22 Sep 2003 11:46:06 -0600
>From: "Janet S Gibson" <address@hidden>
>Organization: NOAA
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20030919: Re: Request for information re: LDM

The above message contained the following:

> Thanks for all your useful information.
> A few more comments and questions below.
> Janet

> >     1.  What corresponds to a data-product?
> 
> A single beam of radar data.

> >     2.  What size is it?
> 
> 15kb - 256 kb  (mode dependent)

> >     3.  How often are these data-products generated?
> 
> 8 beams/second
> This yields 2.048 MB/sec or 7.5 GB/hour.

I assume that "kb" means "kilobyte" rather than "kilobit" and that MB
means "megabyte" (otherwise the above arithmetic doesn't make sense).

If so, then the maximum data rate parameters are

    About 16.4 megabits per second; and

    8 product per second.

These rates are well within the capability of the LDM.

> >     4.  How good is the communications link between the two computers?
> >         (I suggest running some ftp(1)-based tests).
> 
>  good to inadequate depending upon the location

Well, if the link can't handle the load, then it won't matter what
software you use.

> > A "decoder" would have to exist at the downstream LDM.  It would be
> > responsible for disposing of your data-products, which it would read from
> > standard input.
> 
> What do you mean by a "decoder", and "disposing"?

An LDM decoder is a program that reads a particular type of data from
standard input and disposes of that data in some fashion.  It could
display it, or uncompress it and write it to a file, or store it in a
database.  The LDM system ensures that only the right kind of data is
sent to the decoder -- but the LDM doesn't care what the decoder does
with it.

Sample decoders come with the LDM package.  The LDM package also has
built-in decoders for writing data-products to a file.

> How would this solution compare with a Java RMI based solution which
> pushes data from the instrument to the application via callbacks?

Because the LDM system use asynchronous RPC and Java RMI is synchronous,
the performance of the LDM system could be much, much greater.

> How could the data stream be turned into an active object?

That would be completely up to the decoder.  I can imagine, for example,
a decoder that simply appends the data to a file.  A Java-based
application could be watching the file for more data.  Alternatively,
the decoder could notify the application that more data has arrived.

The decoder could be written in Java.

> > There are no plans for porting the LDM system to Windows.  Depending on
> > the speed of the computer, you could probably run the LDM under a UNIX
> > emulator, however.
> 
> I am being pushed towards a Java based solution and would like to know
> how or if the interface between Java and the RPC code exists (has
> someone already done this with LDM, with examples).

I believe a Java-based RPC package exists (Google should find it).  I
don't know that it's been used with the LDM.

> Hopefully this is not a JNI interface.  Running a UNIX emulator is not
> part of the plan, the solution needs to be native Windows.

> Janet S. Gibson
> 
> N.O.A.A. R/ET6
> 325 Broadway
> Boulder, CO 80305
> 
> phone: 303-497-6148
> fax: 303-497-6181
> email: address@hidden

Regards,
Steve Emmerson