Is your model is on the local shared drive? Or revit server?

Keep a tab on the model size. It shouldn't exceed 300mb.


Sent from my iPhone using Tapatalk Pro

I've heard Autodesk staff make that claim in support situations and it was mentioned in the last version of their best practices white paper that I saw a few years back. In that they cautioned that the least capable computer in a group that's active on a project can negatively affect the group as whole. I'd expect that disparity would need to be pretty pronounced to really be noticeable, but since you're asking...

Steve, the benchmark results (see images) of the slowest computer (5 year old T7500 w/ duel 2.13 ghz processors, 60 gb ram, 500HDD) pales in performance to the newer (T5810 w/ 3.10 ghz processor, 32 gb ram, 500 SSD). Currently we have upwards of 13 end users swc on one project with a mix of computers, including several older T7500's. In this case, could there be a revit server central model performance hit based on the slowest computer?

T5810 - 3.10 ghz processor - 32 gb RAM.jpgT7500 - 2.13 ghz duel processors - 60 gb RAM.jpg

Charles-

Since i was working this weekend, i pinged some smarter people than i (at Autodesk... Thanks for the info, Kyle), to see what they had to say. Here is what they came up with, in an unofficial conversation:

During minute to minute element borrowing (touching the elements while modeling, etc) its very unlikely there will be a noticeable degradation for other users due to one user having a slower computer. Element borrowing is very lightweight, computing requirement wise. But, that leaves the process of SWC:

SWC has a large overhead with regards to the CPU, because of the demands of Reload Latest. But here is where it gets interesting:

During a SWC, when you are pushing data TO the model, thats when other folks get the key (locked out) so they cant do work for a few seconds. But, the PUSH of data isnt the majority of the time of the SWC... Thats the Reload Latest. And how the RL behaves, depends on the type of worksharing:

1. Standard worksharing: Other users are locked out during Reload Latest, as well
2. Revit Server: Other users are NOT locked out during Reload Latest
3. Cloud Worksharing: Other users are NOT locked out during Reload Latest

All that to say, it doesnt "sound like" in my opinion, there would be a noticeable impact on the rest of the team. Since the majority of the *hang up* team members feel is during RL (which doesnt seem to tax CPU's all that much).

Thanks Kyle, for providing information about RABBIT. =) (Google speech-to-text never gets Revit correct... We both know the struggle is real... LOL)

To add a little more detail to Aaron's post above. The biggest "slow down" we've seen in support situations associated with relatively slower hardware running on Revit Server & Cloud Worksharing, is the Reload Latest loop. This happens if the "slow" machine - let's call this "machine A" - starts a SWC, which carries out a Reload Latest as the first operation.

• So long as the Accelerator is operating normally, it's likely that the new "deltas" from any SWCs by other team members is already "close" to the Revit session (on the LAN Accelerator in RS, or Personal Accelerator in Cloud Worksharing). So getting the deltas necessary usually is quite fast.
• The problem is the time that Machine A takes to carry out the RL operation. This is where model regeneration updates the model state in RAM based upon consumption of new binary deltas (Element Streams in technical Revitspeak). If another faster machine - let's call it "machine B" - starts SWC during machine A's RL operation, it's highly likely that machine B finishes first, and gets to the "commit" portion of SWC first.
• When the machine A finally finishes the RL operation, it double-checks to make sure that it just reloaded the latest data. In this case, it didn't, because machine B already made their new commit. So, machine A starts another RL operation.
• Compounding this in some cases is the close proximity of machine B's commit operation to the start of machine A's 2nd RL operation. The Accelerators probably haven't caught up yet, so machine A's 2nd RL operation now involves downloading the deltas from the host RS, or the cloud worksharing service; a longer operation.
• When machine A finishes its 2nd RL operation, let's hope another faster machine hasn't committed new data as well, otherwise it's a 3rd RL operation for machine A.

When we profile really long SWC durations in cloud worksharing, where have have good anonymous analytics data, we pretty much always find that the RL portion is where all the time is spent. In many of the cases where we have journals for those slow SWC operations - our analytics don't capture RL count at the moment - we see Revit doing RL a bunch of times, adding up to a long SWC operation.

So the moral of the story here is 1) make sure you've got a properly operating accelerator in RS and cloud worksharing and 2) having good discipline in SWC timing across the teams.

-Kyle

Thanks for the explanation Aaron,..and Kyle!
What I have noticed from the two computers in the bench mark is a difference of nearly 4 minutes in sync times to the same model. Encouraged that it does not affect the team directly though SWC, however, in a years time 4 minutes several times a day multiplied by several computers will add up. At minimum, I would say that 5 year old computers need to be replaced.