This could be a catch-22 first realize what idle wait time is...
Idle wait time works out to be time that the server is waiting on the
client to initiate the next transaction (for lack of a better term)
So if the client is sending a 2GB file, the time between packets
received by the server (that make up the 2GB file) is RECEIVE-WAIT,
the time the server is processing a received packet is
COMMUNICATION-WAIT (or time spent managing packet collision) but if
the client is sending (or getting ready to) 100 - half KB files the
time that the client is reading those little files and getting them
ready to send is IDLE-WAIT... the time the client is calculating "what
to send" is IDLE-WAIT... the time a client is compressing and creating
a bundle of files to send is IDLE-WAIT
(OK and I might be a little off on my definitions above but it is
02:00 am !) What I'm trying to stress is idle-wait isn't necessarily
a bad thing!
example:
Task Sessions CommKB Cumulative Sec Idle sec Comm sec
41 Totals 150 11,434,029 73,791 671 73,075
53 Totals 150 11,440,573 71,842 642 71,159
68 Totals 150 67,868,395 75,709 310 75,200
79 Totals 150 67,868,395 122,437 195 122,030
85 Totals 150 67,868,423 101,171 178 99,665
89 Totals 150 67,868,418 99,117 184 97,533
Basically the above tasks were all archiving the exact same data base (minor
activity between tasks which account for the slight variation in CommKB) if
you notice the two with the GREATEST "Idle Sec" moved the least data in the
shortest times (cumulative session seconds), these two tasks were with client
compression! The other activities were with variations in # of concurrent
archive tasks, a single or multiple fddi interfaces, etc...
So... like I said "Idle wait ain't necessarily bad"
ALSO don't fall into the KB/sec trap... the worst KB/sec (when calculated) were
the ones running compression BUT END USER FILE SPACE WAS THE SAME IN ALL TASKS
SO the *BEST* KB/sec (end user file space) looks like the worst runs in the
above listing. (GOD it took me forever to drive that home with folks!)
anyway, best of luck to you
later,
Dwight
______________________________ Reply Separator _________________________________
Subject: idlew
Author: SGogineni at unix,mime/DD.RFC-822=SGogineni AT caiso DOT com
Date: 11/9/98 9:04 PM
Hi all,
I am interested in reducing specifically the idlew time in the
backup session of a client. Is there any way to decrease this apart from
adding more cpu power to the client.
unfortunately multi streaming does not allow me to split the tasks. because
all the data is residing on a single disk.
other parameter changes seem to have little or no effect for this idlew
time, although I 'm able to improve marginally my backup performance. I can
clearly see that the client is idling (processing files probably about a
million)
Sincere thanks
sri
|
