Alex - Thanks for that isolated example...good to see that kind of thing.
I would caution against attributing the speed variation to the server or tape drive until you have a bunch more information. I'm no Windows expert, but this kind of "pulsing" behavior might be an OS issue where TCP buffers are quickly filled, then relatively slowly drain, then quickly fill again... I perceive that your client is somewhere on the network, separated from the TSM server. Depending upon your networking, another possibility is bandwidth limiting, where some sites may limit per-unit-time traffic; but that would be unusual. Whereas your server and client are both Windows, you might perform the experiment of performing a test restoral of the 32 GB data file locally on the server, to eliminate networking as a variable and see how that performs. You could eliminate the tape drive variable by performing a test backup to a DISK or FILE type stgpool, and restore from that. Problem isolation in such cases can be tedious, but usually determinable. Whereas your server is a Windows 2000 OS, I'd be conservative in expectations from that aged operating system, with its known foibles. Richard Sims On Dec 22, 2005, at 8:09 AM, Alexander Lazarevich wrote:
Thanks for the responses all, but it's not a tape mounting issue. I wasn't clear enough in my original post, but I am watching the actlog while the restore is taking place, and I'm sitting next to the library, so I can tell when it's doing anything: remounting, rewinding, etc. What I'm saying is this: The server is restoring a single 32GB file, and starts doing so at 30+MB/sec. At some point, DURING the restore of that SAME 32GB file, the server suddenly slows down the restore, to 200-300K/sec. The server has NOT switched tapes, and is NOT rewinding even the SAME tape. It is still restoring that same 32GB file, but suddenly does so at a slower speed. I know the drives have some kind of burst speed and normal speed. Maybe something is wacked out with that function? Any other ideas?