File Copying

I have two servers that are running server 2003 SP1 connected via a gb
switch. I also have 1 windows XP Pro workstation that initiates a file copy
between the two servers. We had this workstation plugged into a gb switch as
well and a file copy usually takes 30 minutes. We moved this workstation on
to a 100 mb port and the same file copy took over 2 hours.

My question is why would a the connection speed of this 3rd workstation that
initiates file copies between these two servers affect the network
performance? I checked with concierge chat and they couldn't locate any MS
docs that indicated why this is the case. In the old days with Novell
Netware, I know the 3rd workstation would affect performance, but now with
Windows, I didn't think that the 3rd workstation in this scenario would
affect performance.

Thanks.


SteveW

"SteveW" <(E-Mail Removed)> wrote in message
news:4513D39F-180E-4D00-9EF8-(E-Mail Removed)...
>I have two servers that are running server 2003 SP1 connected via a gb
> switch. I also have 1 windows XP Pro workstation that initiates a file
> copy
> between the two servers. We had this workstation plugged into a gb switch
> as
> well and a file copy usually takes 30 minutes. We moved this workstation
> on
> to a 100 mb port and the same file copy took over 2 hours.

100mb is 10 times slower than 1GB. 30 minutes x 10 = 5 hours,...So I think
you are doing quite well at 2 hours.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Sure, I understand the difference between 1gb and 100 mb. If I moved one of
the servers to 100mb, I can understand the difference. But why would moving
the workstation that initiates the copy cause the file copy to slow down?
What data is being exchanged between this workstation and the servers doing
the copy? It shouldn't make this difference, but it appears it does.

Steve.

"Phillip Windell" wrote:

> "SteveW" <(E-Mail Removed)> wrote in message
> news:4513D39F-180E-4D00-9EF8-(E-Mail Removed)...
> >I have two servers that are running server 2003 SP1 connected via a gb
> > switch. I also have 1 windows XP Pro workstation that initiates a file
> > copy
> > between the two servers. We had this workstation plugged into a gb switch
> > as
> > well and a file copy usually takes 30 minutes. We moved this workstation
> > on
> > to a 100 mb port and the same file copy took over 2 hours.
>
> 100mb is 10 times slower than 1GB. 30 minutes x 10 = 5 hours,...So I think
> you are doing quite well at 2 hours.
>
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"SteveW" <(E-Mail Removed)> wrote in message
news:31738180-FF18-4691-8CD5-(E-Mail Removed)...
> Sure, I understand the difference between 1gb and 100 mb. If I moved one
> of
> the servers to 100mb, I can understand the difference. But why would
> moving
> the workstation that initiates the copy cause the file copy to slow down?
> What data is being exchanged between this workstation and the servers
> doing
> the copy? It shouldn't make this difference, but it appears it does.

It is because the Workstation copies the file into its own RAM and then
copies it from RAM to the target server because it is the Workstation's own
I/O system that is involved. It does not go directly between the two
servers. Thw workstation's perpspective of the copy is that it is copying
from one UNC Location to another UNC Location just like if it was from one
local drive to another local drive. So you effectively copy the file twice
(to the workstation,..from the workstation).

If you want it to go directly between the two servers either:

1. Go to the server itself and do it (doesn't matter which server, just pick
one)

OR

2. Use Remote Desktop from the workstation to connect to one of the servers
(either one) and do the copy from the remote session.

OR

3. Write a batch file that resides on one of the two servers that has the
command to do the copy. Have it execute using the Task Scheduler. (No you
can't execute the batch file from the workstation because it will run in the
workstation's RAM again).

There are probably a few other ways, but those are the three most obvious
ways that I can think of.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

OK, this would make a little more sense, but I don't understand why the
workstation would would copy the files to it's own RAM when the files should
be copied between the servers. This had been the case with Novell and ncopy
had to be used to do a file copy that bypassed the 3rd PC. Do you know if MS
has any documentation supporting your suggestion?

I am running this by using 3rd party automated software via command line.
So, I could try using psexec to run the batch on one of the servers, but
didn't think was required. Having the file copied to local RAM is so old
school!

Thanks Phillip.

"Phillip Windell" wrote:

> "SteveW" <(E-Mail Removed)> wrote in message
> news:31738180-FF18-4691-8CD5-(E-Mail Removed)...
> > Sure, I understand the difference between 1gb and 100 mb. If I moved one
> > of
> > the servers to 100mb, I can understand the difference. But why would
> > moving
> > the workstation that initiates the copy cause the file copy to slow down?
> > What data is being exchanged between this workstation and the servers
> > doing
> > the copy? It shouldn't make this difference, but it appears it does.
>
> It is because the Workstation copies the file into its own RAM and then
> copies it from RAM to the target server because it is the Workstation's own
> I/O system that is involved. It does not go directly between the two
> servers. Thw workstation's perpspective of the copy is that it is copying
> from one UNC Location to another UNC Location just like if it was from one
> local drive to another local drive. So you effectively copy the file twice
> (to the workstation,..from the workstation).
>
> If you want it to go directly between the two servers either:
>
> 1. Go to the server itself and do it (doesn't matter which server, just pick
> one)
>
> OR
>
> 2. Use Remote Desktop from the workstation to connect to one of the servers
> (either one) and do the copy from the remote session.
>
> OR
>
> 3. Write a batch file that resides on one of the two servers that has the
> command to do the copy. Have it execute using the Task Scheduler. (No you
> can't execute the batch file from the workstation because it will run in the
> workstation's RAM again).
>
> There are probably a few other ways, but those are the three most obvious
> ways that I can think of.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
>
> Microsoft ISA Server Partners: Partner Hardware Solutions
> http://www.microsoft.com/forefront/e...epartners.mspx
> -----------------------------------------------------
>
>
>

SteveW wrote:
> OK, this would make a little more sense, but I don't understand why the
> workstation would would copy the files to it's own RAM when the files should
> be copied between the servers. This had been the case with Novell and ncopy
> had to be used to do a file copy that bypassed the 3rd PC. Do you know if MS
> has any documentation supporting your suggestion?
>
> I am running this by using 3rd party automated software via command line.
> So, I could try using psexec to run the batch on one of the servers, but
> didn't think was required. Having the file copied to local RAM is so old
> school!
>
> Thanks Phillip.
>
> "Phillip Windell" wrote:
>
>> "SteveW" <(E-Mail Removed)> wrote in message
>> news:31738180-FF18-4691-8CD5-(E-Mail Removed)...
>>> Sure, I understand the difference between 1gb and 100 mb. If I moved one
>>> of
>>> the servers to 100mb, I can understand the difference. But why would
>>> moving
>>> the workstation that initiates the copy cause the file copy to slow down?
>>> What data is being exchanged between this workstation and the servers
>>> doing
>>> the copy? It shouldn't make this difference, but it appears it does.
>> It is because the Workstation copies the file into its own RAM and then
>> copies it from RAM to the target server because it is the Workstation's own
>> I/O system that is involved. It does not go directly between the two
>> servers. Thw workstation's perpspective of the copy is that it is copying
>> from one UNC Location to another UNC Location just like if it was from one
>> local drive to another local drive. So you effectively copy the file twice
>> (to the workstation,..from the workstation).
>>
>> If you want it to go directly between the two servers either:
>>
>> 1. Go to the server itself and do it (doesn't matter which server, just pick
>> one)
>>
>> OR
>>
>> 2. Use Remote Desktop from the workstation to connect to one of the servers
>> (either one) and do the copy from the remote session.
>>
>> OR
>>
>> 3. Write a batch file that resides on one of the two servers that has the
>> command to do the copy. Have it execute using the Task Scheduler. (No you
>> can't execute the batch file from the workstation because it will run in the
>> workstation's RAM again).
>>
>> There are probably a few other ways, but those are the three most obvious
>> ways that I can think of.
>>
>> --
>> Phillip Windell
>> www.wandtv.com
>>

Much as I prefer top-posting (don't start!) it's definitely best to
stick to one or the other!

I agree with PW: any copy operation consists of a read operation from
disk via a buffer into local RAM and from there, via a buffer (and
possibly a network) onto another disk. If you run the copy on a
"third-party", then all the data has to pass through it. Your
suggestion of using psexec (and Phil W's suggestion of Remote Desktop or
something similar) is a good one. By the way, if there's a lot of data,
and reliability is an issue, it's worth getting to grips with Robocopy,
which has more ingenious options than you can shake a stick at. Part of
the free "Windows Server 2003 Resource Kit Tools" download.

Phil H, London

I am familiar with Robocopy, so will maybe use that in conjunction with
psexec. I just thought that Windows would be smarter than this when
initiating a copy from a 3rd PC. Do you know if this is documented anywhere
in a KB or technet?

Thanks.

"Philip Herlihy" wrote:

> SteveW wrote:
> > OK, this would make a little more sense, but I don't understand why the
> > workstation would would copy the files to it's own RAM when the files should
> > be copied between the servers. This had been the case with Novell and ncopy
> > had to be used to do a file copy that bypassed the 3rd PC. Do you know if MS
> > has any documentation supporting your suggestion?
> >
> > I am running this by using 3rd party automated software via command line.
> > So, I could try using psexec to run the batch on one of the servers, but
> > didn't think was required. Having the file copied to local RAM is so old
> > school!
> >
> > Thanks Phillip.
> >
> > "Phillip Windell" wrote:
> >
> >> "SteveW" <(E-Mail Removed)> wrote in message
> >> news:31738180-FF18-4691-8CD5-(E-Mail Removed)...
> >>> Sure, I understand the difference between 1gb and 100 mb. If I moved one
> >>> of
> >>> the servers to 100mb, I can understand the difference. But why would
> >>> moving
> >>> the workstation that initiates the copy cause the file copy to slow down?
> >>> What data is being exchanged between this workstation and the servers
> >>> doing
> >>> the copy? It shouldn't make this difference, but it appears it does.
> >> It is because the Workstation copies the file into its own RAM and then
> >> copies it from RAM to the target server because it is the Workstation's own
> >> I/O system that is involved. It does not go directly between the two
> >> servers. Thw workstation's perpspective of the copy is that it is copying
> >> from one UNC Location to another UNC Location just like if it was from one
> >> local drive to another local drive. So you effectively copy the file twice
> >> (to the workstation,..from the workstation).
> >>
> >> If you want it to go directly between the two servers either:
> >>
> >> 1. Go to the server itself and do it (doesn't matter which server, just pick
> >> one)
> >>
> >> OR
> >>
> >> 2. Use Remote Desktop from the workstation to connect to one of the servers
> >> (either one) and do the copy from the remote session.
> >>
> >> OR
> >>
> >> 3. Write a batch file that resides on one of the two servers that has the
> >> command to do the copy. Have it execute using the Task Scheduler. (No you
> >> can't execute the batch file from the workstation because it will run in the
> >> workstation's RAM again).
> >>
> >> There are probably a few other ways, but those are the three most obvious
> >> ways that I can think of.
> >>
> >> --
> >> Phillip Windell
> >> www.wandtv.com
> >>
>
> Much as I prefer top-posting (don't start!) it's definitely best to
> stick to one or the other!
>
> I agree with PW: any copy operation consists of a read operation from
> disk via a buffer into local RAM and from there, via a buffer (and
> possibly a network) onto another disk. If you run the copy on a
> "third-party", then all the data has to pass through it. Your
> suggestion of using psexec (and Phil W's suggestion of Remote Desktop or
> something similar) is a good one. By the way, if there's a lot of data,
> and reliability is an issue, it's worth getting to grips with Robocopy,
> which has more ingenious options than you can shake a stick at. Part of
> the free "Windows Server 2003 Resource Kit Tools" download.
>
> Phil H, London
>

> "Philip Herlihy" wrote:
>
>> SteveW wrote:
>>> OK, this would make a little more sense, but I don't understand why the
>>> workstation would would copy the files to it's own RAM when the files should
>>> be copied between the servers. This had been the case with Novell and ncopy
>>> had to be used to do a file copy that bypassed the 3rd PC. Do you know if MS
>>> has any documentation supporting your suggestion?
>>>
>>> I am running this by using 3rd party automated software via command line.
>>> So, I could try using psexec to run the batch on one of the servers, but
>>> didn't think was required. Having the file copied to local RAM is so old
>>> school!
>>>
>>> Thanks Phillip.
>>>
>>> "Phillip Windell" wrote:
>>>
>>>> "SteveW" <(E-Mail Removed)> wrote in message
>>>> news:31738180-FF18-4691-8CD5-(E-Mail Removed)...
>>>>> Sure, I understand the difference between 1gb and 100 mb. If I moved one
>>>>> of
>>>>> the servers to 100mb, I can understand the difference. But why would
>>>>> moving
>>>>> the workstation that initiates the copy cause the file copy to slow down?
>>>>> What data is being exchanged between this workstation and the servers
>>>>> doing
>>>>> the copy? It shouldn't make this difference, but it appears it does.
>>>> It is because the Workstation copies the file into its own RAM and then
>>>> copies it from RAM to the target server because it is the Workstation's own
>>>> I/O system that is involved. It does not go directly between the two
>>>> servers. Thw workstation's perpspective of the copy is that it is copying
>>>> from one UNC Location to another UNC Location just like if it was from one
>>>> local drive to another local drive. So you effectively copy the file twice
>>>> (to the workstation,..from the workstation).
>>>>
>>>> If you want it to go directly between the two servers either:
>>>>
>>>> 1. Go to the server itself and do it (doesn't matter which server, just pick
>>>> one)
>>>>
>>>> OR
>>>>
>>>> 2. Use Remote Desktop from the workstation to connect to one of the servers
>>>> (either one) and do the copy from the remote session.
>>>>
>>>> OR
>>>>
>>>> 3. Write a batch file that resides on one of the two servers that has the
>>>> command to do the copy. Have it execute using the Task Scheduler. (No you
>>>> can't execute the batch file from the workstation because it will run in the
>>>> workstation's RAM again).
>>>>
>>>> There are probably a few other ways, but those are the three most obvious
>>>> ways that I can think of.
>>>>
>>>> --
>>>> Phillip Windell
>>>> www.wandtv.com
>>>>
>> Much as I prefer top-posting (don't start!) it's definitely best to
>> stick to one or the other!
>>
>> I agree with PW: any copy operation consists of a read operation from
>> disk via a buffer into local RAM and from there, via a buffer (and
>> possibly a network) onto another disk. If you run the copy on a
>> "third-party", then all the data has to pass through it. Your
>> suggestion of using psexec (and Phil W's suggestion of Remote Desktop or
>> something similar) is a good one. By the way, if there's a lot of data,
>> and reliability is an issue, it's worth getting to grips with Robocopy,
>> which has more ingenious options than you can shake a stick at. Part of
>> the free "Windows Server 2003 Resource Kit Tools" download.
>>
>> Phil H, London
>>

SteveW wrote: (and Phil H moved):
> I am familiar with Robocopy, so will maybe use that in conjunction with
> psexec. I just thought that Windows would be smarter than this when
> initiating a copy from a 3rd PC. Do you know if this is documented
anywhere
> in a KB or technet?
>
> Thanks.
>

If you mean is it documented that a copy process running on a 3rd PC
will "handle" all the data involved, I'd be very surprised if it was,
because that's just how it works. I think your expectation is a little
eccentric, although I'm not suggesting you are - we all get the wrong
end of the stick sometimes. I certainly had to pinch myself to see if I
was missing something (but I don't think so). If the copy process runs
on the 3rd PC, it's handling all the data.

It's true that Windows can figure out when a computer is making a
network connection to itself; it loops back, so the activity never makes
it out to the network card.

I worked on an obsure Xerox box (1181 was it?) running Lisp, which had a
feature called "DWIM" (i.e. Do What I Mean). It was awful - every
mistake you made when learning had it run off and do something
catastrophic...

Phil

"SteveW" <(E-Mail Removed)> wrote in message
news:8A8D2233-9F5A-44A8-B900-(E-Mail Removed)...
>I am familiar with Robocopy, so will maybe use that in conjunction with
> psexec. I just thought that Windows would be smarter than this when
> initiating a copy from a 3rd PC. Do you know if this is documented
> anywhere
> in a KB or technet?

It is not a matter of Windows being "smarter" or not. It would do exactly
the same thing with Linux.
It is simple "mechanics". It is not the OS of either server making the copy
"happen" and it is not the processor of either server executing the
command,...it is the OS and the processor of the workstation that is 100%
responsible for it,...therefor the data passes through the workstation as it
goes between the server. The OS and the processors of the servers are
responding to the workstation,...not each other.

I don't think you will easily find articles about this, although there might
be some. It is just common knowledge of the way things have been for about
27 years or longer. If you want the data to pass directly between the
servers then one of the servers has to be the one that initiated the
process.

I'm not personally familiar with psexec or robocopy, so I can't say anything
about those.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------