Mediawait, commwait, idlewait

[adsmsuser]

Hi!

can anyone help me understand COMMWAIT?

Here are some Restores we made via Storage Agent.
2 Channels, each restoring about 900GB


DURATION IDLE/h MEDIA/h COMM/h
2:41 1,37 0,01 2,69
2:41 1,36 0,01 2,69

1:56 0,01 0,01 2,51
1:59 0,01 0,01 2,61

6:58 0,00 0,01 2,96 <- was lanfree - STA failed
6:58 0,00 0,01 2,95 <- was lanfree - STA failed

2:41 1,43 0,01 2,69
2:41 1,38 0,01 2,69

1:33 0,00 0,01 1,04
1:33 0,00 0,01 1,05

i just dont understand the entry for *WAIT.
I thougt i would be seconds. but .. cant be
regarding the two lines in bold that would mean: commwait was longer than restore time? is it in milli seconds????

Is there a paper from ibm showing how these values are counted?
i found NOTHING, neither in the redbook, nor in performance guides ...

do you care about them?
do you have such high values?

Please help

 

[DanGiles]

IDLE wait is basically the time between one set of commands/responses and the next.
COMM wait is the time time the TSM server is expecting a reply or response from the client and isn't getting it.

Even with LAN-free, all of the meta data and commands are passed through the LAN, so if it's ultra congested, that will be a problem. It could also be at the client or server: you basically have to run a client side trace to get a better handle.

COMM wait would include the time between the server saying "send me the data" and the client say "here it is", and then the client sending the actual data. It could be possible that the server (as far as these stats are concerned) isn't picking up the fact that the data is actually being sent through the SAN, and hence you'd get rediculous COMM WAIT times.

You find this information in the performance and trouble shooting guides.