Apologetically, we have discovered that in our alternate NT partition, we
did not nail down the port to full duplex, 100 Mb. We have a known problem
with some hubs in our network that do not support auto-negotiate, and the
resulting huge performance discrepancy was really do to this.
Thank you al
Sorry - I forgot to mention that our cache hit is 98.23 so that looks ok.
And, agreed, the command line is slightly faster but not dramatically
different. Where we see the big difference is when we boot the client from
an alternate partition, simulating the destruction of that client. Our
first
We are running on what we call a baby mainframe - Multiprise 3000 -
utilizing the internal adapter. Some basic ftp testing does show us that
this is not exactly stellar performance on throughput. But our basic issue
here is that we are getting some very different performance levels when
dealing
--Original Message-----
From: Ripley, Bev [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 03, 2001 1:38 PM
To: [EMAIL PROTECTED]
Subject: NT client restore C drive
On a bare bones restore of a Windows NT client's C drive, we are getting
very poor throughput times. For example, it is taking an
On a bare bones restore of a Windows NT client's C drive, we are getting
very poor throughput times. For example, it is taking an hour and a half to
restore 200 MB. Restoring the D drive is much better - 4 minutes for 50 MB.
We have release 4.1, a 10/100 Ethernet network, OS/390 TSM server, and
