Very slow RP when editing "remote" Duplicate sets/scripts

[awnews]

Running Retrospect Pro 6.5 RDU 4.4.110 under XP SP1.

 

I'm using (actually *trying* to use, since it's failing miserably, see other post...) RP to Duplicate directories from a local harddrive on an XP SP1 PC to a remote Linux machine via Samba and over a T1. When I try to open a script and make changes (e.g. the schedule, the source or destination locations, option settings), it takes *forever* (in PC time. Often 30-60 seconds or more) to make changes to the local RP script.

 

Even though I'm going over a T1, which is much slower than accessing local drives or devices over a 100Mbps LAN, note that this is a *Duplicate* operation. There's no backup file, with snapshots, on the other end. What in the world is RP doing that is taking so long when I'm *just* trying to edit settings in the *local* script??

[awnews]

Would someone from Dantz please respond. Why, when editing a Duplicate script on a local PC when the Dup destination is on a slow interface, is the Retrospect (6.5 RDU4.4) GUI so slow? I just opened a script that Dups folders and files on a local IDE drive to a networked drive over a fairly slow interface. There are no snapshots involved and the RP config files are local (same IDE drive). It took a while to open the script and, after I made a minor change, it took *three minutes* to close after I told RP to accept the change. What is RP doing that's taking so long--it shouldn't be doing anything with a remote device when changing a local Dup-type *script.*

 

I don't see this slow behavior when editing *scripts* for Backup or Dup scripts where the source & destination are local or over a fast (e.g. 100Mbps LAN) interface.

[natew]

Hi

 

I think this happens because of windows networking.

 

I work via VPN connection to the home office in the US. I have 100Mb fiber connection on my end and I think there are 2 T1s at the home office. When I set up a dupe like you do I get the same sluggish results. I figur it is slow because I am 5000 miles away from the office.

 

I have some shortcuts set up on my desktop to network shares on the VPN. If I drag a file over (holding the mouse button down but not releasing it) the machine will hang a bit while it tries to resolve the destination for the shortcut. My point being that it takes a while to resolve the network path.

 

My guess is that Retrospect tries to resolve the network path as you are modifying the script. I also figure it is doing it more than once.

 

If this were a backup source we could try putting it into a folder in the volumes database. Since it is a dupe there isn't much we can do. For grins I would try the dupe to a windows volume to see if that makes a difference.

 

nate

[awnews]

My objection isn't to the dup (or backup) process itself being "slow"--that's a given when transferring data over a slow interface. My complaint is that RP is slow (*really* slow) when I'm just editing the script, and for a dup this is all being done locally (no remote .rbf file involved). I agree that RP must be repeatedly banging on the remote directory, but IMHO there's no reason it should be.

 

I do dup to other drives on this same PC and don't experience any slowness when editing those scripts. So whatever (unneccesary) thing RP is doing with the dup directory isn't noticed when the dup location is local and fast.

 

As a side note, I've noticed that RP does all sorts of weird under-the-hood/behind-the-scenes stuff. As another example, I have a system with multiple harddrives and I allow the drives to spin down when not in use (so the C: drive stays running and the backup L: drive spins down). When I start RP, even though I'm not doing anything (running backups, editing scripts, etc.) there's a long pause as my L: drive spins up. This doesn't happen when I launch my email program, MS Office, Paint Shop Pro, ...., just RP. So what (and why) is RP doing to bang on other drives in the system when its launched but not doing anything else.