I recieved comment from Alan Saldich, the VP of Product marketing for Riverbed and below is his message. He told me basically that this is not a Riverbed issue, but an Autodesk issue, and that all WDS solutions are affected by the file format change. Here is his letter.
I’m the VP of product marketing for Riverbed, and I wrote a lengthy post yesterday on this topic, which can be viewed here:
Silver Peak has admitted (in a call earlier this week with the TechTarget reporter who wrote that article) that the issue with the AutoCAD 2007 / 2008 .dwg file format is *not* specific to Riverbed and *does* affect all products that use deduplication in their solutions, including their own.
The only way to determine the degree to which any particular WDS solution is affected by the file format is to do your own testing.
Remember, the problem is most pronounced with the ISAVEPERCENT (Incremental Save Percentage) set to zero, which forces a complete save, and which causes all the bytes to be scrambled. Using a non-zero value for that setting (like the default value of 50) reduces , but does not entirely eliminate, the impact of the new file format on WDS solutions.
Unfortunately this is not an issue that can be solved by Riverbed or any other WDS solution provider - it was caused (inadvertently) by the way Autodesk decided to change their file format, including scrambling the bytes on every complete save. Any product that tries to find duplicate data will be affected, possibly to a varying degree, but there is no doubt there is an adverse effect.
VP Product Marketing & Alliances
- I'd like to post my own response to this as Riverbed's VP of Product Marketing and Alliances. I know this is a frustrating issue for our customers who rely on us and on Autodesk, and that's why we did the webcast in the first place a few weeks ago - to explain the issue as best we could. I have personally been working on this issue extensively for the last few months, and especially in the last few weeks. Let me make a few points and give you all an update.We have worked with Autodesk directly on this and we know what causes the problem, and Autodesk agrees with us. It is definitely not specific to Riverbed. Let me be clear: There is absolutely no dispute about that. Autodesk has had developers looking into the issue with their new file format to see if there's something that can be done. Unfortunately as of this moment there is no immediate fix. The problem is caused by a rescrambling of the bytes in Autocad 2007 / 2008 files upon a complete save, and that causes "cold" performance on writes. Reading files across the WANReads are generally fast because if the file in question has been written across the WAN before, then the bytes have not been re-scrambled and the read is fast, as usual. However, if you have a highly collaborative environment where someone in the other office could open and re-save the file, in that case the second read across the WAN could also be slow (because the bytes are again re-scrambled).If users are using other versions of AutoCAD or Civil 3D that don't rely on the newer file format, then they are not affected. The rescrambling is not compression nor encryption - it is an inadvertent byproduct of performance improvements that Autodesk made in an effort to make AutoCAD work better (nothing to do with WANs at all).The only option right now is to leave the Incremental Save Percentage (ISP) setting at its default setting of 50 - that works much better than forcing a complete save. There's some confusion here about whether a setting of 0 or 100 is the one that causes the complete save, and we're trying to clear that up (anyone know for sure?).Several of our competitors (Cisco and Silver Peak primarily) are trying to take advantage of this issue by claiming that it is somehow specific to Riverbed, and that is where a lot of the confusion and angst comes from. Silver Peak has probably been the most aggressive on this front. Unfortunately, they have been wrong about (1) how Riverbed is impacted by this and (2) claiming that they are not affected by the problem. Silver Peak has conceded (yesterday) that (1) this is not a Riverbed-specific problem, but rather it's caused by the way .dwg files are written in the new format, and (2) their products are also affected by it.If you read their claims carefully, and after talking with them it became more clear, their claims that they work well with AutoCAD 2007 / 2008 are couched in terms of average deduplication rates across a range of ISP settings (remember the only relevant use case here is a complete save, not incremental saves), across other Autodesk products like Revit (again, not relevant because Revit does not use .dwg files and is not affected by this issue), and by including other irrelevant operations like FTPing the same file over and over (again, not relevant because the files are not re-saved and therefore the bytes don't get scrambled again, so you get "warm" performance). Just to reiterate again... the problem occurs only when you do a complete save.Silver Peak still claim to be less affected - we'll see if that's true and by how much). The only way to document that will be through publicly available testing of both products under the exact same scenario. We are working on that through a customer who has their products and we will publish the results as soon as we can. We have already completed testing with Cisco's products and Blue Coat's and we have demonstrated the same problem affects their products in almost exactly the same way. As for our products being 'bricks', I'm very sorry you feel that way. If you are having problems, I would like to help you set up a support call to make sure there isn't some other issue like a duplex mismatch or other networking-related issue.We have literally hundreds of architecture, engineering and construction companies all over the world who rely on our products to accelerate AutoCAD, including most of the large multi-site firms in the US. Overall, as of December 31st, we had over 3,500 customers in virtually every industry and over 40,000 Steelhead appliances in use, so it's hard to believe that this is a systemic problem. If you or anyone else on this board would like to talk to me personally, I'd be happy to. My email is email@example.com, and my cell phone is +1 650 888 4032.