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

20030527: LDM tune-up request UCLA (portmapper)

James,

> To: address@hidden
> From: James Murakami <address@hidden>
> Subject: Re: 20030522: 20030522: LDM tune-up request UCLA 
> Organization: University of California at Los Angeles

The above message contained the following:

> Steve (Chiswell and Emmerson)
> 
> Well, that explains a lot. On our old sun server (typhoon), we actually
> weren't picking up all nexrad products (most but not all). I originally
> wanted to stay with a SUN workstation for a replacement server (main
> instead of back-up), but our Dept. systems administrator said that some
> PCs could run faster than a workstation. Hence, I initially set the
> feed and processing to all nexrad data.  I totally forgot that I did
> that. I will change the pqact.conf and ldmd.conf to match that on the
> Sun server (after you finish testing).

Good idea.

> I noted earlier in the morning that there was a latency of over 20
> minutes (around 1500 UTC).  I don't think I lost anything though. As of
> 1727 UTC things were caught up.

Good.

> One last question...We still subscribe to WSI mosaic radar (will
> continue until the university stops funding it). When I told WSI to
> change the server connection to sundog, no data came through. The WSI
> contact noted the following:
> 
> > % ldmping sundog.atmos.ucla.edu
> ] > May 01 12:15:45      State    Elapsed Port   Remote_Host           
> rpc_stat
> ] > May 01 12:15:57      NAMED  12.112720    0   sundog.atmos.ucla.edu  can't 
> ] contact portmapper: RPC: Timed out
> ] > May 01 12:16:34      NAMED  12.109902    0   sundog.atmos.ucla.edu  can't 
> ] contact portmapper: RPC: Timed out
> 
> For the time being, radar is being collected by typhoon (old Sun
> server). Do you have any idea why typhoon will receive the data but
> sundog won't allow it? Both machines were set to collect the same types
> of Noaaport data (excepting details of nexrad data).

WSI has it's own version of the LDM that it uses to send data.  It
could be that that version must connect to the rpcbind(1) (formally
"portmapper) daemon in order to establish a connection (ours doesn't
need to).  Executing the command "rpcinfo -p sundog.atmos.ucla.edu" on
our systems indicates that Sundog's rpcbind(1) is unavailable.  Sundog
might not be running rpcbind(1) or it might be behind a firewall that's
not letting through packets destined for port 111.

> Thanks for all the help.
> 
> James

Regards,
Steve Emmerson