FBO's and WiFi

http://www.orderdsl.net/satellite.htm
How well do these systems work?

2-way satellite "high speed" internet access.

Anyone with experience with these systems? Hidden costs?

Looks like a good $99 month solution - if it works.

--
Montblack

"Montblack" wrote...
http://www.orderdsl.net/satellite.htm
How well do these systems work?

2-way satellite "high speed" internet access.

Anyone with experience with these systems? Hidden costs?

Looks like a good $99 month solution - if it works.

500ms ping time minimum... So count on lots of lag...

Some don't network very well...

None will work when it rains hard or the sun is in transit (summer / winter
soltice)...

All end up with more customers than they can actually support (whether it be
on the transponders, gateways or internet bandwidth)...

They all limit how much you can download, whether they tell you they do or
not...

"Darrel Toepfer" wrote in message
...
500ms ping time minimum... So count on lots of lag...

Unless you are playing online computer games, you would never notice the
lag. Most Internet access is of the form "brief request for data, followed
by large amount of data returned". It'll take an extra half-second for the
data to show up, but that will generally be swamped by the time it takes to
actually generate and send the data, even at broadband speeds.

Some don't network very well...

Not sure what that means.

None will work when it rains hard or the sun is in transit (summer /
winter
soltice)...

Why would you say that? The satellite data systems I've seen are based on
similar technology to that used for my digital broadcast satellite system.
At worst, data throughput drops *some*, and that's in the very worst
downpours.

I have no idea why the solstices would have any effect on data transmission.
Perhaps you could explain that one.

All end up with more customers than they can actually support (whether it
be
on the transponders, gateways or internet bandwidth)...

That may well be true. Though, of course, it happens with DSL and cable as
well.

Pete

On Tue, 19 Aug 2003 21:13:35 -0700, Peter Duniho wrote:

500ms ping time minimum... So count on lots of lag...

Unless you are playing online computer games, you would never notice the
lag. Most Internet access is of the form "brief request for data,
followed by large amount of data returned". It'll take an extra
half-second for the data to show up, but that will generally be swamped by
the time it takes to actually generate and send the data, even at
broadband speeds.

This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

None will work when it rains hard or the sun is in transit
(summer / winter soltice)...

Why would you say that? The satellite data systems I've seen are based on
similar technology to that used for my digital broadcast satellite system.
At worst, data throughput drops *some*, and that's in the very worst
downpours.

I have no idea why the solstices would have any effect on data
transmission. Perhaps you could explain that one.

Your transmitter is nowhere as powerful as the one of the base station
or the one on the satellite.

The good news is that DirecWay's dish is about as big as the
old PrimeStar dish. I have one of those, modified to support
DirecTV's LNB with a bunch of duct tape and some pieces of wood.
My TV never goes off even in "worst downpours". So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

-- Pete

