But for those who have managed to miss out on both of those things, I wanted to recap some items here.

 What Changed?

“PCoIP GPO settings take effect immediately when changed (host side only)”

This was announced with the launch of View 5.2 as a new PCoIP feature. But there are a few problems with this, and a lot of confusion around it (even internally to VMware).

To briefly recap the information I left in the comment at myvirtualcloud.net-

This feature allows a limited number of PCoIP settings to be applied to the registry (via whatever method) and to take effect immediately within a currently running PCoIP session.  So, specifically for something like tuning, you would be able to change parameters and it would not require a disconnect/reconnect sequence for those settings to take effect.  This is pretty awesome!

So what’s wrong?

Well, the press releases just generically say “PCoIP GPO settings take effect immediately” – but do nothing to specify WHICH settings.  Further, some issues were introduced between the early 5.2 beta and the RTM code for View 5.2 that caused this feature to only “work” for a really small subset of parameters.  In my opinion, this basically renders a potentially awesome feature mostly useless.

So, in a perfect world, what options should take effect immediately?  As far as I know, the following were planned for in the original drop:

• Disable Build-to-Lossless
• Max session bandwidth
• Session Floor
• Max initial image quality
• Minimum image quality
• Max FPS
• Audio bandwidth limit
• Logging level

What options actually work in the 5.2 GA release (based upon my experience)?

• Max FPS
• Audio bandwidth limit

Slightly less useful right?  So the feature is in there, but it’s not really implemented across enough options to make it terribly viable.

 Why does this matter?

Having this feature added to PCoIP has been a long-standing request of mine. I’ve been building tools (sporadically, I admit) for PCoIP for the past 3 years now, and I’ve always maintained a “vision” of being able to control the protocol in real-time for both users and admins and then building new tools around that.

One tool I had started work on, but have put on hold is a real-time tuner:

So close, yet so far

This tool allows you to view content and tune at the same time; to see the subjective impact of tuning at the same time as the objective impact on bandwidth, loss, and latency. I’ve been wanting to write this tool for 2+ years! And I did, mostly, but you know what?  It’s of absolutely no use to anyone right now, so I didn’t finish, and I won’t be releasing it yet.

The real-time tuner app supports transparency to allow adjustments without altering bandwidth utilization by “masking” pixel changes behind it

I also have several ideas on how to improve the PCoIP Configuration Utility.  With this feature fully implemented, I can create a version of it that not only stores and applies profiles, but that could do so in response to contextual data from the client.  Connecting via a mobile device?  Automatically apply this profile.  Connecting across the WAN?  Automatically apply the WAN profile.  This could be keyed off IP, MAC, User, Domain – whatever!  If it’s a piece of information that can be read on the desktop, it can be used as a condition to apply dynamic tuning.

That would be cool wouldn’t it?

That’s a wrap

So, to wrap this up, I’m pushing hard internally to get the initially planned set of dynamic parameters fully implemented.  I am hoping to see it in the next release of View, but I can’t say if that will happen with any certainty, probably, it won’t.  Still, membership has it’s privileges, so I have access to “working” code for these changes and I wanted to share a video I had intended to show at PEX 2013 but which a last minute computer failure forced me to abort.  I hope it gives you a taste of what’s to come once these features are fully implemented.

I have embedded the video here for ease of access, but since youtube is only aware of video in 16:9 format you can’t view the content at 1:1 which means it’s far harder to see the visual artifacts when aggressively tuning the session.  Because of that I am also going to include a download link for the source MP4 video to allow for true 1:1 playback and better subjective visual inspection.

Also, there’s a slight jerkiness to the video at times, I want to be clear that this is an artifact caused by the software-based capture method I am using and is NOT present when interacting with the View session natively in the View Client.  As soon as a DVI frame-grabber capable of high-resolution capture at 30+ FPS goes on sale for less than a few grand, I will get one and this artifacting will go away, until then – sorry :-/

Direct download:  Dynamic PCoIP Tuning Video

Thanks, and sorry for the lack of content recently, I am hoping to get some blog and software updates out the door in the coming weeks.

Stay tuned for more info this weekend.

TinyCore Builder allows you to fill out a simple form, and get a very compact bootable Linux image with the VMware View Client out the other end. The image provided is ideal for USB or PXE booting a repurposed PC againbst a VMware View environment.

The TinyCore Builder recently moved so if you were already aware of and using this tool, please update your links to the following URL:

http://repurpose.vmwarecloud.at/

Enjoy!

I’ll update the blog as soon as a fix is found.

So, here it is! The new and improved PCoIP Configuration Utility.

I have decided to remove the beta moniker and call this code drop Version 1.0.  I consider this a decently “feature complete” drop of the code, but as with all software, it’s never done, and bugs almost certainly remain.  Unlike Google though, I feel compelled to take things out of beta after a reasonable amount of time

What’s new

You saw some of this in my previous sneak peek post but I’ll recap it all here. For the original feature list please review the initial launch posting here.

Features

