From: Rick Jones on
Barry Margolin <barmar(a)alum.mit.edu> wrote:
> In article <hr5a3r$lii$1(a)usenet01.boi.hp.com>,
> Rick Jones <rick.jones2(a)hp.com> wrote:

> > Plan C - It would be a very blunt instrument, but if the download
> > is managed by a distinct process, you could, presumably send a
> > series of SIGSTOP/SIGCONT pairs to the process, where SIGSTOP
> > would stop it from running until SIGCONT was sent. You don't want
> > to leave it SIGSTOPped for very long or you will start to induce
> > some undesirable behaviours in TCP - I'd shoot for having it
> > stopped for no more than a tenth or a quarter of a second at a
> > time. When the application stops, it stops draining the socket
> > buffer. When the socket buffer is not drained, the socket buffer
> > fills. When the socket buffer fills the receiving TCP advertises
> > a zero window. When the sender sees the zero window it will
> > probe, but may not be willing to probe for very long.

> Do you think nice'ing the SU process to the lowest priority could
> accomplish this? If the scheduler doesn't run the process as often,
> it might not be able to drain the queue as fast as the SU server
> sends, so the window will shrink.

Niceness is a noop if something else doesn't want to consume the CPU
cycles. Chances are there isn't much CPU being consumed by the
updater during the download - the "system performance" bottleneck here
is the internet link.

I think the "fair share scheduler" of Unix lore might have a way to
preclude a process from getting more than some fraction of the
available CPU, regardless of how much is free. Whether it could limit
it to a small enough fraction to affect the bandwidth consumed is a
good question. Even beyond whether or not the FSS is available under
OSX :)

Another possibility that sprang to mind later:

Plan D - dummynet or some other variation on the theme of a bandwidth
shaper (eg linux netem) - getting it setup on the specific flow used
by the updater might be difficult though.

rick jones
sorry to be late with the reply - don't always get into the newsgroup
reliably...

--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...