Hmm, I suspect the "proper" mechanism for this would be some sort of
traffic shaping or bandwidth allocation. Guearantee the download app no
more than say 5% of the link bandwidth, and guarantee everything else
95%. Then, whenever everything else needs network resource, it can get
it, and the download is not _comletely_ starved.
That requires stuff in the "kernel."
If you wanted to go outside the kernel, my first guess is to assume the
existence of three "processes." One is your download app. One is a
monitoring app, and the "third" is everything else.
Assuming it was available on your platform, and CPU util is no issue
your monitoring program sniffs the interface connected to the internet
(this may not need to be promiscuous mode depending on the platform).
Each time interval, it counts how many bytes your download took, and how
many bytes everything else took. Your download app has to cooperate when
told by the monitor to slow down.
Start the download at say 90% bandwidth, then as your monitor sees
"other" taking a percent of bandwidth, you take that away from the
download. If the monitor sees other take less, it then gives it to
download. You would want some sort of damping on that behaviour. Always
leave a cushion so there is room for other to try and get bandwidth in
the first place.
If you cannot sniff the interface, your monitor instead makes SNMP
queries of its MIB for the byte counts. Start with the download at 90%
or something. If the bandwidth util shows 91%, tell the download to take
89. Next time it goes to 91, take another percent from download. If the
byte count goes to your download apps allocation, that implies "other"
is quiet and you can tell download to take more bandwidth.
> b) is more in the area of this mailing list, i.e. stack performance, but I
> hoped that somebody would have done this type of thing before and could give
> me some pointers.
Are you asking how to measure stack performance, or are you looking for
figures on stack performance?
rick jones
-- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain...