Teamwork experiences..S/R times with large files
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 03:38 PM
I'm curious about other's experiences with Teamwork. I'm on the IT side of things and am supporting a group of ArchiCad users using Teamwork with a file in the 150MB range for a large project. The endusers are using high end dual cpu XP workstations, minimum 2GB RAM, gigabit ethernet, local, optimized libraries, latest ArchiCAD SP's, and are seeing 10-15 minutes minimum for Send-Receive to complete. It's quite a thorn in my side.
What do you see in practical use? What are your best practices with Teamwork?
Thanks!
-Adam

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 04:06 PM
1Adam12 wrote:I went through this about a year ago on a file of comparable size. I was working on the project as well, and these seemed to work.
Hi,
I'm curious about other's experiences with Teamwork. I'm on the IT side of things and am supporting a group of ArchiCad users using Teamwork with a file in the 150MB range for a large project. The endusers are using high end dual cpu XP workstations, minimum 2GB RAM, gigabit ethernet, local, optimized libraries, latest ArchiCAD SP's, and are seeing 10-15 minutes minimum for Send-Receive to complete. It's quite a thorn in my side.
What do you see in practical use? What are your best practices with Teamwork?
We came up with a set of rules to regulate the problem, since it did not seem fixable:
1) Keep the staff working on the same tasks as much as possible. This could keep someone in the same workspace for several days.
2) Figure out what workspace users will need for the next 4 to 8 hours. Users should not need to change workspace more than once per day that way.
3) Save your changes to the "Local Draft" format (PLC) whenever you feel like but preferably to your local drive since it is faster than saving 150+ MB over the network.
4) Only Send & receive when changing workspace. (if they follow Rule 1, that's once per day).
5) Stagger the Send & Receive times, so some people are saving at 4, some at 4:30, some at 5:00, etc.
6) If someone will use the same workspace the next day, they do not sign out at the end of the day.
Yeah, it was a pain, but it cut down on a LOT of lost time.
We also tried dividing the file up a bit, so some of the non-model stuff like typical details, the cover sheet, and some other things were in a separate PLN file. You couldn't use automated detail linking, but it was a small price to pay.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 04:54 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 04:57 PM
r wrote:We have the same problem on Apple OS X / OS X Server. For 150 MB file, it takes about 10 to 15 minutes to Send & Receive. I think the S&R/Teamwork function just slows down as the files get bigger. I mapped out the process once, watching the scratch files build, then the originals get moved to the Backups/ folder, then the scratch file get renamed. S&R with a Workspace change added one more file scratch file recreation, if I remember right, so you were essentially moving three 150 MB files over the network to complete the process.
hmmm we have this problem alot....my gut feeling this is an xp issue and could be related the lck/scratch files created during the process...quite often I have to purge the network of left over scratch files....in addition...the scratch file is not associated to anything and we all know how possessive bill gates can be
There was an article on Archiguide about the scratch files a while back, that may be related to your problem:
I suspect you may have a different problem, Rob (aside from the obvious ones we already know about
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 06:01 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 06:11 PM
Keep the experiences coming! Much appreciated!
A
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-06 07:19 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-07 06:00 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-08 06:20 PM
Of course all projects cannot be cut up this way but there seems to be a reasonable and manageable solution somewhere.
Lew Bishop
AC 9 2219
OS X 10.6
Dual G5 2.0/ 4GB/ nVidia 6800/ dual 20" Cinemas
Gigabit
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2006-04-08 06:55 PM
LewBishop wrote:Lew,
It appears that we are all experiencing similar slow down conditions.
Have you guys upgraded your server and network yet? Is it slow over Gigabit or are you still using the eMac?