Start a Conversation

Unsolved

This post is more than 5 years old

28574

October 11th, 2010 16:00

Excesive bandwith usage by vWorkspace

Hi folks,

I having a very strange issue that is probably related to my environment but I'm not able to catch.

This is the ticket I just opened with the support team, just in case it rings a bell.

regards!

dani

Hello,

I detected a very strange behaviour about the bandwidth  consumption using vWorkspace that I'm able to reproduce in a very  consistent way.

Under the same conditions vWorkspace uses 100 times more bandwith  than classic Terminal Services.  The same operation in classic Terminal  Services uses 9KB/s while the same operation in vWorkspace uses  1000KB/s.

You will find attached a couple of snapshoots of the final results in my environment.

What I do to reproduce it is:

1) Install DUMeter to watch the bandwidth consumption
2) Open a full desktop first using Terminal Services and then vWorkspace
3) In the remote desktop, navigate to c:\Windows using the File browser
4) scroll in this directory up&down.


At  least in my environment, the bandwidth used by classic Terminal  Services goes between 6 and 15 KB/s.  Using vWorkspace can range between  700 and 1450 KB/s. (near the limits of my internet connection)

Do you have any advise to where to start looking for this bandwith leak?

You'll find attached my test results and my vWorkspace configuration

Additional Attachments:

1 Attachment

35 Posts

January 30th, 2011 13:00

> Remember that with GA you can control the amount of compression (high-medium-low).

Where are these settings?

64 Posts

January 30th, 2011 13:00

I don't have the UI in front of me, but IIRC you right-click on Managed Applications in the Resources node

48 Posts

February 3rd, 2011 07:00

Hi Mark,

One of the features of EOP that accelerates RDP display performance on bandwidth-limited (WAN) connection is graphics acceleration (GA). GDI graphics primitives are hooked on the virtual host, passed through a JPEG compression engine, transferred down a separate virtual channel to the client and injected into the RDP client display buffers. But this isn't a panacea for reducing bandwidth utlisation because RDP has some real smarts of it's own as well.

GA overcomes a few RDP client performance issues:

(1) RDP isn’t all that efficient at handling animation, graphics or even simple stuff like transparency changes, and (2) the bias towards the video virtual channel meant that heavy video updates could effectively stall the RDP session keyboard and mouse response and (3) RDP’s screen painting (64x64 pixel blocks), where EOP GA paints a screen in a far smoother fashion.

A good example of the capabilities of EOP GA can be illustrated by opening IE and going to a site that has non-flash (taken care of by flash redirection) multimedia content. In this scenario, EOP GA is significantly faster and uses a fraction of the bandwidth used by native RDP. But RDP does some things very well indeed, particularly when dealing with fonts and cacheable glyphs.

The trick with getting the most out of EOP GA is to use graphics capabilities, tuned to best advantage where the CPU used for compression makes sense, and to let RDP do what it does best when it makes sense. While in an ideal world all these settings would be automatic on a per application basis, it is nearly impossible to make a hard and fast rule for each application because performance depends on content. For example, Word documents are handled very efficiently by standard RDP, but once a document has images inserted, scrolling and refresh times will be significantly degraded.

I need to stress this again. RDP handles system fonts and glyphs (cacheable bitmaps from menus etc) very efficiently, much more so than any bitmap compression technology. EOP GA handles transparency changes, colour bitmaps and animation much better than standard RDP, but isn't nearly as efficient with standard fonts. Unless of course you have font smoothing enabled which means RDP is handling fonts as bitmaps where you'll find EOP is again faster.

To get the most out of EOP GA and your available bandwidth, you have to be selective about the applications that get displayed by EOP GA. As a loose rule, GA works well for non system font based applications (IE, Acrobat reader) and should be disabled for system font-based (eg Word, Excel, Windows Explorer etc) applications.

GA can be enabled or disabled globally, or enabled and disabled by managed application. The degree of lossiness (compression, reduced bandwidth) or quality can be set globally (Management console) or on a per-application basis. Maximum compression means minimum quality and depending on your colour depth settings, this can also result in a slighly fuzzy (blue tinge) application display. Provided there are no colour palette issues (eg client colour matches virtual host) you will only be dealing with lossiness and not other artefacts (fuzziness) as well.

I tend to set things up either with GA turned off globally and turned on for individual apps, or turned on globally and disabled for individual applications. Either approach will generally give a much better result than having just GA enabled or disabled.

Version 7 of vWorkspace allows much greater granularity with regard to the graphics acceleration applied on a per application basis.

