Networking standards and load conciderations

Hello fellow Linux gurus,

I have a question floating in my mind about network loads and "Mb/s
per X amount of users." Is there a standard? I am stationed in Iraq
right now and we have a service here that puts internet into our rooms
for $50 a month... This speed, as you would expect is supposed to be
fast right? Wrong, we are dragging arse and I feel like I am back on
the baud modems of our good ol' days.

The why they have it set up, is we have a satilite reciver to a modem
and form there switched 100+ diffrent ways. Its killing me!

So, if you have any information pertaining to certian standards (IEEE
or ISO) off hand that you can direct me to, I would be greatful.
Perhaps with this information I can propose a solution to my higher.

Take care,
Paul

On Tue, 13 Mar 2007, Paul Hendricksen wrote:

> Hello fellow Linux gurus,
>
> I have a question floating in my mind about network loads and "Mb/s
> per X amount of users." Is there a standard? I am stationed in Iraq
> right now and we have a service here that puts internet into our rooms
> for $50 a month... This speed, as you would expect is supposed to be
> fast right? Wrong, we are dragging arse and I feel like I am back on
> the baud modems of our good ol' days.

There is absolutely no standard. Availability of bandwidth varies greatly
between areas and thus it's value as a commodity changes. If only 10
megabits of bandwidth are available for 10 users that need concurrent
access they cannot have more than 1 megabit each.

>
> The why they have it set up, is we have a satilite reciver to a modem
> and form there switched 100+ diffrent ways. Its killing me!

That sucks. I remember my 2400baud modem. It worked fine for BBSs but I'd
sooner shoot myself then try and do anything with it after being spoiled
by 8Mb/s connections.

>
> So, if you have any information pertaining to certian standards (IEEE
> or ISO) off hand that you can direct me to, I would be greatful.
> Perhaps with this information I can propose a solution to my higher.

If you want to convince him that you need it tell him that the slow
bandwidth is in some way hurting your productivity with whatever it is
you do (-:

>
> Take care,
Good luck with the BW, I feel your pain (-;

--Sir Jackery

Paul Hendricksen <(E-Mail Removed)> wrote:
> I have a question floating in my mind about network loads and "Mb/s
> per X amount of users." Is there a standard? I am stationed in
> Iraq right now and we have a service here that puts internet into
> our rooms for $50 a month... This speed, as you would expect is
> supposed to be fast right? Wrong, we are dragging arse and I feel
> like I am back on the baud modems of our good ol' days.

What does the supplier say the bitrate should be?

> The why they have it set up, is we have a satilite reciver to a
> modem and form there switched 100+ diffrent ways. Its killing me!

IIRC, satellite mean at least 500 milliseconds of round-trip delay.
Up and back outbound for ~46000 miles, and an up and back for the
return for another ~46000 miles, so 92000 miles at 186000 miles per
second or ~500 milliseconds.

TCP has a window-based flow-control mechanism - a TCP sender can send
no more than one window's worth of data before it must wait for a
window update from the receiver. The soonest that can happen is one
round trip time (RTT). So, we have one of the fundamental limits to
the performance of a TCP connection as the window size divided by the
round-trip time:

Window/RTT

If you have an 8KB TCP window, then with a 500 millisecond RTT that
means that TCP will go no faster than (8192 bytes * 8 bits/byte)/ 0.5s
131072 bits per second. If you prefer KB/s then that would be
8KB/0.5s or 16 KB/s.

If you have an application which is latency sensitive, the more
exchanges it must do before you see something happening the slower it
will appear. For example, if you were running a browser, it will take
0.5s to establish the TCP connection, and then at least another 0.5s
to have the response arrive from the initial HTTP request. So, it
will be at least one full second before you could see any response at
all from a web server, and that assumes that it is just the one
exchange required to see something. If you are accessing pages with
lots of things embedded in them, if they are do different webservers,
or even to the same web server, all that is going to pile-up.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Wed, 14 Mar 2007, Rick Jones wrote:

> Paul Hendricksen <(E-Mail Removed)> wrote:
>> I have a question floating in my mind about network loads and "Mb/s
>> per X amount of users." Is there a standard? I am stationed in
>> Iraq right now and we have a service here that puts internet into
>> our rooms for $50 a month... This speed, as you would expect is
>> supposed to be fast right? Wrong, we are dragging arse and I feel
>> like I am back on the baud modems of our good ol' days.
>
> What does the supplier say the bitrate should be?
>
>> The why they have it set up, is we have a satilite reciver to a
>> modem and form there switched 100+ diffrent ways. Its killing me!
>
> IIRC, satellite mean at least 500 milliseconds of round-trip delay.
> Up and back outbound for ~46000 miles, and an up and back for the
> return for another ~46000 miles, so 92000 miles at 186000 miles per
> second or ~500 milliseconds.

That really depends on weather he is using two way satellite connection or
not. If it's one way his upstream band is probably provided by that modem
(terrestrial return). This could seriously slow down average use of the
connection.

>
> TCP has a window-based flow-control mechanism - a TCP sender can send
> no more than one window's worth of data before it must wait for a
> window update from the receiver. The soonest that can happen is one
> round trip time (RTT). So, we have one of the fundamental limits to
> the performance of a TCP connection as the window size divided by the
> round-trip time:
>
> Window/RTT
>
> If you have an 8KB TCP window, then with a 500 millisecond RTT that
> means that TCP will go no faster than (8192 bytes * 8 bits/byte)/ 0.5s
> 131072 bits per second. If you prefer KB/s then that would be
> 8KB/0.5s or 16 KB/s.
>
> If you have an application which is latency sensitive, the more
> exchanges it must do before you see something happening the slower it
> will appear. For example, if you were running a browser, it will take
> 0.5s to establish the TCP connection, and then at least another 0.5s
> to have the response arrive from the initial HTTP request. So, it
> will be at least one full second before you could see any response at
> all from a web server, and that assumes that it is just the one
> exchange required to see something. If you are accessing pages with
> lots of things embedded in them, if they are do different webservers,
> or even to the same web server, all that is going to pile-up.
>
> rick jones
>

Sir Jackery <(E-Mail Removed)> wrote:
> That really depends on weather he is using two way satellite
> connection or not. If it's one way his upstream band is probably
> provided by that modem (terrestrial return). This could seriously
> slow down average use of the connection.

That is true - I was ass-u-me-ing based on the situation description
given that the satelite link would be two-way rather than one-way with
a terrestrial return. Just one-way would change the minimum RTT to
250 milliseconds.

I guess it would be good if the OP could do some "ping" tests from his
system to some suitable system "out there."

I presume you mean that a considerable assymmetry between the
downstream bitrate via the satellite and the upstream bandwidth of the
modem could be limiting the effective use of the downstream satelite
link? I guess if the IP can find-out and tell us what each of them
happen to be then we could calculate if the upstream bandwidth were
sufficient to support the required rate of TCP ACKs back to the
server.

I suppose if the OP's system/network are sufficiently "open" we could
setup some sort of netperf or other tests to try to see what each of
those bandwidths happen to be, using perhaps some carefully crafted,
paced UDP_STREAM tests.

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...