Paul, I know it's been a while since you posted this but I wanted to share my insights. We've received the same complaints.
The problem is not TSM per se, but the fact that I/O is interrupt-based and the interrupt service routines run at high-priority. This also affects any scan process, including anti-virus. For years, the AV writers set their software to scan at the lowest possible priority, only to have it create a huge impact on the machine anyway. No matter how low a priority the process runs, once it tells the storage system to read a file, that file read will run at high priority until it completes the transaction. On the network, there is another factor to consider, that was discussed recently by Intel engineers in one of the IEEE computer magazines. Incoming network data ends up being placed in memory by the NIC driver without being cached by the CPU. When the NIC generates the interrupt telling the CPU to process the received data, its absence in every level of CPU cache causes a cache miss and at today's clock cycles, a stall of several hundred cycles while the addresses and data make their way into the cache hierarchy. Since at the start of every standard TSM backup, the client receives over the network the list of files already known to TSM, that qualifies as "incoming data". Outgoing data is less of a factor since the processor is setting up the data in the various buffers. Therefore, what we've chosen to do is this: * provide a set of hourly schedules spread between 8 pm and 5 am; a PC - CAD workstation in our case - can be set to "backup no earlier than xxx". If I have an engineer who frequently works till 8 pm, I can schedule his PC to backup at 11 pm, for example. We also have a special "noon" backup schedule for docked laptops. * tune TCP window size to reduce the number of acknowledgements; * tune the client aggregation settings to minimize the number of data bursts; we have our system set to create 48 MB aggregates by default. The larger the aggregate, the fewer number of transfers will be made, but the more memory will be needed to buffer the aggregate under construction. * turn off anti-virus scanning on files "when opened for backup"; all PCs have real-time scan enabled so it isn't necessary to re-scan when backing up. Hope this helps. Tab Trepagnier TSM Administrator Laitram LLC "ADSM: Dist Stor Manager" <[email protected]> wrote on 04/25/2006 01:13:58 PM: > We have a small number of users here who are complaining that when a > TSM backup runs on their client system, it monopolizes use of their > network card. They are looking for a way to throttle back TSM's use > of the network. Has anyone else run into this? Any ideas? The only > thing I've come up with is to configure a secondary NIC at 10MB/s and > point these users at that card. This seems crude to me, so other > ideas would be welcome. > > ..Paul > > > -- > Paul Zarnowski Ph: 607-255-4757 > Manager, Storage Systems Fx: 607-255-8521 > 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]
