Does syncing with central from a slower computer (2.13 ghz processor, 500HDD) adversely affect model performance when others syncing to the same model have a (3.10 ghz processor, 500 SSD)? My concern is the wait time of a slower computer may be affecting the performance of the model for the entire team.
Announcement
Collapse
No announcement yet.
Central Model Performance with Older Computers
Collapse
X
-
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...
Comment
-
Originally posted by Steve_Stafford View PostI'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...
Bettisworth North
Comment
-
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)
Comment
-
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.
-KyleDirector
Building Design Strategy
Comment
-
Originally posted by Twiceroadsfool View PostCharles-
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)
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.Bettisworth North
Comment
Related Topics
Collapse
-
Hi,
I work in a small 12 member architecture firm and often have been experiencing frustrating lag when working on work shared files and...-
Channel: Hardware and Infrastructure
October 16, 2012, 08:11 PM -
-
Dear Experts,
I was planning to build network for the File based work-sharing and need your suggestion (Central file located at network drive...-
Channel: Worksharing and Cloud Coordination
October 12, 2020, 08:35 PM -
-
Hello,
Is anyone leveraging RAMDISK for Revit Performance gain?
Thanks,-
Channel: Hardware and Infrastructure
June 19, 2017, 04:09 PM -
-
Hello everyone, recently we bought at the office some lenovo Thinkstation p500, Xeon CPU, Nvidia Quadro k5200, 32 Gb of RAM and 1 TB of Hard Drive (Which...
-
Channel: Hardware and Infrastructure
June 11, 2016, 05:52 PM -
-
Our Revit Server is located in Fairbanks and we have team members syncing to central from the lower 48 and Anchorage. My question would be, why is there...January 27, 2016, 07:12 PM
Comment