Bandwidth Calculation !!!

[Striker99]

All,

I am relatively new to comm's and need all the help i can get to solve my problem.

My question is, how do i calculate the bandwitdh for my application. My client application is connecting to Server thro a remote access. I understand that this depends on the size of the message transfered. Once i know the size of the message, how do i proceed in calculating the Bandwidth.

All kinds of help in this would be greatly appricated.

Rgds,
striker99

 

[benzito]

Assuming u have a Windows box:

Sounds like your display / resolution settings are off.

To remedy this, go to start->settings->control panel->display->settings->screen area, and try adjusting the resolution. Sounds like it may be set to low.

Try 800 x 600 or 1024 x 768.

 

[benzito]

oops: Wrong Forum

but to address ur issue. Bandwidth is determined by connection type (ie. Dialup, BroadBand, Satellite, etc), not application.

Maybe I'm missing ur point...

 

[dilettante]

The rough-and-ready way to do this is to first look at your application as a series of user transactions:

User does (T1), gets back (R1).
User does (T2), gets back (R2).
etc.

You can lump together and average similar ones.

Then you look at how many bytes T1 sends, how many bytes R1 replies; how many T2 sends, etc.

Total the bytes for each (T1+R1), etc.

Then you set response-time criteria for each transaction:

(1) must complete in S1 seconds.
(2) must complete in S2 seconds.
etc.

This part is a service-level issue. You want it fast, it is going to cost.

Then you calc. it for each transaction (8 bits/byte to change to bits/sec):

B1 = (T1+R1)*8/S1
B2 = (T2+R2)*8/S2
etc.

Then you really need some idea of the frequesncy of each type of transaction. For example if transaction 1 is to load up a client program over the network and initiate it - that might be the most expensive thing you have but you only do it once - throw it out. If another is done infrequently but must meet your service-level requirements, keep it in.

Generally discard the rare ones from your list.

You might also discard any others that stick out as having high bandwidth requirements if they aren't common, or else work to optimize them - figure out how to get by with less bytes over the wire if at all possible.

After you've weeded things out, take your highest "B" (bandwidth in bits/sec) figure. Lets say you ended up with a high after weeding out extremes and once-onlys of 5000 bits/sec.

Now you need to make an assumption about overhead. For TCP/IP over ethernet, assume 70% overhead (no lie, it is really poor) for an app with small transactions, leaving you 30%. If you are doing file transfer operations it does a heck of a lot better. This part is black art and depends on your network. Lets assume 25% overhead best case, leaving us 75%.

B' = "biggest B after weeding" /{.30 to .75}

If "big B" is 5000 this gives us about:

B'high = about 17,000
B'low = about 7,000 bits/sec

Then I would lick my finger, hold it to the wind, and average the two for a final figure:

B' = 12K bits/second

These days that is an extremely modest requirement, quite suitable for dialup connections. If you throw in nastiness like graphics or passing recordsets back and forth you can easily see MUCH higher bandwidth requirements - but you T1/R1 values should cover that nicely giving you an appropriate high B' at the end.



The other approach is empirical, using a recording bandwidth monitor installed on a machine running an automated tester that runs at human-operator speeds to "play back" a realistic session with your application. I don't have one of those.


Does this help?

Any other opinions??