[THIN] Re: Video Performance

  • From: Chris Grecsek <chris@xxxxxxxxxxxxxxxxxxxx>
  • To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
  • Date: Fri, 18 Jul 2008 11:20:50 -0700

Hi Joe,

Thanks for the speedy response!

We're not using any LBs - there are no network devices other than a standard 
PIX.

The WI and CSGs are both VMs on ESX 3.5. Based on your question I think we'll 
setup a WI/CSG on a standalone server "just to see" even though we're not 
seeing high utilization.

At this point we have not isolated the WI or CSG. We're going to setup an 
additional site on the WI that will not use the CSG so that should achieve the 
isolation.

We've done quite a bit of testing with the speedscreen/multimedia stuff - I 
think we've tried every conceivable combination in the policies and farm 
settings . I believe the policies should apply the same whether we come in via 
the CSG/WI or the PN.
            Image acceleration using lossy compression: enabled; compression 
level: do not use lossy compression; speedscreen progressive display:disabled
            Speedscreen browser acceleration: off; speedscreen flash: enabled - 
all connections; speedscreen multimedia: enabled - buffer = 10.



Thanks again,
Chris
-----------------------------
chris grecsek | centered networks | t:415-294-7776 | f:415-294-7772 | 
chris@xxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxx>
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
Joe Shonk
Sent: Friday, July 18, 2008 10:35 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Video Performance

It could be a couple of things....  Have you tried removing CSG from the 
equation and isolate if its WI or CSG?  Is your CSG box running in a Virtual 
Machine?  Do you have a LB in front of your WI and/or CSG box?  How are you 
Applying the Ctx Policies for the SpeedScreen/multimedia.

Joe

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
Chris Grecsek
Sent: Friday, July 18, 2008 10:24 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Video Performance

We provide published desktops via Citrix/terminal services delivered via the 
internet. All users come in through the web interface/CSG via high speed, 
burstable (up to 100mb) connections. Most of the branch offices are <50 users 
so connectivity/maxxing out the pipe is not an issue. We don't use any 
bandwidth restriction policies - users can use as much bandwidth as they'd 
like. We have bandwidth monitoring to look at all traffic and have our 
firewalls setup so that only Citrix traffic is using the burstable connection. 
Latency is sub 20ms and we have no packet loss.

Like everyone else using Citrix we've had challenges with video performance on 
the published desktop (Windows media player works great - Flash/other codecs, 
not so much). We had an interesting discovery today and I was curious if anyone 
could answer why/how this happens...when we connect to a published desktop via 
the WI/CSG (from one of our branch offices) video performance is bad. We ran a 
test today from within the datacenter where we connected to a published 
desktop, locally (from a laptop at the DC), using the Program Neighborhood as 
opposed to coming in over the WI/CSG and low and behold, video performance was 
excellent.

When we look at the amount of session bandwidth being used it's nearly the same 
when coming in via the WI/CSG as it is when testing at the datacenter. So I 
guess the question is, is there something with the way the WI/CSG works that 
would be restricting/degrading the video performance (we ran performance 
counters on the WI/CSG and it doesn't seem to be working very hard), is there a 
difference between using the Program Neighborhood verses the web client, etc.?

We're on Citrix 4.5, latest rollups, latest version of the client, etc.

If anyone has any ideas, it would be much appreciated.

Thank you!

Chris

-----------------------------
chris grecsek | centered networks | t:415-294-7776 | f:415-294-7772 | 
chris@xxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxx>

Other related posts: