topic Re: Teamwork experiences..S/R times with large files in Modeling

Teamwork experiences..S/R times with large files

Anonymous — Thu, 06 Apr 2006 13:38:23 GMT

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?

Thanks!

-Adam

Re: Teamwork experiences..S/R times with large files

TomWaltz — Thu, 06 Apr 2006 14:06:07 GMT

1Adam12 wrote:
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?

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.

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.

Re: Teamwork experiences..S/R times with large files

Anonymous — Thu, 06 Apr 2006 14:54:46 GMT

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

Re: Teamwork experiences..S/R times with large files

TomWaltz — Thu, 06 Apr 2006 14:57:03 GMT

r wrote:
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

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.

There was an article on Archiguide about the scratch files a while back, that may be related to your problem:
http://www.graphisoft.com/support/archicad/archiguide/StrangebehaviorofACscratchfiles.html

I suspect you may have a different problem, Rob (aside from the obvious ones we already know about 😉 )

Re: Teamwork experiences..S/R times with large files

Anonymous — Thu, 06 Apr 2006 16:01:49 GMT

now that's kinda weird .... we don't get a *.SCR extension.....it will be scratch_12345678....but it will be random numbers....and of course I have problems...it's not like I am going to camden everyday...I mean really.....

Re: Teamwork experiences..S/R times with large files

Anonymous — Thu, 06 Apr 2006 16:11:51 GMT

my understanding from Graphisoft is that they changed from using the .SCR with ArchiCAD 9, but that they still strongly recommend excluding the local scratch areas from *any* AV scanning.

Keep the experiences coming! Much appreciated!

A

Re: Teamwork experiences..S/R times with large files

Anonymous — Thu, 06 Apr 2006 17:19:11 GMT

see I can't buy the whole "turn off your virus scans"...the first thing I do with my personal pc's is strip the scanners off the machine....so my laptop has no scanner...but still the scratch files sit there....

Re: Teamwork experiences..S/R times with large files

Anonymous — Fri, 07 Apr 2006 16:00:40 GMT

i'm not advocating removing all av scanning - and archicad wouldn't be alone as an app that would take a performance hit or have problems from an av scanner constantly hitting it's scratch file activity (photoshop, anyone?)

Re: Teamwork experiences..S/R times with large files

Anonymous — Sat, 08 Apr 2006 16:20:37 GMT

It appears that we are all experiencing similar slow down conditions. The solution that we are working for a current project - a 142 unit multifamily live work project - has been to break the project into managable chunks that relate vertically into the overall project. The unit plans in one file, moduled up to a building that is half the project and other units relative to the other half of the project and then both halves linked to the overall site. We are TW in each of the unit files and the building files and typical S/R times are very managable. The stick comes with the site plan and the LBK as save times are like 10 min +. It seems that the biggest hit is when we try to work over the network - even for short edits that the time increases. Local drafts are, other than the usual file management issues, the only way to maintain sanity.

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

Re: Teamwork experiences..S/R times with large files

Anonymous — Sat, 08 Apr 2006 16:55:04 GMT

LewBishop wrote:
It appears that we are all experiencing similar slow down conditions.

Lew,

Have you guys upgraded your server and network yet? Is it slow over Gigabit or are you still using the eMac?

Re: Teamwork experiences..S/R times with large files

Anonymous — Sat, 08 Apr 2006 22:23:46 GMT

We are in the process of upgrades - changed out the server to a dual 2 G5 and upgraded the main switch to Giga. All of the standard proceedures are much better. Thanks to Tom Walz for advice. We replaced several of the sub switches to Giga as well - so most of the file stuff is at that speed. We are also considering some file synching software to allow for the home working local drafts to work better.

File management as well as real rules and enforcement are the next bug-a-boo to hurdle. As most people have been working on single file elements, getting all (including me) to recognize the level of importance that maintaining the rules means - is the management condition of today and Monday too.

Re: Teamwork experiences..S/R times with large files

Anonymous — Sat, 08 Apr 2006 22:26:47 GMT

I apologize for the typing error misspelling Tom Waltz's name --

Re: Teamwork experiences..S/R times with large files

Anonymous — Sat, 08 Apr 2006 22:41:54 GMT

LewBishop wrote:
We are also considering some file synching software to allow for the home working local drafts to work better.

I think that's a good idea. I have found that file synching is the best way to make portable libraries & project folders and I have used lots of different programs with varying degrees of satisfaction.

On the Mac side, I recently started using ChronoSync (based on a recommendation here in ArchiCAD talk as I recall) and it is the best I've seen since EasySync died back in the mid nineties. It is amazingly fast and easy to use.

Re: Teamwork experiences..S/R times with large files

Anonymous — Sun, 09 Apr 2006 22:43:00 GMT

AaMoF I downloaded the demo and it works similarly to a program that I used to use on the Windows side.. Save-n-sync -- it was a very good program and worked really well both as one way and bi-directional. The bi-directional thing was the very best part as which ever part of each file was correct, the files were both made the same. Will get the Chrono and give it a go.

Lew Bishop
AC 9 US 2219
OS X 10.6
G5 Dual 2.0/ 4 GB/ nVidia 6800