[THIN] Re: ICA session bandwidth calculations

  • From: HBooGz <hboogz@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Mon, 12 Jun 2006 10:50:37 -0400

Guys -- I definitely appreciate the input and understand that overhead and
as each packet transverses each layer from the source to the destination
there can be an added overhead. But for basic management purposes i want to
keep it simple.

Purely understanding that MegaBytes relates to a size while Megabits relates
to throughput ( generally speaking ) is part of the battle and calculation
to further express will follow.

Thanks guys..

On 6/9/06, Joe Shonk <joe.shonk@xxxxxxxxx> wrote:

And then there is data add to each packet as it transverses each layer of the network stack. Not to mention you also need to account for latencey, retransmissions, acknowledgments and the line speed of the destination.

Joe


On 6/9/06, Nick Smith <nick@xxxxxxxxxxxxxxx> wrote: > > Try reversing the explanation. > > Take a 1 mega-bit pipe. It transfer 1000 kilobits/second. To work out > the bytes divide by 10 (This is of course a non-binary lie, but we're aiming > at decimal-speaking folks). So it can transfer, at a **maximum** 100 > kilobytes/second. So, your 1.5 Megabit line will actual transfer > 1,500/10 = 150 Kilobytes a second. Roughly speaking, you're going to get 1 > Megabyte every 6 seconds (Again an approximation, but we want to keep this > easy for your guys). Therefore you will get 60/6 = 10 Megabytes/minute â so > your 100MB file will take 10 minutes to transfer. > > > > Alternatively, try pointing them at this site: > > http://www.onlineconversion.com/downloadspeed.htm > > > > I believe a T1 is 1.5Mbits, so for your 100Mbyte file, it says 9.03minutes. Personally, given overhead, packet loss, headers, and general > internet messiness, I'd guess that my 10 minutes is probably more realistic. > > > > > (Bows in a slightly smug mannerJ ). > > > > Nick > > > > *From:* Andrew Wood [mailto:andrew.wood@xxxxxxxxxxxxxxxx] > *Sent:* 09 June 2006 09:58 > > *To:* thin@xxxxxxxxxxxxx > *Subject:* [THIN] Re: ICA session bandwidth calculations > > > > ah right - thought I'd deleted that - d'oh! > > > ------------------------------ > > *From:* thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] *On > Behalf Of *HBooGz > *Sent:* 08 June 2006 17:31 > *To:* thin@xxxxxxxxxxxxx > *Subject:* [THIN] Re: ICA session bandwidth calculations > > You ended the explanation with " i think" which hinted to me that you > were a little uncertain with your explanantion. > > I just wanted to know if some other folks could chime in with their > feedback on your explanantion or another explanation of their own. > > Thanks to everyone who has contributed thus far. > > > On 6/8/06, *Andrew Wood* <andrew.wood@xxxxxxxxxxxxxxxx > wrote: > > how do you mean - feedback on that explanation? > > > ------------------------------ > > *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On > Behalf Of *HBooGz > > *Sent:* 08 June 2006 17:04 > > > *To:* thin@xxxxxxxxxxxxx > *Subject:* [THIN] Re: ICA session bandwidth calculations > > > > I think management will respond better to 1000 better than the 1024, but > thanks for the specificity. > > Regarding the transfering of the file of a 1.5 Megabit line -- does > anyone have any more feedback on that explanation ? > > On 6/8/06, *Andrew Wood* <andrew.wood@xxxxxxxxxxxxxxxx> wrote: > > > > true - but I was working to IEC standards ;) > > > > I'm happy for it be old school > 1024 as thats a multiple of 8 - but if poor guy is struggling to explain it, > lets not let him have to have the curve ball of explaining to the suit that > a kilo is not *actually* a 1000 but 1024. > > > > :) > ------------------------------ > > *From:* thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] *On > Behalf Of *Alex . > *Sent:* 08 June 2006 16:47 > > > *To:* thin@xxxxxxxxxxxxx > *Subject:* [THIN] Re: ICA session bandwidth calculations > > 1024 is not 1000 > > ------------------------------ > > From: andrew.wood@xxxxxxxxxxxxxxxx > To: thin@xxxxxxxxxxxxx > Subject: [THIN] Re: ICA session bandwidth calculations > Date: Thu, 8 Jun 2006 16:32:36 +0100 > > Well a byte is 8 bits. A kilobyte is a thousand bytes while a kilobit is > a 1000 bits. A megabyte is a thousand kilobytes > > > > Megabit per second - http://en.wikipedia.org/wiki/Megabit_per_second > > Kilobit per second - http://en.wikipedia.org/wiki/Kilobit_per_second > > > > when you transfer 100MB over a 1.5Mbit/s line you are transferring 100 x > 1000 x 1000 x 8 bits over a network that can average a transfer of 1.5 x > 1000 x 1000 bits every second > > > > I think... > > > ------------------------------ > > *From:* thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] *On > Behalf Of *HBooGz > *Sent:* 08 June 2006 15:28 > *To:* thin@xxxxxxxxxxxxx > *Subject:* [THIN] Re: ICA session bandwidth calculations > > I'm currently in a battle with upper management about bandwidth > consumption with certain apps. I could use a basic defintition as what the > differences are from KiloBytes and Kilobits and MegaBytes and Megabits to > demonstrate to further elaborate. > > The confusion comes in when the idea of users transferring files that > are about 100 MegaBytes over a 1.5 Megabit line. > > This ties into the justification of an additional citrix server if > multiple users are running off different apps, printing, file-sharing, etc. > > Thanks, > > > On 6/8/06, *Matt Kosht* <matt.kosht@xxxxxxxxx> wrote: > > I am assuming the 27KB was bits not bytes, as 27 KBps = 216 Kbps... > > I benchmarked a client/server app just recently. Heads down data > entry in the application averaged only 26Kbps (no sound, 16 bit color, > 128 bit encryption, seamless window) with v9.15.xxxx PNAgent. > Benchmarks of ESRI ArcGIS were closer to 33Kbps (probably because it > is so graphics intensive). > > Printing can burst much higher as indicated but can be limited (using > the policy to control it in Citrix) without much notice by the user. > We limited GIS plotter users (who could plot 40-50MB drawings) to > 30Kbps they didn't even notice. Printers are so much slower than the > network it just sits in the spooler waiting to print vs. sitting in > the plotter's local memory waiting to print. Net impact to the user is > the same. > > -Matt > On 6/2/06, Landin, Mark <Mark.Landin@xxxxxxxxxxxxxxxx> wrote: > > I know the rule of thumb used to be 27KB or so for an ICA session. No > > doubt things like high screen resolution, high color depth, and > virtual > > channels have changed that number somewhat. > > > > Is there a number that is still used with some degree of confidence? > If > > not, can one try to calculate what a session would take up? If so, > what > > variables need to be considered? > > > > For instance, I am thinking of deploying a GIS-like app, using 16-bit > > color, 1280x1024 resolution, with no sound, from Windows 2003/MPS3 or > > MPS 4, over an ICA 9 client. What could I expect the bandwidth > > requirements for an ICA session running that app to be? Is there any > way > > to guestimate? > > ************************************************ > > For Archives, RSS, to Unsubscribe, Subscribe or > > set Digest or Vacation mode use the below link: > > //www.freelists.org/list/thin > > ************************************************ > > > ************************************************ > For Archives, RSS, to Unsubscribe, Subscribe or > set Digest or Vacation mode use the below link: > //www.freelists.org/list/thin > ************************************************ > > > > > -- > HBooGz:\> > > > > > -- > HBooGz:\> > > > > > -- > HBooGz:\> >




--
HBooGz:\>

Other related posts: