Ericom Blaze Review

This week I had some time available to give Ericom Blaze a try. For those not familiar with the product, it is basically an add-on for Remote Desktop Services that accellerates RDP performance using compression/shaping techniques. It also reduces the overall bandwidth utilization and the effects of latency. Ok, this is all they say on their marketing materials in a nutshell.

The bottom line for me, when running the tests, was to determine two things: does it work? And given its costs, is it worth? After some not extensive testing, this is what I found out.


Dead on simple. Just load a server component that does not even require a reboot on all your RDS Session Hosts (or Terminal Servers as it is compatible with 2003/2008/2008R2) and their client on all your PCs and Thin Clients. They cover all sorts of clients, from Linux/OSX to Windows XP/Vista/7 and even Windows CE. Nice. I even recorded videos to show you how simple the install really is. Here you have them:




So here is the deal. No matter how good marketing is, the bottom line is if the product works. For these tests I simulated two different connection scenarios using an Apposite Linktropy Mini2 (a great device that deserves a review on its own). To determine how much bandwidth and latency I was going to use, I used the website and the iOS app 10 (ten) different times and got the average numbers for each case. With these in hand I first created a baseline video where I use a plain RDP7 client on an XP SP3 box to connect to a 2008 R2 RDS SH and opened a simple PDF file and the Adobe Flash player website. Here you have the videos:


With that out of the way I then proceeded to simulate the two scenarions: cross country connection and 3G. For the cross country, my ten tests returned a 2.5MBits down/1.9MBits up connection with 108ms latency, from Ottawa to San Francisco. For 3G, 2.2Mbits down/330kbps up, 112ms latency (using the Rogers network in Canada from a metro location like Ottawa). Again let’s watch the results:

Cross Country


So what do I think of Ericom Blaze? Well the videos do not lie. It does help your RDS Session Host for sure but depending on the conditions this does not necessarily mean it is usable. IMHO Flash does get better but not to the point that makes it usable. Of course it will get down to the Flash content you have. I do expect Flash websites to work great. For video, at least on my tests, the audio was very choppy, choppier actually than with plain RDP7. But again, your mileage may vary. Bottom line is do I think it is amazing and that it greatly enhances RDP? No.

The second thing to consider, and to me the most important one, is the cost/benefit and here, again, IMHO, it fails miserably. At US$ 100-110 per USER, I cannot understand how anyone can justify such solution, considering Quest’s EOP does offer similar (if not better) capabilities in terms of RDP enhancements PLUS a lot more on the RDS SH side. And if you stretch your budget you are now in Citrix XenApp territory and its ICA protocol what does work great indeed.

Resuming: Blaze does work but it is not the silver bullet and may not be that great under certain conditions. Plus it costs. Way too much for my wallet.


7,607 total views, 2 views today

RemoteFX First Impressions

As I did not have much time to test RemoteFX extensively, here are the first impressions of it and how we got it to work.

First of all, you MUST get a compatible video card. Not everything will work with Windows Server 2008 R2 with SP1 with Hyper-V, so you can get your Windows 7 VMs (with SP1 of course) working with RemoteFX.

I posted about it before. You can read the list of supported video cards here.

What did we get?

– HP desktop with a six-core AMD CPU and 8GB RAM.
– FirePro 5800 Video Card (also tried the unsupported Quadro FX 580 that by the way, does work too).

Initially I simply tested the Windows 7 VM connecting from the Hyper-V host itself but later got another Windows 7 SP1 box and used that one to connect to the VM.

Performance is decent I must say. I tried playing some Windows Media HD videos (make sure you disable multimedia redirection by using videoplaybackmode:i:0 in the .RDP file (save the RDP connection to the desktop and open it using Notepad). Also very important that you set the policy for RemoteFX (as I was not sure where to set it, I set it both on the client and on the VM itself). It is described here:

To set the experience index for connections using RemoteFX

  1. Log on to the client computer as a member of the local Administrators group.
    Click Start, and in the Search programs and files box, type gpedit.msc and then press ENTER.
  2. Navigate to Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostRemote Session Environment.
  3. Double-click Set experience index for connections when using RemoteFX.
  4. Select the Enabled option.
  5. In the Screen capture rate (frames per second) box, click Highest (best quality), and then click OK.
  6. Restart the client computer.

The key thing to understand here is, why you may need RemoteFX. For example, during our tests, playing the WMV-HD tests, it used up to 30MBits so as you can see it is VERY bandwidth intensive. For comparison, running Google Earth in DirectX mode used around 9MBits. So basically the bandwidth will of course depend on the application being used. The same for how intensive CPU/GPU utilization will be.

I would expect applications like AutoCad to use way less bandwidth than something like WMV-HD and what we will be testing next is actually using RemoteFX over a typical home (cable/DSL) connection, simulated in our lab. By typical I mean a 10MBits down/1MBits up with 40-50ms latency and some packet loss probably in the 1% range (or a little more due to bursty loss). Given the first results we have seen, I am confident RemoteFX can indeed work over the WAN (at least bandwidth wise) depending on the applications.

Yes, before Brian Madden sends me a tweet or leave a comment here saying ‘MS says RemoteFX is LAN only’, I still want to make the point that IMHO, anything that is LAN only has its fate determined already. DOA. See my post about this here.

And still on the performance side, what we have seen in a nutshell is this: RemoteFX does work great BUT it is NOT the same as local. Simple things like Flip3D (using Windows key + Tab) are NOT as smooth as running them locally. Even Google Earth (that works just fine by the way) is NOT as smooth. But they both work and work fine, considering you are over RDP. For a BETA release we can expect it will be tweaked and improved even more before it hits the market.

As a sidenote, keep in mind there IS a bug on SP1 that throws a message on the RemoteFX event log about CPU encoding being used for ATI cards. It is a known issue and has been fixed apparently on later builds, what of course I have no access.  But for 1 VM testing like we did (I am after experience testing and not scalability – I will leave that to people with more time and resources on their hands like Ruben and Benny 🙂 ).

As soon as I have more results and some nice videos to show RemoteFX, I will post these here.


4,472 total views, 1 views today

LAN only protocols for VDI. DOA?

As promised (I know, late) here are my thoughts on the topic.

It all started when Brian posted on twitter that he was testing RemoteFX with Gabe and I replied saying they should test it with loss. He replied pretty much implying ‘are you nuts? MS is saying RemoteFX is LAN only’ to what I replied ‘WAN is the new LAN so you should test it with loss’.

The reason I mentioned RemoteFX is simple and we must go back a couple years (maybe a decade) to understand what I mean and why I do think ‘LAN only protocols for VDI are Dead on Arrival’.

If you remember (and I clear remember this, back in 2003/2004 when I was working in Japan, accessing my machine over a dial-up connection) years ago all many people had was a dial-up connection to the internet. Things were ‘slow’ at the time and everyone wished they had a much faster connection one day. The idea of having a 1MBit connection, only for you and at home or in a hotel was simply a dream. Everyone though when that day came, all our needs would be solved.

So fast forward a couple years and now, if you are cheap, you are probably using some ‘high-speed lite’ plan from your ISP that is almost certain, at least 1Mbit down/256kbps up. Considering all you had years ago, this should be great, more than you need.

As we both know, this is not the case. Your 1MBit connection is slow. Freaking slow. How come? Well as we can easily see, with more available bandwidth comes all sorts of new technologies like movie streaming, P2P file sharing, rich multimedia experience (from websites, from VDI hosted desktops and so on), etc. The list goes on.

That shows us clearly, no matter how much bandwidth you get in the next couple years, technology will find a way to use it. Either because you will be downloading BluRay2 movies (at 500GB each) or because you need your USB 4.0 WebCam running at 3840×2160 resolution, when connected to your XenDesktop 7.0 hosted desktop (running Windows 9 with 64GB RAM and 32 vCPUs – note it will still boot Office 2015 as fast as a Windows 98 with Office 97 – see Claudio’s Law).

And as we get more and more connected I can only see ‘remote’ workers growing. People that want to work from home, from anywhere and also companies that will start to reduce their office space (that is costly if you do not realize) by giving users what they need at home or anywhere they decide to work from.

That leads us to what I posted on Twitter. The WAN will become the new LAN.

If that is the case if more and more work is shifted to the outside (your home, your cottage, a hotel, etc) are LAN only protocols for SBC/VDI dead?

I do understand that as of today the ratio of users working in a LAN connected desktop and on a WAN connected one is probably 20:1 if not more. But again, is this what the future holds? Will we ever see a shift on this that may bring this down to 2:1 maybe? And if that happens, what future a LAN only protocol has? Type-1/Type-2 hypervisor solutions may alleviate this but again, there may be cases where I do want to work ‘connected’ to my hosted desktop and not from a locally cached copy (i.e. what if I can assign 64GB RAM/32vCPUs to my hosted one instead of using 8GB/2vCPUs for my locally cached one? It will for sure be MUCH faster for several tasks and a reason for me not to use the cached one).

My take on this is, for now, RemoteFX and any other LAN only solutions will do it and will of course help the adoption of a VDI model on the LAN. But as we shift towards an always connected model, if anyone tries to sell their stuff as ‘Good on LAN only’, that will become an issue.

So Microsoft and Citrix, make sure you keep in mind WAN is the new LAN and that whatever crap you develop or acquire in the future has a future on the WAN.

WAN is king.


1,700 total views, no views today

Packet Loss Reduction. How we do it.

Now that our BETA program is open (please join it by emailing us at BETA at IPeakNetworks dot com) of course I keep getting questions on how our solution works, what is required and so on. So here you have it, right from the source.

First of all, as mentioned before we are completely protocol agnostic. We do not care if you are PCoIP, ICA, RDP, RDP with RemoteFX or even if you are doing video conferencing only. Our solution works in all cases as we are at a lower level.

Secondly, the solution exists in two forms: a software driver (for Windows XP/Vista/7, Windows Server 2003/2008 and Linux at this stage – yes, no Mac OS X until the market shows us it makes sense) and a hardware appliance (in this case it can be physical or a VM – we are working on having it ready for ALL major virtualization platforms, ESX, XenServer and Hyper-V). The two ends being protected must of course run our solution.

So let’s see a couple examples. One would be a field worker with his laptop running our driver, connecting back to the main office where our appliance sits. Anything going from his PC to the appliance will have the packet loss reduction in place. So if he hits a XenDesktop, XenApp, video conferencing, whatever solution that is now behind our appliance (that is really a bridge, not routing anything), he gets protected. Another example would be a remote office to main office connection with two appliances, one on each end. Easy enough?

Now, the main question everyone is asking is “How the hell do you do it?”. Here is the quick explanation (well not so quick).

Basically it works by first monitoring network flows. Then, when it detects a flow that can benefit from protection against packet loss, it adds a non-disruptive beacon to the flow. This beacon has no impact on end-devices but is detected by other IPQ systems. When our system detects a beacon from a far end system, it knows that it can communicate directly with that the IPQ peer.

All communications between IPQ pairs including control and data messages are inserted directly into the existing network flow in a manner that is entirely friendly to NAT and firewall systems. With both peers of the IPQ ‘pair’ connected and communicating, there is a negotiation session to determine the best way to protect the network flow based on the following analysis:

  • Current Network Conditions. How good or bad is the network at this moment?
  • Application Sensitivity to Loss. How much loss can the network application tolerate before the quality of experience is impacted?
  • Packet Size. What size are the packets in this flow?

Using the results of the analysis, IPQ divides each packet, one packet at a time, into the optimum number of segments. An extra segment is also generated to provide protection for the other segments. Should an original segment fall victim to packet loss, the extra segment is used to recreate it.

One more thing worth mentioning is our Real Time Optimization techniques.

The IPQ peer on the receiving end of the pair is able to recreate the original packets as long as enough of the segments are received. By comparing the number of segments received to the number transmitted, the receiving IPQ peer is able to detect changes in network conditions. Those changes are communicated to the transmitting peer as they occur and the level of protection applied to the network flow is adjusted and optimized in real time. This critical monitoring function is ‘always on’ but when network conditions are excellent, IPQ suspends the protection function and no extra segments are created. Monitoring continues, however, and IPQ is ready to apply optimum protection when network conditions deteriorate.

And again, this is all truly Plug ‘N’ Play. If you are coming to Synergy, PLEASE I ask you to join our BETA and stop by to see the demos we will have ready to go! I am sure you will be impressed.


989 total views, 1 views today

RemoteFX, PCoIP, ICA in a WAN world.

Last week as you all know Microsoft announced RemoteFX, the name for all the work/technologies they acquired from Calista a couple years ago (amazing how long it took them to get here. Subject for another post). All nice and great for VDI and I am certain, with the licensing changes announced as well, it will help the industry moving forward towards the adoption of such model in a larger scale.

The main problem now is simple. As Shawn Bass mentioned on Twitter, ‘WAN is King’. And that is definitely true. With the rise of mobility, either on mobile devices like the iPhone/iPad or on full blown PCs connected through 3G cards, several companies do rely on these to connect back to corporate and more than that, are willing to expand such option for an ‘always connected’ solution. The problem is, once you hit the 3G/EVDO data network, latency and packet loss will be there. Guaranteed.

The end result is a much worse experience over the WAN, no matter what kind of magic Citrix, Microsoft or VMWare have as of today. Throw Riverbed and all other products like that to the mix too. They do help. But again, once packet loss/latency is there, they are also in bad shape.

That is where we come to the picture.

After years of development, we now have a hardware (appliance) or software solution (driver) that you can mix (HW-HW or HW-SW or of course, SW-SW) that drastically reduces packet loss (typically to 1/10 of what you had before using us – so to 0.5% if you had 5% loss before) and makes life on the WAN much easier for all the things mentioned on the title of this post.

The good news is this is a mature technology that we developed and that has been in use by some large people out there (no names at this point) for other things (video conferencing mostly) with impressive results. But once we realized how much we could do for SBC/VDI, after testing it internally, we decided to take it to the public, to validate and prove the results we have seen with RDP, ICA, PCoIP and other things. So our BETA program is officially open as of today.

If you are interested on testing our solution, all I ask is you to email us at BETA at IPeakNetworks dot com and of course let us know about your environment so we can assist you on how to get the most out of it. And yes, I do ask you to provide honest feedback. What you have seen before and after. Good or bad. We are here to listen.

For now we do not have our SW solution ready for all platforms but it is in the works (it is Win32/Linux for now) and the HW one we should have available as virtual appliances for all major virtualization solutions (VMWare ESX, XenServer and Hyper-V) shortly.

I do think the VDI battle will be decided on the WAN. Vendors, no matter which one, do realize that but may not want to say it, especially if whatever protocol they have sucks on the WAN. Again, with high speed wireless available everywhere it is just natural that more and more employees will be indeed connected to their desktop/session over a wireless connection. So the WAN is the battle ground. Period. 

We are the ammunition.


11,617 total views, no views today