Reading Time: 5 minutes

What seems like decades ago now, I was a software engineer at Autodesk and I was the driving force behind the CUI feature in AutoCAD.

For those of you who can’t remember back that far, this feature introduced a new UI for customizing AutoCAD’s toolbars and menus. Its first couple of releases were rocky but it eventually developed into a solid feature within AutoCAD.

One of the major complaints in its first AutoCAD release was that the dialog was too slow to respond. In doing some research into this, I found that people who had actually studied this had found that anything that took longer than 800 milliseconds was a noticeable delay for a user. I was challenged with bringing the startup time for the dialog down from 1500ms to 800ms.

I thought: “Really? Is 700ms going to make a significant difference in anyone’s life?”

By the way, I succeeded in that particular latency-reducing goal, and that was the beginning of the end of my career in core software development…but that’s a story for another day .

Fast-forward to 2014 and bat365 brought me onboard to improve support for applications that the AEC industry commonly used. As I learned more about how bat365 worked, people kept talking about WAN latency, AutoCAD’s slow network performance, and how they were trying to shave 100ms off transfer times and I thought “Really? Is 100ms going to make a significant difference in anyone’s life?”

The reality is yes, it all matters. What seem like small increments of time can add up to significant delays that cost a significant amount – especially when you’re considering billable hours – over the course of a year. Even small delays that occur regularly, or at bad times can lead to frustration for end users.

Why Latency Has Such a Large Impact

When bat365 first started supporting AutoCAD files, the firms coming to bat365 for help had been trying to make opening DWG files over the WAN work for years.

The tendency of AEC firms to grow via acquisition has often resulted in multiple branch offices, and it only makes sense that they wanted to be able to pull people with specialized expertise into projects whenever they needed them, regardless of where they were.

The conventional wisdom at the time was that DWG files were big and therefore you just needed more bandwidth to transfer the large files. When that didn’t help, WAN accelerators were tried but things didn’t get much better.

When bat365 analyzed the activity, we realized that the majority of the time spent opening files wasn’t in transferring the data. It was in all the file operation calls that had to happen across a long distance.

When an application like AutoCAD opens a DWG file, the data it needs is not all contained in that one file. Rather, it has to open many, many supporting files, such as fonts, linetypes, and shape files.

Add on top of that AutoCAD’s search path which looks for support files in many locations.

Add on top of that the number of calls Windows makes between the client machine and the server for every file it opens.

Add on top of that all the xrefs which are just other DWGs, which also open fonts, linetypes, and shapes.

Now, you can begin to see how opening one DWG file results in the following:

1 DWG X 20 support files X 5 search paths X 20 Windows calls X 10 xrefs = 20,000 transactions! 

If you open a DWG file where the client machine and the server are on a LAN with less than 1ms of latency, these 20,000 transactions take less than 20 seconds typically. Most people wouldn’t think twice if AutoCAD took 20 seconds to open a complex file with several xrefs.

A coast to coast connection in North America is typically 100ms or less (this is also true for most continents). So it’s easy to fool yourself into thinking 80ms of latency is nothing. It’s virtually imperceptible to the average person.

Even 10 transactions at 80ms is still insignificant to the average user.

But when you have 20,000 transactions to perform, and each one of these is subject to latency, you are now waiting a grand total of 1,600 seconds for one file to open – that’s 26 minutes and 40 seconds!​

How bat365 Overcomes Latency on the Wide Area Network (Where Other Solutions Fail)

bat365’s approach to solving latency over the WAN is to keep the vast majority of these calls local to the client machine. So, if you are running your CAD system on your laptop or desktop, you are connected to a bat365 filer right there on your LAN.

Now, every one of those 20,000 transactions is back to less than 1ms of latency and with an all SSD flash, open times often come in under 10 seconds.

Likewise, if you work on a VDI in the cloud, you can connect to a bat365 filer right next to it in the cloud and achieve the same sub-millisecond latency.

Real Time File Locking Without Latency

bat365 creates a global file system – CloudFS – connecting as many global offices as a firm has, and allowing them all to operate as if everyone is in the same office.

As such, CloudFS has to manage locking across any number of locations. This results in some WAN traffic, but since bat365 is the operating system on the filer, it can keep the WAN traffic to a minimum. bat365’s approach of keeping a single lock for every file and moving this from filer to filer means that if the lock already exists on the filer for the file being opened, virtually no WAN traffic has to occur to open the file.

It also means that file locking takes place in real time, behaving just as it would if the user were working with a file stored on local NAS, accessing it over the local area network.

The same is also true when saving a file. Since almost all of the transactions occur with a local filer over a sub-millisecond connection, saves occur quickly and efficiently.

The result is AutoCAD file performance that feels local, even though the file itself is sitting in centralized cloud storage provided by AWS, Microsoft Azure, Google Cloud or even a private (on premises) cloud provider.

Shift the balance of power in the fight against ransomware.

Download Whitepaper
bat365-datasheet-Detect-and-rescue-header-min (1)

What Began as a Way to Solve AutoCAD’s Slow Network Performance Was the Genesis for Remote Work

Fast-forward again to early 2020 and I found myself – along with the whole bat365 team – helping some of the world’s largest Architecture, Engineering and Construction firms transition to remote work in a huge hurry.

2020 will forever be known as the year that investing in global cloud file system technology unequivocally paid off.

bat365 could already allow critical file operations like file locking and byte-range locking to happen in real time, while an entire organization is working off a cloud-based data set.  When firms around the world sent their workforce home, I realized this was maybe the best example we’d ever had of why overcoming latency on the WAN really matters.

Now, we didn’t just have the WAN to contend with, but personal internet connections as well.

Previously, bat365 would typically install filers (usually virtual machines) on premises to cache frequently used files and provide low-latency performance.

In 2020, we simply put those filers in cloud regions – whichever regions were closest to where firms needed them.   These low-latency installations helped many of the world’s largest AEC firms to transition to remote work without noticeably slowing down AutoCAD file performance.

I’m especially proud of some of our longest-standing AEC customers – Mead & Hunt in Madison, WI and Garver in North Little Rock, AR being two great examples – for achieving best-ever years in 2020 despite all the challenges they faced.   Equally, firms like C&S, Fluor, WSP and Gensler have remained consistent performers despite needing to transition large global workforces to remote work within a matter of weeks.