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