"Pete Zaitcev" wrote in message
news
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response. Even if
the delay were 10 seconds (which it's almost never going to be), that's in
the same ballpark as the delay some servers have just getting around to
servicing a client. It's just not a big deal.

[...] So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Hmmm...okay, I see. I wasn't aware that they didn't provide a high enough
power transmitter to deal with weather.

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

Several minutes? I guess I'd call that insignificant. That's what, 10
minutes of downtime per year? Big deal. I have to deal with that kind of
downtime with my wired DSL access.

Pete

"Peter Duniho" wrote in message
...
"Pete Zaitcev" wrote in message
news
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response.

The number of DNS queries to render any particular page can drive this time
up quite high. Have a couple packets lost in between? ouch.

$1000 a year is a bit steep for the class of service.

"Robert Henry" wrote in message
news:hpK0b.11202$uh6.8355@lakeread05...
The number of DNS queries to render any particular page can drive this
time
up quite high. Have a couple packets lost in between? ouch.

That's just silly. Especially for the typical use in an FBO, the number of
DNS queries to render any particular page is going to be quite small.
Furthermore, there's no need for DNS queries to be serviced sequentially,
and I doubt any browser would do it that way. I know that IE doesn't.

Once they get the initial page HTML, any additional Internet addresses that
need a DNS query to be resolved can and will be handled asynchronously. In
other words, a dozen DNS queries required by a single page isn't going to
take much more time than one additional DNS query would take.

$1000 a year is a bit steep for the class of service.

Only if you can have DSL or a cable modem installed. If you are in the
boonies and satellite is the fastest, most reliable Internet connection you
can get, $1000/year isn't that bad at all.

Pete

"Peter Duniho" wrote...
"Pete Zaitcev" wrote...
This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Regardless, that still only affects the initial delay in response. Even
if
the delay were 10 seconds (which it's almost never going to be), that's in
the same ballpark as the delay some servers have just getting around to
servicing a client. It's just not a big deal.

Ever tried VOIP over satellite? Painful, is a good one word discription,
same for remote access applications, network gaming as mentioned is
impossible...

[...] So, your downlink
is virtually rain proof. The bad news is that the same cannot
be said about your uplink.

Hmmm...okay, I see. I wasn't aware that they didn't provide a high enough
power transmitter to deal with weather.

Someone who lives in the desert might not experience as much rainfall that
occurs in other parts of the USofA or other countries in the beam... Hmmm
Las Vegas just got flooded, so better wording might be, "on a regular
basis"...

Solstices only knock communication off for several minutes a day,
when the Sun is directly behind the satellite. It is a well known
effect. I used to depend on an old Soviet satellite Raduga-7
for connectivity, and it was true back then.

Several minutes? I guess I'd call that insignificant. That's what, 10
minutes of downtime per year? Big deal. I have to deal with that kind of
downtime with my wired DSL access.

Nearly 10 minutes per day spread over several days, twice a year...
Guaranteed to screw up something important that needed to be done,
everytime...

Satellite data delivery has faults, just making you aware of it... I've been
there done that (our lawyers got the money from the class action lawsuit
against Hughes) and won't geaux back (2 cards still sits in the deactivated
computers since '98, dishes are still pointed at the satellites) to anything
with a ping time over 90 ms to the world... I actually endured the loss of
the satellite itself once, and the repointing a few times due to bird
migration (moving from one satellite to another, as the provider sees
fit)...

Pete Zaitcev wrote in message ...
On Tue, 19 Aug 2003 21:13:35 -0700, Peter Duniho wrote:

500ms ping time minimum... So count on lots of lag...

Unless you are playing online computer games, you would never notice the
lag. Most Internet access is of the form "brief request for data,
followed by large amount of data returned". It'll take an extra
half-second for the data to show up, but that will generally be swamped by
the time it takes to actually generate and send the data, even at
broadband speeds.

This depends on how big the data piece is relative to the
starting handshake. Consider that TCP start-up involves
so-called 3-way handshake, and that many protocols have
a setup phase when client and server exchange messages
strictly in simplex, before bulk data transmission can commence.

Sorry for continuing an off-topic conversation and splitting hairs,
but....

"Lag" in the original poster's case, is actually referred to as
"latency" in the world of computer networking. Latency is defined as
the time it takes to set up and send a message, whereas bandwidth is
the rate at which data moves from point to point. Sat connections,
therefore, have a latency of 500ms (for example) plus the latency of
the system doing the send/receive.

Since all data is transported in TCP packets (in the case of Web
traffic), there is continual send AND receive on BOTH sides since TCP
requires acknowledgement of every packet on the part the of the
receiver (remember, TCP is a *reliable* protocol). Granted, the ACK
packets are much smaller than the data packets and most of the traffic
to a web browswer is downstream, but a high-latency network like
satellite will exhibit performance degradation during *all* phases of
a connection, not just startup.

Did I just restate what was already said? Sorry!

-Scott

"Scott Lowrey" wrote in message
om...
Since all data is transported in TCP packets (in the case of Web
traffic), there is continual send AND receive on BOTH sides since TCP
requires acknowledgement of every packet on the part the of the
receiver (remember, TCP is a *reliable* protocol). Granted, the ACK
packets are much smaller than the data packets and most of the traffic
to a web browswer is downstream, but a high-latency network like
satellite will exhibit performance degradation during *all* phases of
a connection, not just startup.

Wrong. Only if the server requires a protocol-defined acknowledgement
(where protocol is the high-level protocol, like FTP, HTTP, etc., *not* TCP)
would that happen. And that's uncommon with TCP-based protocols (since it
would totally break one of the main advantages of using TCP). Certainly
it's not the case with any of the commonly used protocols.

TCP uses sliding windows to allow constant streaming of data to occur as
long as the latency in the connection is "reasonable". That is, it will
send many packets before needing to receive any acknowledgement even for the
first packet. As long as the acknowledgements start coming in time, the
latency of the connection will NOT affect throughput AT ALL. A latency of
500ms is MORE than reasonable in this context.

Pete