NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: "Bret D. Whissel" <address@hidden> >Organization: FSU >Keywords: 200309300045.h8U0jvk1023216 IDD LDM upgrade Hi Bret, >Thanks for the info, Tom. I've changed the connections, Thanks! I see that pluto is now pointing at idd.nrcc.cornell.edu for the feeds it was requesting from squall.atmos.uiuc.edu. The three machines that were incorrectly feeding from squall are now pointed at other relay nodes, so David can remove the allows on squall without affecting anyone's data feeds. >and I'll upgrade pluto.met as soon as I have a chance. OK. We will be able to see the change as soon as the upgrade is complete and you have stopped and restarted your LDM. For reference, we monitor your real time stats online at: Real time stats site list http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml pluto.met.fsu.edu http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml?pluto.met.fsu.edu >We have also been feeding >from idd.nrcc.cornell.edu, but they seem to have had several outages of >late. You can feed from flood.atmos.uiuc.edu. It has been performing well for an extended period of time (outside of a minor clock drift that has been fixed). >We typically split feeds so that WMO comes from Cornell, and FSL2 >& MCIDAS from UIUC. OK. Another approach possible with LDM-6 is to setup PRIMARY and ALTERNATE feed requests. Here is a simple example: request WMO ".*" flood.atmos.uiuc.edu PRIMARY request WMO ".*" idd.nrcc.cornell.edu ALTERNATE and so on. The difference between a PRIMARY and ALTERNATE feed request is the PRIMARY request tells the upstream LDM to simply send the products requested as soon as it has them. The ALTERNATE request tells the upstream to ask if a product is wanted before it is sent. If the answer is yes, then the entire product is sent in one transacdtion. The ALTERNATE request is somewhat like that employed in LDM-5, but there, products larger than 16KB were split up into a number of 16 KB chunks and each of those were sent using a blocking RPC call. LDM-6's method of semi-LDM-5 delivery is much more efficient than LDM-5 was. Its LDM-6 PRIMARY deliver is _WAY_ more efficient than either LDM-5 or the ALTERNATE mode delivery. The best indication of this assertion is the latest stress test we ran on the top level IDD node, thelma.ucar.edu. We were able to relay 1.4 TB/day sustained over the last two days of the test. Peak (unsustained) rates reached 2.8 TB/day and we routinely exceeded a 2.2 TB/day rate. >I inherited our ldmd.conf without an authoritative >history of what our connections should be. If you have other info about >how we are supposed to be connected, I'd love to have it! For now, keep feeding from flood.atmos.uiuc and idd.nrcc.cornell.edu. As the reorganization of the IDD progresses, we will likely be asking you to change your requests to other machines. Stay tuned :-) Thanks for the help! Tom