• PCoIP Connection Health Monitoring (See screenshots)
  • Monitors various PCoIP connection stats and determines an overall health score
  • Health status can be easily determined via the systray icon with states ranging from “green” to “red”
  • A new health status popout that shows the metrics being tracked and their current health “scores”
• Profile Tooltips
  • Hovering over a profile within the “Apply Profile” menu will now show a tooltip with the detailed settings for that profile

Hovering over a profile now shows detailed information

Fixes

• PCoIP Server CPU Utilization
  • This should now be accurate, previously, as load increased this value would scale out of proportion to the actual load leading to inflated CPU utilization values

Enhancements

• Session disconnect awareness
  • The utility now detects when there is not an active PCoIP session and when there is not, it enters a  ”sleep” mode that will consume less CPU than the active polling mode. Why burn CPU if there’s no user connected right?
  • Upon re-connection the utility will cleanly reset and resume stat collection in active polling mode. Previously, stats were not properly reset after a disconnection event causing some ugly numbers in the stats popout window.

Requirements, Issues, Implementation details, etc.

• .NET 3.5 is required
• VMware View 5.0 or 5.1
• Tuning profiles and last used profile are stored in HKCU and in theory should be able to roam with a user to whatever desktop they happen to land on – if you have something setup to allow the profile to roam, that is.
• The utility will request admin access – it needs this to be able to write to HKLM which is where the PCoIP settings are read from. You may need to get clever while launching it if you want to avoid UAC nagging you about it.
  • This seems to come up often in the comments and in other feedback, right now there’s not an easy fix for this. I have reached out to Teradici to get these settings moved under HKCU – we’ll have to see where that leads. This CAN be fixed but most options are kind of a “cure worse than the disease” solution that I’m not ready to move towards just yet.
• GPO Conflicts
  • If you plan to use this tool to manage the tuning settings of a desktop you should avoid also setting tuning parameters via GPO on that desktop. GPO can still be used for things like clipboard sharing policy, or USB device policy, just avoid any of the settings controlled via a profile.

Download

You can grab a copy of the utility here: PCoIPConfig.exe

Next Steps

There are a lot of existing enhancements left for the current tool. But the biggest issue still remains the required disconnect/reconnect. There are some potentially promising developments along that path though, so stay tuned. Please share your thoughts for enhancements and/or bugfixes in the comments.

At the end of that article the author concludes that the reasons for designing a new connector are not “control for the sake of power” but instead because it’s the only way to do it “right”. A committee could only produce an inferior product.

And this is where I disagree.

While I do believe in the power of the “individual” to be more bold and take greater risk in a design, I wholly believe this move by Apple is entirely about control for the sake of power – at least as far as power = money.

Any of the capabilities of the current dock connector can be handled by microUSB and/or analog audio jack and/or Bluetooth. You can bicker about the details but I’m sorry – the current generation of standard ports and technologies CAN provide equivalent functionality. Possibly “different”, but no less capable. So while Apple could work within the standards of today, they choose not to. If their concern really was to make a better connector for all of us, why couldn’t they go to the existing standards bodies and propose changes. Yes, it’s a committee, but if your goal is to really improve things, you’d tough it out. Apple could have massive influence on any standards body, don’t be fooled into thinking they couldn’t. So they could say “We would like to propose the following changes to the microUSB standard, connectors shall be omni-directional, tolerances shall be X, electrical characteristics need to be Y, additional data busses need to be provided for Z, and the following control protocols will need to be implemented. And by adopting this standard we can all benefit by enabling a broadly compatible ecosystem of devices and peripherals that allows for consumer choice, while also improving ease of use, and lowering costs through economy of scale.”

But that will never happen. That is why I can only see this as another power grab and tactic to control the cash flow around the Apple ecosystem. Even with a “standard” Apple could contract out and make the highest quality version of that connector, and the highest quality cables – better quality than anyone else. But they know that no one would pay their premium if Uncle Jimmy’s World of Connectors could make the same thing and only make it “good enough” for half the cost. Without creating an artificial scarcity via control of the hardware spec and licensing, Apple would have to fairly compete with everyone else – and that ain’t gonna happen.

I find it ironically amusing that Apple has gone into traditional media and completely busted up their model – a model based ENTIRELY upon artificial scarcity. That is/was the premise for music, movies, TV, and print.  Control the distribution channels and you control the pricing.  But no one ever looks at Apple and sees that they are doing the exact same thing with this forced ecosystem of proprietary connectors and ports. So it’s OK for them to bust up everyone else’s business, it’s just not OK for anyone else to bust up their racket.

My point here isn’t that microUSB is the “best”, my point is that everyone would benefit from an improved connection STANDARD – and in far more ways than just making the physical connection easier to use. Perpetuating proprietary connectors and then selling adapters to make them compatible (as the EU requires) does far less good. People still end up with the confusion/complexity of an inferior standard, and they have to pay more on top of it. How is that good for me? How am I benefiting from the improvements of the proprietary connector then?  Or, ok, go make your connector, but license it fairly – how do you think Apple would feel about letting Samsung license their new connector?  Motorola? LG? HTC? Asus? Acer? Intel? Microsoft? Yeah. Exactly.

“But why should Apple license it?! Why help those other guys? They did all the work designing it! They deserve to reap the rewards from it.”

This means there’s an update to the parser and the viewer to reflect the new versioning. As always the Viewer will update itself, but you’ll need to grab the parser from here.

The updated parser can found here. It should report version 1.0.0158 when passed ‘-h’.

If you need to freshly install the viewer you can find it here.

One of the requests I had gotten was to allow the context menu to be opened with a left-click vs. a right-click as it’s not so easy to trigger a right-click when accessing a desktop from a mobile device. This change is in place. A right-click or a left-click can be used to open the context menu.

Another request was to add some form of “health” monitoring of the connection. I thought this was a great idea but the actual implementation is fraught with issues. Still, based upon what I know of PCoIP I figured there should be a few things you can monitor and compare against some “common sense” baselines to determine if things are looking good or looking bad. So that’s where I went. I’ll cover this again in the official release post (likely a few weeks out I am sad to say) but this is NOT a “user experience” meter! View and PCoIP continue to improve in their tolerance for less-than-ideal network conditions such that even on a highly latent or slightly lossy network connection you can still have a good user experience, but the fact remains that the connection itself is less than ideal – and that’s what the tool will be showing you.  It might also be the case that the network conditions are just fine and yet your user experience could be bad – this might be from lack of CPU on the VM or client side, or other factors – I can’t measure all of those, and so I can’t show you why things might be bad in that case – but at the very least you can have some peace of mind that it’s probably not the network. I just throw these examples out to show that network health alone (as measured by PCoIP) cannot be directly correlated to end-user experience. Often they will be reflective of each other – but not ALWAYS.  Are we clear? Ok. Good.

The health score calculations themselves I’m not going to cover in too much detail, but basically there are 4 items being calculated or measured directly (and then factored into other calculations):

• Packet Loss
• Latency
• Variance/Jitter
• Available Bandwidth/Bandwidth Limitng

So what does this new stuff look like? First off you’ll notice that the systray icon for the tool is slightly different.  It now has a status “LED”:

Green to red - blinky blinky!

This is so that users can have at-a-glance visibility into the general health of the connection and is probably the way most people will interact with this new feature. However, if you want a more detailed view of the health rating there’s also a new menu option:

Can you find the new option?

Selecting this will pop-out a new window giving a bit more detail into how the current health score is being generated. Let’s look at a few examples…

Happy, healthy (LAN) connection:

Doesn't get much better than this

Connection with moderate latency and variance:

Yes, that is the video you think it is...

Another showing packet loss and the fact that PCoIP is adapting down bandwidth to deal with that loss:

Where, oh where, have all those packets gone?!

And the “I need to play flawless video to my offshore users, 15,000 miles away across homing pigeons carrying floppy disks” connection (a.k.a. business as usual for VMware PSO):

What do you mean it's a network problem?!

So there you have it, a sneak peek at what’s coming soon in the PCoIP Configuration Utility. I am also hoping to have a profile import/export function to make it easier to share and distribute PCoIP tuning profiles. Check back in a few weeks and let’s see where we land.

To update the viewer simply launch it while connected to the internet and it should auto-update.

The updated parser can found here. It should report version 1.0.0134 when passed ‘-h’.

If you need to freshly install the viewer you can find it here.

One item of note – it seems that delta bits and delta build bits have been removed in this release so there will be no data reported for them in the graphs.

As always please report issues in the comments and PLEASE provide some feedback on my previous post: A note on View 5.1 Support for the PCoIP Log Viewer

Once again, with View 5.1 I find myself in a position of chasing a new file format that clearly was never intended to be machine parsed. Data is randomly placed, and formats and positioning data are altered from previous releases – seemingly for no good reason.  New data is mingled with old and some data has simply vanished entirely.

With the 4.x series of releases the changes were there but relatively minor from release to release. With the move to 5.x and the introduction of the APEX2800 card, the changes are much more significant. I assume this is because someone is making the assumption that if people want to monitor PCoIP they’ll use the WMI counters to do so and that the logs are irrelevant. However, it’s not always feasible to get direct access to be able to monitor via WMI and in some areas the logs do contain more information than the WMI counters have available. So it’s been a worthwhile struggle to keep updating the parser to get meaningful data out of the logs.

At this point though, the changes for both View 5.0 and 5.1 look to be quite significant. And updating the existing parser for these formats while retaining the old formats is becoming a significant challenge. I am thinking it might be time to reconsider the entire parser framework to make it more easily expandable and maintainable for future releases. This means, without question, a longer downtime before View 5.1 support will appear. It also quite possibly means the end of a standalone parser as my direction would be a cloud-based design and/or integration of the parser into the viewer directly.

I’d like to try and solicit some feedback on these new directions, so here’s a few questions, please respond in the comments:

• Do you currently use, and see value in, the continued support of a standalone parser executable?
• Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files)
• If you  had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first?
• Do you see the need for continued log file parsing support or is WMI support alone enough going forward?

I will determine the future course of Log Viewer development based upon your answers (or lack thereof).

Thanks,

Chuck