Unsolved
This post is more than 5 years old
5 Posts
0
28574
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
laur3ns
35 Posts
0
January 30th, 2011 13:00
> Remember that with GA you can control the amount of compression (high-medium-low).
Where are these settings?
DELL-Jon Ro
64 Posts
0
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
rmack1
48 Posts
0
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
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:
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.
markh21
98 Posts
0
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
markh21
98 Posts
0
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....
Michel Roth
173 Posts
0
February 7th, 2011 13:00
You right Mark. It’s one the ‘server’ side indeed. So virtual desktop or TS/RDSH.
psnovar1
27 Posts
0
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
rmack1
48 Posts
0
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
psnovar1
27 Posts
0
May 26th, 2011 17:00
Hi Mark, thanks by informations.
I will test using vWorkspace registry tasks.