XM Geopak slow over VPN

Hey all,

Has anyone else had an unpleasant experience using Microstation XM and Geopak over a VPN? 

 Well through trial and error we have determined that the main problem lies with the GPK file.  If two indivduals working remotely off of the server access the GPK file using the plan view and labeler tool, the reponse times vary from 3 min to a complete seizure of Microstation.  Sometimes followed by a not responding error from Microsoft, and then you have to end the program.  We have lost microstation elements in DGN and REF files several times.  Elements that have been in the drawing for many months.  I'm not sure why we would randomly lose elements in our drawings.  Anyways luckily we had back ups. 

So for now we are copying the GPK file to our local servers to use for referencing only.  Any time someone needs to make a change in the GPK, they can do so on the remote server.  Then everyone has to update their local gpk files.  Everything seems to work great like this other than the tedious and dangerous method of having mulitple GPK files. 

I have looked into the VPN network configuration and everything seems to be fine.  I used a networking analyzer to watch for packet losses, which there are none.  I also checked our computers TCP settings to see if our maximum transfer units are configured properly.  No problems there.  So the problem in my opinion is with the GPK file. 

 Is there a way to tweak Geopak or Microstation to allow us to comfortably work with one GPK off of the remote server?  Is there anything we can do to make working over the VPN with Microstation and Geopak better?  Why is there a bottle neck for only allowing one person to work effectively with the GPK file?  Why would we lose elements in a DGN from a program crash while working over the VPN?

I hope the new V8i is much better for working over the VPN!  Last I heard they got rid of the GPK file.

 Thanks ahead of time! 

Parents
  • By default, most servers have Opportunistic File Locking turned on by default.  This causes slow-downs in accessing the GPK because of the way the GPK is accessed.  The delays are exaggerated to the bothersome levels you report when using remote access across wide area networks.

    Turn off opportunistic file locking should alleviate the problem.  You will probably have to have the system administrator make this settings change.

    Robert Garrett
    Senior Product Engineer
    Bentley Systems Inc.



  • Thank you for the suggestion Robert!

     I disabled the opportunistic locking for the remote server by following the instructions on this webpage.

    http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

    Microsofts instructions are here, which included similar details to the data access website.

    http://support.microsoft.com/kb/296264

    We tested the connections again by using the plan view and labeler.  I felt like it was alittle better.  Instead of  a 3 min delay it was only about 30 sec or more. Still a little annoying. Others still reported having significant delays.  One user is running Vista Premium.  The rest of us are running XP pro.  It didn't look like you can disable the locking in Vista.  So the Vista user might just be sol.   

    I'm thinking about disabling the windows clients request for opportunistic locking, and seeing if that helps too.  Thanks again Robert!

     Any other ideas to help improve the GPK file access over a VPN? 

     

  • Sorry, no other suggestions.  I am only aware of that one becuase it has occured for a number of our users working over wide area networks.

    It might be worth a call to technical support and ask to talk with someone familiar with remote access issues.

    Robert Garrett
    Senior Product Engineer
    Bentley Systems Inc.



Reply Children
No Data