Silver Peak gently corrected
Alan Saldich, VP for Product Marketing and Alliances at Riverbed Technology has written the following text in response to points made by Jeff Aaron, Silver Peak’s VP for product marketing. Alan is pictured below. Here is his text:-
Autodesk makes periodic changes to the widely used .dwg file format used by AutoCAD and many of their related CAD applications. In the 2007 release of the .dwg format, some of the changes Autodesk made in an effort to increase the performance of AutoCAD had an unintended side effect that reduced the performance of products reliant on deduplication.
What is the problem?
The problem is that in the new format, used in AutoCAD 2007 and 2008, when a user does a complete save (as distinct from a partial save – more on tat below), virtually every byte in the .dwg file is rewritten and scrambled, even if the user made no changes at all to the file. In the older format, if a user opened a file and made no changes, and then saved the file, virtually 100% of the bytes in the file would remain the same, and products like Riverbed’s would deduplicate it quite effectively.
The effect for a user is that a save across a WAN using WAN acceleration appliances can take 4 to 5 times longer with AutoCAD 2007 or 2008 as compared to earlier versions. If the files are small it’s no big deal, but with larger files a save can go from 30 seconds to several minutes, or from a few minutes to 10 or 15.
When does this problem occur?
The issue is only relevant during a complete save (a write to disk) as distinct from a partial or incremental save. In AutoCAD, there has long been a feature called “Incremental Save Percentage” (ISP); if users retain the default ISP setting of 50 (on a scale of 0 to 100), then upon a save, only the incremental changes will be saved and the problem described above is minimized. However, many users prefer to use an ISP setting of 0 to ensure that a complete save is done every time they hit “save” in order to avoid possible file corruption.
Does this problem only affect Riverbed?
No, this issue is caused by the way data is written to disk in the complete save operation – before any data is “seen” by Riverbed’s Steelhead appliances (or any other vendors’ appliances). Therefore, any Wide-area Data Services appliance that is looking for repeated byte patterns won’t find any if the user (1) is writing a file across a WAN through the two WDS appliances, (2) did a complete save, and (3) has the ISP set to 0.
There are many use cases where this is not an issue. For example:
- saves to a local file share are not affected
- reads are normally not affected if the file has been written (saved) once across the WAN (because the bytes comprising the file have been seen by both appliances).
- If the ISP is set to 50, most users won’t notice
What else is affected by this issue?
Any product that relies in finding byte patterns in order to save WAN bandwidth, backup resources or disk space would be affected to varying degrees. As CAD files get larger, in many cases now exceeding 100 MB with 3D files, a system that scrambles bytes upon save will generate new data all the time, whereas other formats would be able to be optimized by deduplication technology, which is used in many solutions in categories such as:
- Wide-area Data Services appliances (a.k.a. WOC, WAN Optimization, Application Acceleration, Wide Area Application Services or WAAS)
- Backup / replication systems
- Secondary storage optimization products
- Primary storage solutions
What are Riverbed and Autodesk doing about it?
The two companies are cooperating. Since Riverbed is the consensus leader in the WDS market, we have taken the lead in working with Autodesk to document the problem and work jointly with them to look for a solution or workaround. Both companies have posted the following statement on our respective web sites. Here is Autodesk’s link:
VP Product Marketing and Alliances, Riverbed Technology.