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.
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.
On Wednesday 02 April 2003 00:58 am, Gilbert Sebenste wrote: >> deletia >> > OK. So in 2 1/2 years, they could conceivably crank the speed of NOAAport > up to 20 times what it is now. But that is not the plan . . . the plan is to go to 7.5Mbit on a single DVBs channel . . . roughly twice the current bandwidth. The issue is that the technology we have pushed for NOAA to consider has not been adopted by the "ip-via-satellite" community . . . i.e. TPC. This leaves NOAA to play with current DVBs technology which is based on RS Forward Error Correction (FEC). If this is all greek to anyone reading . . . you can stop reading here and hit the delete key. What does this mean? With TPC (Turbo Codec, designed by AHA), a 7.5Mbit satellite throughput would nearly be 7.5Mbit/s. On RS . . . closer to 6Mbit/s, and you still have to use a larger reflector. The potential to use a smaller reflector . . . i.e. 6' or smaller . . . has obvious benefits. What this latest news more importantly illustrates is that we have some very good technical people at NOAA . . . Phil Cragg, David Helms, etc. . . . that recognize the cost benefit of the SBN over landline ($80k/year for the SBN maintenance versus $4.3million/year just to sponsor the existing internet/FTP data access storage maintenance). Moving from the current split-half-transponder SBN to DVBs with more bandwidth will actually lower the SBN maintenance even more. There is no comparison to the cost to maintain landline facilties with bandwidths like Internet II versus an SBN with up to 52Mbit/s (theoretical) of _unshared_ bandwidth. Some very intelligent people have been guilty of not recognizing the difference between a 20Mbit/s dedicated pipe vs. a 100Mbit/s pipe shared with every music and movie lover on the internet. > Yeah, yeah, I know. This certainly > won't be perfect and you know some of this will be delayed. Still, > it's now not a matter of if...but of when. And, there's no way we (NIU) > could allow that sort of a feed through our current Internet pipeline. And that's the whole point of the SBN . . . so that facilities can receive massive amounts of operational and research data without the bandwidth and share limitations of landline technology. The near-perfect solution would be a pairing of pull-technology via landline (like the IDD/CONDUIT/EMWIN-internet) with push technology (like proprietary weather data vendors, NOAAPort, EMWIN-Wefax). The power of LDM is inherit in this ability to "pull" only what you need . . . while using an SBN to receive "it all" so you can look at new data as needed. Doing a "request ANY" may need to be disabled ;-) > Then, how can the machines handle it? In less than two years, all the > text products get zlib compressed. How are we going to handle that > through the LDM, making them uncompress on the fly, perhaps? Will we need > a Pentium 7 to handle it? Will we all need our own receivers? The relative cost of a PCI DVBs card vs. the currently needed EFData SDR-54A is what really pushes this . . . a DVBs card, such as ones we work with, run $120/card. This is compared to the $2,750.00/satellite receiver for the current implementation . . . and that doesn't include the RS422/EIA530 serial card to receive the data from the satellite data-out. So, needing your own receiver will suddenly not become a bank-busting effort. Include the fact that if a vendor picks up TPC instead of RS FEC, that reflector installation becomes less of an issue . . . moving from 3m to 3.7m installations to 2.1m and smaller reflectors filling the bill. Tests with TPC, at 10Mbit and nominal RF budget (signal strength), were conducted using 4' antenna with 0 packet loss. And on to the compress via zlib . . . .zlib has very little overhead on the decompression side of things. For over two years, we've tested and have enabled both zlib and bzip2 compression for NOAAPort data downstream to help overcome landline bandwidth issues. The zlib compression has a lite overhead on the compression side (~2% . . . depending on packet size) . . . and virtually no overhead on decompression (~0.4%). This compares very well to bzip2 (~32% on the compression side, ~4% on the decompression side) . . . yet bzip2 is already well handled via LDM with CRAFT and NEXRAD level II data. Someone at a WFO can confirm this for me, but I don't believe the Linux workstation used on the RPG for those sites to inject the level II for CRAFT are very big at all . . . mono-CPU PII and PIII's. Anyway, just some clarification to dispell any FUD . . . this is a good thing . . . a very good thing. -- Stonie Cooper Planetary Data, Incorporated (402) 782-6611/(770) 713-6763
ldm-users archives: