C4R connection and best practices
Accepted solution
@Anonymous wrote:
Hi,
We are currently using C4R and we are having slow syncing and download takes a lot of time. We have 50 users working and let say 2GB of file together with the links and different projects. Also currently all routes re-routed to the 30MB connection via sydney with like 300ms latency pinging s3.amazonaws.com.
My questions are the following:
1. what will be a minimum internet speed per user?
2. what will be the best practice opening big file model with big links?
3. what do we need to do if the collaboration cache in the computer goes like 10GB or more?
3. what will be the best route to access c4r in the internet connection Location (Manila-Philippines)?
4. Is there a way we can have a one point connection to c4r, via ip address?
Hope you could help us,
Thanks
Llexis
- Each user should be able to ramp up to 5Mbps symmetrical at minimum. That's not a constant bandwidth, but when transacting with C4R services as part of cloud worksharing operations. For your project size though, you'd benefit from being able to hit 10-15Mbps.
- Open it and let the services do their thing. The first load will always take a while, as Revit is downloading the binary chunks of host + links and putting them into the collaboration cache. Make sure you;re not clearing that cache for some reason, and that you are all running the Revit Accelerator service, and subsequent open operations will take dramatically less time.
- The best thing you can do is make sure you are routing C4R traffic to the open internet from your site. AWS CloudFront edge caching will pull down data from the closest data center.
- These domains are what's used by C4R. There is definitely not a single IP address that you can route through, as the services nodes are frequently being refreshed under normal operation. The domains are the only thing static.
-Kyle
Kyle Bernhardt
Director
Building Design Strategy
Autodesk, Inc.
@Anonymous wrote:
Thanks Kyle,
From the ramp up to 5mb, can you please elaborate more?
Existing user is 40 users, we do have a 50mb direct internet connection with a 230ms latency for AWS which is normal for all I think. I notice on my monitoring for our connection is it didn't ramping up or its not getting a lot of usage, its like getting only 10mb connection for all users from the 50mb connection and the guys are slow downloading and syncing. I'm pretty sure its not the connection or the unit having issues, they are perfectly fine.
Is there a way I could check C4R connection or how much usage are getting per each computer for c4r?
Thanks
Llexis
Llexis,
Sure, glad to elaborate.
The "big" transactions with C4R services happen in 2 cases:
- Prefetching data via Revit Accelerator -> This is the highest frequency situation, as in most cases the Accelerator grabs the necessary binary deltas ahead of when Revit actually needs them. These deltas are what's needed during the Reload Latest operation that's shared between the Model Open and Sync With Central commands.
- Major File Operations -> This is what most folks think of as the major file transfer operations. In truth, if Revit Accelerator has done its job effectively, in many cases the transaction itself is a lot of small transactions with C4R services + model regeneration of the new changes from others (the big chunk of the work in practice) + the upload of the deltas representing the changes.
The one exception to this is the "cold open" scenario, when a team member is opening a model for the very first time. In that case, there's a significant amount of data transferred, as Revit is technically downloading the Element Streams (binary chunks) for the Host + Links and assembling them. On my end, we've seen Revit pull 70Mbps during that operation, so we know the services can scale up to some serious bandwidth.
So when I referred to "ramp up" to 5Mbps, I'm talking about any of the above cases when Revit itself needs to transfer these binary deltas to or from C4R services. Since the files themselves are actually pretty small (~3MB), often times they transfer quickly enough that something like Windows Task Manager doesn't register the actual file transfer rate, since Task Manager displays a running average over a time period, rather than instantaneous transfer. Nonetheless, you want to have the best bandwidth for those transfers when they are required.
As for tracking bandwidth usage, something like NetBalancer can do that nicely. If you'd like us to look at a transaction to identify what component is taking up all the time, post a Revit journal and we can take a look.
Cheers,
Kyle
Kyle Bernhardt
Director
Building Design Strategy
Autodesk, Inc.
@Anonymous wrote:
Cool explanation, thanks.
Please see attached Journal file. There are 2 logs. (Speed is ramping up to 3.4mb but not consistent)
1. Initial download with error ( its downloads more 2 GB of file and links) then suddenly crush with attached error
2 Second open but no error and it tool like 5 minutes to open
*questions
a. Is it normaly happen to crush for the first download of file? Its always happen more often
b. Is it ok to synced at the same time and whats your best practice when syncing. (Sometimes its Sync failed)
c. They checked it on the communicator but not being used always, is there an app that always advise whos syncing?
Regards
Llexis
Llexis,
Thanks for posting that Journal, very helpful. Looking through it, that crash happens when Revit is drawing the "Starting View" after the C4R Model Open work has been completed. That completed without error, so this is a core Revit issue as opposed to C4R-related. It looks like the "Starting View" is a View used for Navisworks export, which means it's likely very complex. You might want to consider a much simpler view as the starting view, which should shorten Model Open durations significantly.
As for the crash itself, the journal captures the failure signature, but it's generic enough that we'd need to review the crash report to know for certain what caused it. Can you confirm what email address you used when you submitted the crash report? Having a crash is definitely not normal.
In the absence of the crash report, I can speculate that the root cause is tied to the limited RAM on your machine, which appears to be 8GB. Given the size of the host + linked models, you're likely requiring the use of the SWAP file on the hard drive, which is dramatically slower than RAM.
In regards to your 2nd question, it's a best practice to avoid trying to SWC at the same time. I'm not aware of any situations where that would cause the SWC to fail, but it can result in one of the team members having a really long SWC time. That's what the Communicator is intended to help avoid, but as you mention it requires that everybody keep it running while working in the model.
-Kyle
Kyle Bernhardt
Director
Building Design Strategy
Autodesk, Inc.