(In reply to "Saptarshi Guha[:joy]" from comment #10) > So if i understand correctly, these are time durations(intervals)? Correct and they are in seconds. > If a profile successfully updates, then time between Update Check and Update Applied is the time taken to successfuly update. Correct > If "Updated Applied" never happened, one would have to backtrack to the last successful stage to see time taken to last successful stage. What would be the values of missing stages? i guess their entries would be missing? That is what I am leaning towards. It is also possible to check for a success code in existing telemetry if we want to measure the time it took to fail. > Looking at Romain's comment, i had some thoughts > > - BITS might not lead to faster downloads because IIRC BITS can throttle the downloads, right? That is one reason. If BITS fails for whatever reason then we'll fallback to using Firefox to download the update which will also take longer due to the time it takes to fail and start the download in Firefox. There are probably other reasons as well. > - but the promise of BITS is that downloads will continue even if Firefox is closed and hence the following hypotheses > - (a)we have more profiles with completed downloads (of MAR files) > - (b) we have more profiles that successfully update to newer version of Firefox More installations (profiles if you prefer since that more closely matches telemetry) that would download the MAR file sooner and hence update sooner. We don't think it should have a significant affect on success of downloading or updating. The main reason for older Firefox versions taking a very long time to update was identified using telemetry and fixed in Firefox 49 and further improvements were made in Firefox 52. This can be seen with the "Update Watersheds" by comparing Firefox 43.0.1 and 47.0.2 with Firefox 56.0 in the "Out of date, of concern client distribution across Firefox versions" section of the "Firefox Application Update Out Of Date Dashboard". https://telemetry.mozilla.org/update-orphaning/#version-dist-chart The main reason I recommended using BITS to download while Firefox isn't running is to update the clients that seldom run Firefox or when they do run Firefox they only have it open for a very short period of time. This can be seen in the "Out of date, potentially of concern reason distribution" section of the "Firefox Application Update Out Of Date Dashboard". Specifically, the clients that "Ran for less than 2 hours" during the previous 12 weeks (84 days) and have "Less than 4 update pings" during the previous 12 weeks (84 days). https://telemetry.mozilla.org/update-orphaning/#not-min-reqs-chart > Thus while Romain did ask for baseline of download rates, ultimately i think were interested hypotheses (a) and (b), correct? For this phase of the project I am interested in getting Windows clients that seldom run Firefox or only run Firefox for a short period of time updated faster without adversely affecting the clients that are already considered to be updating at a reasonable pace. If all Windows clients update faster with the BITS download implementation then that is all the better. For the full implementation I am interested in all Windows clients updating faster, have less interaction with updating, and possibly some other improvements we've been considering. > Hence once this lands we hope to see > > 1. for seldom/less users of Firefox, higher successful MAR download (do we measure currently if success of MARS download?) aftre they get this feature. Faster successful download rate for these users. We don't expect there to be a change in success vs. failure of downloads. We already measure download success and failure (including error code). Also, a value for the interval between "Update Download" and "Update Download Ready" represents a successful download. > 2. for same set of users, higher update rate (do we also measure if the MAR file successfully applied?) Faster successful update rate for these users. We don't expect there to be a change in success vs. failure of applying updates. We already measure applied success and failure (including error code). Also, a value for the interval between "Update Pending" to "Update Applied" represents an update that was successfully applied. > Lastly, why do you say "*The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients.*" This is just the BITS download portion of the Update Agent. The full project would also perform the update check, the download, and apply the update all without Firefox running.
Bug 1528278 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to "Saptarshi Guha[:joy]" from comment #10) > So if i understand correctly, these are time durations(intervals)? Correct and they are in seconds. > If a profile successfully updates, then time between Update Check and Update Applied is the time taken to successfuly update. Correct > If "Updated Applied" never happened, one would have to backtrack to the last successful stage to see time taken to last successful stage. What would be the values of missing stages? i guess their entries would be missing? That is what I am leaning towards. It is also possible to check for a success code in existing telemetry if we want to measure the time it took to fail. > Looking at Romain's comment, i had some thoughts > > - BITS might not lead to faster downloads because IIRC BITS can throttle the downloads, right? That is one reason. If BITS fails for whatever reason then we'll fallback to using Firefox to download the update which will also take longer due to the time it takes to fail and start the download in Firefox. There are probably other reasons as well. > - but the promise of BITS is that downloads will continue even if Firefox is closed and hence the following hypotheses > - (a)we have more profiles with completed downloads (of MAR files) > - (b) we have more profiles that successfully update to newer version of Firefox More installations (profiles if you prefer since that more closely matches telemetry) that would download the MAR file sooner and hence update sooner. We don't think it should have a significant affect on success of downloading or updating. The main reason for older Firefox versions taking a very long time to update was identified using telemetry and fixed in Firefox 49 and further improvements were made in Firefox 52. This can be seen with the "Update Watersheds" by comparing Firefox 43.0.1 and 47.0.2 with Firefox 56.0 in the "Out of date, of concern client distribution across Firefox versions" section of the "Firefox Application Update Out Of Date Dashboard". https://telemetry.mozilla.org/update-orphaning/#version-dist-chart The main reason I recommended using BITS to download while Firefox isn't running is to update the clients that seldom run Firefox or when they do run Firefox they only have it open for a very short period of time. This can be seen in the "Out of date, potentially of concern reason distribution" section of the "Firefox Application Update Out Of Date Dashboard". Specifically, the clients that "Ran for less than 2 hours" during the previous 12 weeks (84 days) and have "Less than 4 update pings" during the previous 12 weeks (84 days). https://telemetry.mozilla.org/update-orphaning/#not-min-reqs-chart > Thus while Romain did ask for baseline of download rates, ultimately i think were interested hypotheses (a) and (b), correct? For this phase of the project I am interested in getting Windows clients that seldom run Firefox or only run Firefox for a short period of time updated faster without adversely affecting the clients that are already considered to be updating at a reasonable pace. If all Windows clients update faster with the BITS download implementation then that is all the better. For the full implementation I am interested in all Windows clients updating faster, have less interaction with updating, and possibly some other improvements we've been considering. > Hence once this lands we hope to see > > 1. for seldom/less users of Firefox, higher successful MAR download (do we measure currently if success of MARS download?) aftre they get this feature. Faster successful download rate for these users. We don't expect there to be a change in success vs. failure of downloads. We already measure download success and failure (including error code). Also, a value for the interval between "Update Download" and "Update Download Ready" represents a successful download will be the likely path we take. > 2. for same set of users, higher update rate (do we also measure if the MAR file successfully applied?) Faster successful update rate for these users. We don't expect there to be a change in success vs. failure of applying updates. We already measure applied success and failure (including error code). Also, a value for the interval between "Update Pending" to "Update Applied" represents an update that was successfully applied will be the likely path we take. > Lastly, why do you say "*The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients.*" This is just the BITS download portion of the Update Agent. The full project would also perform the update check, the download, and apply the update all without Firefox running.
(In reply to "Saptarshi Guha[:joy]" from comment #10) > So if i understand correctly, these are time durations(intervals)? Correct and they are in seconds. > If a profile successfully updates, then time between Update Check and Update Applied is the time taken to successfuly update. Correct > If "Updated Applied" never happened, one would have to backtrack to the last successful stage to see time taken to last successful stage. What would be the values of missing stages? i guess their entries would be missing? That is what I am leaning towards. It is also possible to check for a success code in existing telemetry if we want to measure the time it took to fail. > Looking at Romain's comment, i had some thoughts > > - BITS might not lead to faster downloads because IIRC BITS can throttle the downloads, right? That is one reason. If BITS fails for whatever reason then we'll fallback to using Firefox to download the update which will also take longer due to the time it takes to fail and start the download in Firefox. There are probably other reasons as well. > - but the promise of BITS is that downloads will continue even if Firefox is closed and hence the following hypotheses > - (a)we have more profiles with completed downloads (of MAR files) > - (b) we have more profiles that successfully update to newer version of Firefox More installations (profiles if you prefer since that more closely matches telemetry) that would download the MAR file sooner and hence update sooner. I don't anticipate that it should have a significant affect on success of downloading or updating. The main reason for older Firefox versions taking a very long time to update was identified using telemetry and fixed in Firefox 49 and further improvements were made in Firefox 52. This can be seen with the "Update Watersheds" by comparing Firefox 43.0.1 and 47.0.2 with Firefox 56.0 in the "Out of date, of concern client distribution across Firefox versions" section of the "Firefox Application Update Out Of Date Dashboard". https://telemetry.mozilla.org/update-orphaning/#version-dist-chart The main reason I recommended using BITS to download while Firefox isn't running is to update the clients that seldom run Firefox or when they do run Firefox they only have it open for a very short period of time. This can be seen in the "Out of date, potentially of concern reason distribution" section of the "Firefox Application Update Out Of Date Dashboard". Specifically, the clients that "Ran for less than 2 hours" during the previous 12 weeks (84 days) and have "Less than 4 update pings" during the previous 12 weeks (84 days). https://telemetry.mozilla.org/update-orphaning/#not-min-reqs-chart > Thus while Romain did ask for baseline of download rates, ultimately i think were interested hypotheses (a) and (b), correct? For this phase of the project I am interested in getting Windows clients that seldom run Firefox or only run Firefox for a short period of time updated faster without adversely affecting the clients that are already considered to be updating at a reasonable pace. If all Windows clients update faster with the BITS download implementation then that is all the better. For the full implementation I am interested in all Windows clients updating faster, have less interaction with updating, and possibly some other improvements we've been considering. > Hence once this lands we hope to see > > 1. for seldom/less users of Firefox, higher successful MAR download (do we measure currently if success of MARS download?) aftre they get this feature. Faster successful download rate for these users. We don't expect there to be a change in success vs. failure of downloads. We already measure download success and failure (including error code). Also, a value for the interval between "Update Download" and "Update Download Ready" represents a successful download will be the likely path we take. > 2. for same set of users, higher update rate (do we also measure if the MAR file successfully applied?) Faster successful update rate for these users. We don't expect there to be a change in success vs. failure of applying updates. We already measure applied success and failure (including error code). Also, a value for the interval between "Update Pending" to "Update Applied" represents an update that was successfully applied will be the likely path we take. > Lastly, why do you say "*The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients.*" This is just the BITS download portion of the Update Agent. The full project would also perform the update check, the download, and apply the update all without Firefox running.
(In reply to "Saptarshi Guha[:joy]" from comment #10) > So if i understand correctly, these are time durations(intervals)? Correct and they are in seconds. > If a profile successfully updates, then time between Update Check and Update Applied is the time taken to successfuly update. Correct > If "Updated Applied" never happened, one would have to backtrack to the last successful stage to see time taken to last successful stage. What would be the values of missing stages? i guess their entries would be missing? That is what I am leaning towards. It is also possible to check for a success code in existing telemetry if we want to measure the time it took to fail. > Looking at Romain's comment, i had some thoughts > > - BITS might not lead to faster downloads because IIRC BITS can throttle the downloads, right? That is one reason. If BITS fails for whatever reason then we'll fallback to using Firefox to download the update which will also take longer due to the time it takes to fail and start the download in Firefox. There are probably other reasons as well. > - but the promise of BITS is that downloads will continue even if Firefox is closed and hence the following hypotheses > - (a)we have more profiles with completed downloads (of MAR files) > - (b) we have more profiles that successfully update to newer version of Firefox More installations (profiles if you prefer since that more closely matches telemetry) that would download the MAR file sooner and hence update sooner. I don't anticipate that it should have a significant affect on success of downloading or updating. The main reason for older Firefox versions taking a very long time to update was identified using telemetry and fixed in Firefox 49 and further improvements were made in Firefox 52. This can be seen with the "Update Watersheds" by comparing Firefox 43.0.1 and 47.0.2 with Firefox 56.0 in the "Out of date, of concern client distribution across Firefox versions" section of the "Firefox Application Update Out Of Date Dashboard". https://telemetry.mozilla.org/update-orphaning/#version-dist-chart The main reason I recommended using BITS to download while Firefox isn't running is to update the clients that seldom run Firefox or when they do run Firefox they only have it open for a very short period of time. This can be seen in the "Out of date, potentially of concern reason distribution" section of the "Firefox Application Update Out Of Date Dashboard". Specifically, the clients that "Ran for less than 2 hours" during the previous 12 weeks (84 days) and have "Less than 4 update pings" during the previous 12 weeks (84 days). https://telemetry.mozilla.org/update-orphaning/#not-min-reqs-chart > Thus while Romain did ask for baseline of download rates, ultimately i think were interested hypotheses (a) and (b), correct? For this phase of the project I am interested in getting Windows clients that seldom run Firefox or only run Firefox for a short period of time updated faster without adversely affecting the clients that are already considered to be updating at a reasonable pace. If all Windows clients update faster with the BITS download implementation then that is all the better. For the full implementation I am interested in all Windows clients updating faster, having less interaction with updating, and possibly some other improvements we've been considering. > Hence once this lands we hope to see > > 1. for seldom/less users of Firefox, higher successful MAR download (do we measure currently if success of MARS download?) aftre they get this feature. Faster successful download rate for these users. We don't expect there to be a change in success vs. failure of downloads. We already measure download success and failure (including error code). Also, a value for the interval between "Update Download" and "Update Download Ready" represents a successful download will be the likely path we take. > 2. for same set of users, higher update rate (do we also measure if the MAR file successfully applied?) Faster successful update rate for these users. We don't expect there to be a change in success vs. failure of applying updates. We already measure applied success and failure (including error code). Also, a value for the interval between "Update Pending" to "Update Applied" represents an update that was successfully applied will be the likely path we take. > Lastly, why do you say "*The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients.*" This is just the BITS download portion of the Update Agent. The full project would also perform the update check, the download, and apply the update all without Firefox running.
(In reply to "Saptarshi Guha[:joy]" from comment #10) > So if i understand correctly, these are time durations(intervals)? Correct and they are in seconds. > If a profile successfully updates, then time between Update Check and Update Applied is the time taken to successfuly update. Correct > If "Updated Applied" never happened, one would have to backtrack to the last successful stage to see time taken to last successful stage. What would be the values of missing stages? i guess their entries would be missing? That is what I am leaning towards. It is also possible to check for a success code in existing telemetry if we want to measure the time it took to fail. > Looking at Romain's comment, i had some thoughts > > - BITS might not lead to faster downloads because IIRC BITS can throttle the downloads, right? That is one reason. If BITS fails for whatever reason then we'll fallback to using Firefox to download the update which will also take longer due to the time it takes to fail and start the download in Firefox. There are probably other reasons as well. > - but the promise of BITS is that downloads will continue even if Firefox is closed and hence the following hypotheses > - (a)we have more profiles with completed downloads (of MAR files) > - (b) we have more profiles that successfully update to newer version of Firefox More installations (profiles if you prefer since that more closely matches telemetry) that would download the MAR file sooner and hence update sooner. I don't anticipate that it should have a significant affect on success of downloading or updating. The main reason for older Firefox versions taking a very long time to update was identified using telemetry and fixed in Firefox 49 and further improvements were made in Firefox 52. This can be seen with the "Update Watersheds" by comparing Firefox 43.0.1 and 47.0.2 with Firefox 56.0 in the "Out of date, of concern client distribution across Firefox versions" section of the "Firefox Application Update Out Of Date Dashboard". https://telemetry.mozilla.org/update-orphaning/#version-dist-chart The main reason I recommended using BITS to download while Firefox isn't running is to update the clients that seldom run Firefox or when they do run Firefox they only have it open for a very short period of time. This can be seen in the "Out of date, potentially of concern reason distribution" section of the "Firefox Application Update Out Of Date Dashboard". Specifically, the clients that "Ran for less than 2 hours" during the previous 12 weeks (84 days) and have "Less than 4 update pings" during the previous 12 weeks (84 days). https://telemetry.mozilla.org/update-orphaning/#not-min-reqs-chart > Thus while Romain did ask for baseline of download rates, ultimately i think were interested hypotheses (a) and (b), correct? For this phase of the project I am interested in getting Windows clients that seldom run Firefox or only run Firefox for a short period of time updated faster without adversely affecting the clients that are already considered to be updating at a reasonable pace. If all Windows clients update faster with the BITS download implementation then that is all the better. For the full implementation I am interested in all Windows clients updating faster, having less interaction with updating, and possibly some other improvements we've been considering. > Hence once this lands we hope to see > > 1. for seldom/less users of Firefox, higher successful MAR download (do we measure currently if success of MARS download?) aftre they get this feature. Faster successful download rate for these users. We don't expect there to be a change in success vs. failure of downloads. We already measure download success and failure (including error code). Also, a value for the interval between "Update Download" and "Update Download Ready" represents a successful download will be the likely path we take. > 2. for same set of users, higher update rate (do we also measure if the MAR file successfully applied?) Faster successful update rate for these users. We don't expect there to be a change in success vs. failure of applying updates. We already measure applied success and failure (including error code). Also, a value for the interval between "Update Pending" to "Update Applied" represents an update that was successfully applied will be the likely path we take. > Lastly, why do you say "*The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients.*" This is just the BITS download portion of the Update Agent. The full project would also perform the update check, the download, and apply the update - all without Firefox running.