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

Re: 20011008: IDD latencies at PSU (cont.)

"Arthur A. Person" wrote:
> 
> My
> conclusion is that NMC2 cannot be fed on the same socket as anything else
> or they will both suffer.
> 

Yes, this sounds true.

> I don't entirely understand why the above should be the case.  The
> immediate conclusion might be that there are too many products/time for
> the network turnaround latencies on the socket.  If this were the case I
> would expect to see delays in all the data arriving through that socket.
> Last evening, however, I seemed to notice that when both were on the same
> socket, NMC2 was only running a few minutes behind (comparing notifyme's
> from motherlode with ldmadmin watch's here) but the DDPLUS stuff fell to
> ~15 minutes behind.  If things were sent serially in time from the product
> queue on the same socket, I guess I would have expected to see similar
> delays on both.  Not knowing the internals of the LDM, this makes me think
> the LDM is somehow round-robining feed stream requests and somehow the
> DDPLUS|IDS|HDS stuff is not getting into the feed hopper as much as NMC2.
> Without further investigation, I don't know how to explain the
> discrepancy, unless my observation of delays in transmission was a fluke.
> 

I would also suspect products/time, and more specifically, blocks/time. 
The LDM breaks large products into 16K blocks.  Each 16K block requires
an RPC call.  The large NMC2 volumes will result in lots of RPC calls,
and, as I showed in an earlier message, there are only so many RPC calls
you can shove through a connection.  And, if the quality of the
connection is varying, the backup can grow.

However, I don't understand either why the NMC2 data was timely while
the WMO data wasn't when you were requesting both via the same socket,
i.e., the request lines were *not* broken into one using FQDN and the
other using IP address.  My understanding is that that the LDM does
indeed transmit products in the order they were received. If you happen
to see that again, I'd like to log in and take a look.

> Whatever the case, it would seem that a capability in the LDM to put
> requests from a single machine on different sockets would be useful,
> formallizing the backhanded approach of using name/IP address.  Something
> like motherlode.ucar.edu:0, motherlode.ucar.edu:1, etc... like the X
> window system does for displays.
> 

Yes, there are so many improvements we could make to the LDM.  However,
our resources are so limited that the difficult choice we have to make
is whether to continue to prop up this version of the LDM, or take the
time to develop the next version. 


> I'll continue to watch the streams and see how things do.  FYI, here are
> the stats for NMC2 data for the last several days on ldm.meteo showing the
> improvement last evening (assuming the NMC2 feed itself didn't improve
> coincidentally):
> 
...

I believe the NMC2 feed did improve during the day yesterday.  And, as I
said yesterday, it had degraded sometime last week, so your stats would
reflect that.


> 
> At this point only ldm.meteo.psu.edu should be feeding from motherlode.
> Jeff has turned off nutone.  Let me know if you still need me to switch
> ldm.meteo to flood for the NMC2 feed.  Is flood a top level feed source?
> My only concern with a switch would be getting too far down the chain
> which would potentially introduce more points of congestion/delay for our
> feed.
> 
>                                      Thanks.
> 
>                                        Art.

I'll leave that choice of feeding from flood to Steve.  I understand
that flood is a top level source for the NMC2 feed.  In the meantime,
I'll remove the allows for nutone from motherlode.

Well, I'm glad things are working better, and you were able to identify
the router problem anyway.  And, we now have further verification of the
difficulty of merging the NMC2 feed with other feeds.  It was good to
test the routing through nutone to confirm this.  I think we've learned
a few things...

Anne 

-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************