A while back I posted about how to setup and deploy Collaboration for Revit. Things are moving quickly in this space, as more projects now need concurrent access to centralized models from a distributed team (say that quickly 5 times!)
Here is an updated list of a few best-practices for initial C4R project setup:
- generally its a good idea to do a Reload Latest before Sync with Central
- its best to be on the most current versions of Revit and their C4R extensions
- baseline all workstations to the latest ISV certified drivers, reinstall the C4R v6 components using the .exe installer and flush all 4 caches being – CollaborationCache, PacCache, Communicator, User Temp Dir. This will ensure all workstations are at exactly the same Revit environment.
- confirm that traffic to/from pubnub.com is successfully moving across your firewalls to/from the C4R workstations? That’s an important requirement for the Communicator panel; a key reliability and performance enhancement depends on this connectivity and without it the Communicator will fall back on an earlier implementation behavior which is known to be less reliable.
- ADSK recommends that all users should use the personal accelerator.
- To the best of each user’s ability, ADSK recommends self-scheduling SWC activity by using the Communicator timeline to avoid syncing when another user is syncing. See images below to help the team understand why this is important.
- The success of this project likely hinges on the team’s ability to develop a way to coordinate SWC activity, as poor SWC scheduling is responsible for the major pain point for project teams. It should also be noted that the most egregious cases of poor SWC performance are due to users failing to self-schedule their SWC activity. When multiple SWC operations are in-flight simultaneously, Revit must go through multiple RL phases to maintain model and data integrity. this has the effect of greatly expanding SWC time, which is why we recommend that users check in the Communicator panel to see if a SWC is already in progress before attempting one. See the attached pptx for an explanation of why this is important.
- Please review this Link here to understand the Proxy Server settings to unblock Autodesk A360 services
- Please use this Link here for Proxy Server and domain exceptions for A360
- The table below provide further information on minimum system requirements.
- Note the connectivity speeds:
Sync with Central diagrams
As you can see below, when SWCs ‘overlap’ there is a performance hit. Good C4R management will require:
- attempting to sync on a schedule… because modelling projects are easy to schedule, right?
- using the Communicator (or some other IM tool) to keep team informed that you are syncing / about to sync. You could use a Slack channel per RVT for this?
I have added the above information to the Best Practices section of the Revit Collaboration Public Help notebook I created:
Can you point me to the webpage/pdf where Autodesk suggests to “avoid syncing when others are syncing”?
My team believes this is only my preference and it would be good to have an “official” statement as well.
I’m not sure it is said explicitly on the Knowledge Base. But that document was a working document produced by some high-level Autodesk people. As you can see, it demonstrates why multiple people syncing at the same time results in more handshaking and a slower process, as Revit and C4R struggle to maintain the database integrity in a semi-transactional way.