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 testing had this alternate partition with a different node name than the original which caused us to have to specify the path to restore a disk, directory, or file. We got very slow performance with this. Next we changed this alternate partition to have the same node name as the original client so we could then do a restore without being forced to specify the path. Unfortunately, this had the same result. So at this point we have to believe the problem is something to do with running the client from an alternate partition (and, therefore, not running from the C drive). I have seen statements that the client should be running from the C drive, but if you lose the client entirely, how do you restore enough of the client to get back to the C drive to then complete the rest of the restores? No changes are being made to the file system types, either. At this time we are dealing with a test NT box, deleting the data or formatting disks and trying to recover it to exactly the same hardware and software. Examples: restoring a directory of 178 MB of data, 2925 objects took 2:35 minutes when restored from the original client, while it took 1 hour and 10 minutes when the restore was initiated from the alternate partition. Restoring the D drive, 195 MB, 4955 objects took 4:25 minutes from the original client, while it took 1 hour and 41 minutes when initiated from the alternate partition.
-----Original Message----- From: Christo Heu�r [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 8:49 AM To: [EMAIL PROTECTED] Subject: Re: Re: NT client restore C drive That does sound a bit funny. >From the difference in performance between the GUI and the cmd line - the cmd line is faster. As far as I've seen the restore command does not behave differently when specifying a path other than the original. Have you looked at the cache hit percentage. When you are restoring a lot of files this makes quite a difference in the overall picture. As a matter of interest - why are you restoring to a different path than the original path the data was backed up on? Something you could look at is the type of file system your new NT system has - was it using NTFS and now fat or the other way around? Let me know as you progress. Regards Christo Heuer 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 with restore commands. Perhaps a further clarification from our ongoing testing would be to say that we are seeing very dramatically different restore results from entering restore commands either through the gui or command line when we have booted from an alternate partition on the NT client. It is dramatically worse performance from the alternate partition. But this is what we would anticipate having to do if we lost the client machine entirely. And so far, this is really unacceptable results. There must be something very different in the processing of the restore when a path is specified for the restore as opposed to choosing the "put it back where it came from" option. Any suggestions for us? Thanks for any help you can offer. -----Original Message----- From: Christo Heu�r [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 7:26 AM To: [EMAIL PROTECTED] Subject: Re: Re: NT client restore C drive Hi Bev, You said you are running 10/100 Ethernet network - I presume this is on the NT machine. What is the interface into the TSM server like (What networking hardware are you using attaching your OS/390 system to the rest of the IP network?) As a start - do a ftp from your client on NT to the OS/390 box. This will eliminate any TSM related tuning that you can do. Even on a default config running via a 3172 controller(16M T/Ring), we get better performance than you are getting. (About four times better than what you are seeing on your D drive restore....) The FTP will indicate if the network can pump the data fast enough. The second thing is look at your cache hit statistics on the server via the q db f=d command - your cache hit must be above 98% - if not you are experiencing memory problems on the TSM server side of things - this will definately affect the speed at which you are restoring files - especially if you move a lot of small files. Let me know how it goes. Regards Christo Heuer ABSA Bank Johannesburg SOUTH AFRICA > Thanks for the suggestion but there are no tapes involved. This is a test > environment still and we are only going to dasd on the mainframe server. > > 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 we > are booting off an alternate partition on the NT client to restore the C > drive. > Why would we have such a discrepancy in restore times between the 2 drives? > And is this average performance? We have much larger servers coming up in > our plans and this is not an acceptable timeframe for restores. > TIA > > ---------------------------------------------------------------------------- > --
