BITS Priorities for User Initiated Deployments
Test in 1606: For User launched Application deployments (i.e Software Center) , the BITS job is created as FOREGROUND priority which can hog all of the available bandwidth on the machine.
Package/Programs downloads are launched with a BITS priority of LOW – please can we standardize on this for all user initiated content downloads.
Phil
shared this idea
6 comments
-
Anonymous
commented
The problem is not throttling at all, it's that two similar entries in the software center behave different:
A user initiated download of a *package/program* will be paused when the energy schema changes to "save battery" (since its bits priority is "low"), while a user initiated download of an *application* will resume in that case (since it's "foreground").
The user isn't aware of the difference between programs and applications... -
Joshua Binney
commented
You all must have awesome bandwidth to every site. Why do you throttle at all?
-
Anthony Greer
commented
2 votes from me! I agree with Jay's comment and would also add that this should be a hotfix, not even a full release feature! Please fix this one and dont make us wait for the next milestone for it!
-
JayM
commented
Yes SWerner, user initiated from the Software Center. I disagree though with that design. There are plenty of circumstances where I want to control the transfer rate of any active content transfer, optional, or required. We can only throttle BITS background transfers. So either we need the ability to throttle BITS foreground transfers, the SCCM transfer methods need to be Background/Low priority only, or we need some way to choose whether any given deployment is using one, or the other.
-
Anonymous
commented
Ricky Bobby does not approve of slowing down. I wanna go fast.
-
swerner
commented
Phil,
is it triggered by user interaction, but not by the deadline of a required deployment?
If so, I think it is good that the user gets the app he needs as fast as possible