| • |
|
|
|
|||
|
||||
The IDD had many changes in the last couple of months. I have taken over the helm of the IDD management after two year break in which I developed decoders and provided Web type support duties. A few LDM sites have been connected to the vBNS backbone, new LDM relays sites, rearrangement of leaf nodes for better data reception, new LDM sites, Profiler data feed distribution, and additional statistical information available about sites. These new developments have made IDD management more active.
The most significant development has been the connection of LDM sites to the vBNS backbone. In theory, a vBNS site can handle more connections than a non-vBNS site. (So far 15 connections has been tested but seven of the connections have been to UCAR internal nodes.) If testing proves the theory true, then the routing topology can have a broader fan-out, which might result in better data reception due to the reduction in the number of nodes the data must pass through. At this time there are nine sites connected to the vBNS and three other connections pending. When the pending sites are connected there will be a vBNS site in each major area of the country. Currently we do not have a site in the north west or the south east part of the country. Of course, the top tier routing rearrangement is still in progress. As a side note, this routing topology could be used for NOAAport too.
In terms of IDD configuration, the vBNS sites have been moved up to top tier of relay nodes with the data sources being SSEC Wisconsin for McIDAS and UCAR for FOS. UCAR was placed as the source because Alden is not directly connected to the vBNS but UCAR is directly connected and UCAR has a satellite backup as well. (In reality, the UCAR machine receives data from both the IDD and satellite that results with two thirds of the products being received from the satellite.) The UCAR machine usually has lower latency times than the connection from Alden to Cornell that is only miles apart. The UCAR machine has almost operational support through an agreement with IITA.
Four LDM sites have taken on the responsibility of being relay nodes, three are top tier nodes; one is a second tier relay. This supplied more flexibility to the overall routing topology rearrangement that can designed in more unified manner with closer physical locations as well as good network connections. The closer physical location is important because most of the larger latency times are the result of data crossing different network vendor gateways. As network vendor grow to encompass wider country coverage, this importantance diminishes. The network congestion is still the main problem in the late afternoon hours.
The relay routing topology changes have resulted in better data reception for the leaf nodes. The leaves with poor late afternoon reception now have priority as candidates for new connections. So far there have been ten changes to leaf nodes, but some sites can not get good connection no matter what the configuration. I am working on a algorithm that will produce an optimal routing topology based on the latency times from the LDM statistic data. The fact that there are still sites that do not send in their LDM statistics is a problem I continue to work on.
There have been three new LDM sites since the last report and they are now receiving data. A first time install page was created on the Web to assist these sites in the installation process.
The six-minute Profiler data (feedtype FSL2) is now being distributed over the IDD using the same routing topology as the FOS with the source UCAR. The data stream is about 2 megabytes per hour.
The LDM statistics scripts have been modified to catch information that caused distortions in the charts. This information is usually produced when there are many starts/stops of the LDM or rebooting of the LDM machine. There have been two new Web page entries that permit comparing latency times between two sites and creating a graph that shows the data path to the site from the source. A short term fix for the automatic LDM failover is currently being tested.
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | ||||||
|
||||||
