[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  4400
Date     :  2003-04-21
Author   :  profasaurus
Subject  :  Re: Slow transfer speeds of large files over network?
Size(KB) :  3


I am already using the latest version of xxcopy, so the /ni switch 
was not a factor. I've tried using the UNC path instead of a drive 
letter, but the issue remains the same. Any other ideas? 

Again, I'm using a network speed utility to monitor the transfer 
rates in realtime. When using 'copy' from the command line, 
transfer rates are normal. When using 'xxcopy' from the command 
line, transfer rates are very slow for the same exact file (large 
files only exhibit this problem). This occurs whether I'm using UNC 
or network Drive letters...with or without any additional xxcopy 
switches. We are transferring from a Windows 2000 NTFS to a Quantum 
Snap server. 

Thanks,
Chris

--- In xxcopy@yahoogroups.com, Kan Yabumoto  wrote:
> 
> Other than the /NI switch, XXCOPY tries to run at full speed.
> 
> If you experience a performance degradation with a relatively
> large number of small files, you may look at the /NX operation
> (SFN preservation feature) that may be slowing down --- the
> adverse effect most pronounced with the NT/2K/XP family
> of OS ---- this problem was corrected in the latest release).
> 
> To test this quickly, you may just add /NI0 /NX0 at
> the end of your command line and see if this makes any
> difference. (I'm not sure if this makes much difference.
> If it does not improve anything, I don't know where to
> look for the problem at this moment). It could be a more
> generic problem such as just a lack of sufficient free
> space in the virtual memory. Make sure you have plenty
> of virtual memory allocated.
> 
> Lastly I'm not sure of the difference between accessing
> a remote computer using a mapped drive letter or a more
> direct UNC pathname ---- I always suggest the use of
> the UNC convention rather than assigning to a drive letter
> (which should be thought of a kludge which is supposedly
> help legacy programs which are not network-ready).
> That is, if a remote machine's name is SERVER_XYZ
> and the resource name for remote access is under C
> (the most common name fro drive C:), then,
> 
> E.g.,
> 
> xxcopy \\SERVER_XYZ\C\windows\ c:\dir1\server_xyz\ /backup
> 
> or, after mapping the volume as H:,
> 
> xxcopy h:\windows\ c:\dir1\server_xyz\ /backup
> 
> I advocate the use of the first example here rather than
> assigning the remove volume as H: (emulating a local
> drive by the driveletter-mapping).
> 
> I'm not sure whether any other factor is creating the
> bottleneck, though.
> 
> Let me add just one possible scenario which explains your
> observation of "large file only": the degradation
> of the file transfer rate may be affecting smaller
> files also, but small files are still transferred
> within a reasonable amount of time that you notice
> only the large file's poor performance.
> 
> Kan Yabumoto
> ===========================================================
> 
> 
> At 2003-04-17 14:10, you wrote:
> >Hello,
> >
> >We are experiencing a strange problem with slow network transfer
> >speeds only when copying very large files (4 GB +). When 
xxcopying
> >other size files (~160 MB), transfer speeds are 1.5 MB/sec. When
> >xxcopying the very large files to the same network drive map, the
> >transfer speeds are only 150 KB/sec. However, when using windows
> >explorer to copy and paste the same large files, the transfer 
speeds
> >are 1.5 MB/sec, so the issue seems to be linked to xxcopy. Any 
ideas?
> >
> >Thanks,
> >Chris



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.