In order to make sense of the tuning options, I’ve lifted information from a great wiki article about JPEG (http://en.wikipedia.org/wiki/JPEG) to explain the effect of manipulating some of the graphics acceleration settings.

HKLM\Software\Provision Networks\Image Acceleration

Enabled: (reg_dword) 0 – off globally, 1 – on globally
This is easiest option, turn graphics acceleration (GA) on for all applications, regardless of whether it makes sense or not. No smart font handling or bitmap caching and just treat everything as if it was a bitmap. That’s not all that dumb with RDP 7 because font smoothing (or ClearType support) treats fonts as bitmaps so why not use GA but if you're not using font smoothing and use mainly system font-based applications (Windows explorer is an application) then GA could use more bandwidth than standard RDP.
Exceptions: (reg_multi_sz) a list of applications that are exceptions to the global rule, that is applications that are either NOT accelerated (if Enabled=1) or applications that ARE accelerated (if Enabled=0)
This key contains values that are the executable names, eg         acrord32.exe    iexplore.exe
Quality: (reg_dword) gross degree of lossiness of global JPEG compression.
0 - very lossy, also fast
1 – some lossiness, not quite as fast

2 – almost no lossiness but slower

ProgressiveUpdate: (reg_dword): 0 disable progressive update, 1 enable progressive update

This works by updating a JPEG compressed image with a lossless image once the image has been static for more than 15 seconds. An example of where you’d want to do this is medical x-rays where you can’t afford to have a JPEG introduced artefact that gets interpreted as a tumour.

Jpeg Quality: (reg_dword) Jpeg quality 20-100 [Note: this overrides Quality when present]

This allows you a bit more granularity, but it is still a global setting. The effects of manipulating JPEG quality are illustrated in the examples below:

Examples:
Quality
Compression Ratio
Comment
High quality (Q = 100)
2.6:1
Extremely minor artefacts
Medium quality (Q = 50)
15:1
Initial signs of subimage artefacts
Low quality (Q = 20)
25:1
Stronger artefacts; loss of high resolution information

Jpeg RGB (REB_DWORD): 1 - using RGB instead YCbCr,  0 – use YCbCr

Due to the densities of color- and brightness-sensitive receptors in the human eye, humans can see considerably more fine detail in the brightness of an image (the Y component) than in the color of an image (the Cb and Cr components). Using this knowledge, encoders can be designed to compress images more efficiently.

Jpeg Subsampling: (reg_dword) 0 - 4:4:4, 1 - 4:1:1 (default), 2 - 4:2:2

The transformation into the YCbCr color model enables reduction of the the spatial resolution of the Cb and Cr components (called "subsampling"). The ratios at which the subsampling can be done on JPEG are 4:4:4 (no subsampling), 4:2:2 (reduce by factor of 2 in horizontal direction), and most commonly 4:2:0 (reduce by factor of 2 in horizontal and vertical directions). For the rest of the compression process, Y, Cb and Cr are processed separately and in a very similar manner.

Note that subsampling increases lossiness and visual artefacts (fuzziness around characters) but its fast, both in terms of the compression ratio and the amount of CPU resources needed to achieve the final compression.

Maximum compression and subsampling is definitely quick and dirty, but it does a brilliant job when it comes to scrolling through a PDF document or looking at an animation in IE on a slow WAN link.

ExcludedWindows: (reg_multi_sz) a list of the window class names to be excluded in GA.

Check Microsoft technote 112649 (support.microsoft.com/kb/112649) on how to get Windows class names using Spy or use Spy++ (http://msdn.microsoft.com/en-us/library/aa264396(VS.60).aspx.)

Version 7.X introduces the ability to set GA quality on a per-application basis and more importantly per-user

HKLM\Software\Provision Networks\Image Acceleration\AppList\

– OR –

HKCU\Software\Provision Networks\Image Acceleration\AppList\

Enabled: (reg_dword): 1 - enable GA for this executable, 0 - disable GA

Jpeg Quality: (reg_dword): compression quality (20-100)

Note: GA checks the HKCU AppList first, if the executable is not on the list, it checks the HKLM settings. If the executable is not on the HKLM AppList setting, GA uses the global settings in the HKLM\Software\Provision Networks\Image Acceleration key.

The per-user settings can be propagated as a login registry task or a custom group policy template.
This would let you do things like depending on the client subnet address, turn on GA or not for an application, or if a user has problems with the compression quality, reduce compression for that user or on one application for that user.
I hope this explains a few things and gives you some tools to fix performance issues.
ergards,
Rick

98 Posts

February 3rd, 2011 16:00

about all I can say to that is....wow...

Will have to take a look at this and see how best to implement things like this in relation to us publishing desktops.

the main apps that need fast typing over graphics are excel, word, outlook.  Everything else is probably less obvious to the users.

We've disabled GA for many thing because on Windows 2008 R2, just enabling GA for client with default settings based on install showed fuzzy characters and blocks in the background of documents and explorer so this might give me some tweaks to use it when possible...

Thanks

98 Posts

February 7th, 2011 12:00

Just to follow up on this...where would you set the registry keys for

HKCU\Software\Provision Networks\Image Acceleration\AppList\

Is this on the VDI/Terminal Server side of the users profile or is this a local client side setting?

I would guess the VDI/Ts side....

173 Posts

February 7th, 2011 13:00

You right Mark. It’s one the ‘server’ side indeed. So virtual desktop or TS/RDSH.

27 Posts

May 19th, 2011 13:00

What is the correct way to configure this settings by user or user groups that will use Internet Explorer?

Can anyone provide a example or procedure?

Thanks

48 Posts

May 26th, 2011 09:00

Hi Paulo,

It can be set on a per-user or per-group basis by using the vWorkspace registry tasks (under resources in management console) to populate the necessary HKCU settings. You could also use a custom group policy template but it would mean I'd have to hack one up for you

regards,

Rick

27 Posts

May 26th, 2011 17:00

Hi Mark, thanks by informations.

I will test using vWorkspace registry tasks.

No Events found!

Top