Hi Saptarshi, We're limited in what data points we can get from BITS with just the BITS download implementation. We should be able to get many more BITS data points with the complete Update Agent implementation but with just the BITS download implementation the data points are much more limited. Below I've outlined the data points we can get for the BITS update download and the Firefox update download that I hope will suffice for the analysis. Telemetry for the overall measurement of the difference that downloading with BITS compared to downloading in Firefox can be achieved using the average time it takes to finish an update when using BITS update download and the Firefox update download. All intervals will be recorded in seconds. Interval from the start of the "Update Check" to the start of the "Update Download". Interval from start of the "Update Download" to "Update Download Ready". Note: The phrase "Update Download Ready" represents a couple of different possible next steps: 1. Start of "Update Staging" when staging is available. This will be followed by "Update Pending". 2. "Update Pending" when the update will be applied without staging. Interval from "Update Download Ready" to "Update Pending". This will be the time in seconds to stage the update or 0 when it isn't possible to stage the update. Interval from "Update Pending" to "Update Applied". To provide a consistent comparison for the difference in time that it takes for a client to update the intervals from start of "Update Check" or "Update Download" through any of the phases that come after "Update Download" can be added. I suggest using "Update Applied" to get the overall affect that using BITS to download an update has on getting clients updated though measuring the next phase of "Update Download Ready" would exclude failures that occur in later phases. Note: the initial implementation of BITS download will likely have little affect on the majority of clients which already update within a short period of time but it should show an improvement for clients that only run Firefox seldom and / or for short periods of time. The full Update Agent implementation which is planned to happen after BITS download should show an improvment for the majority of clients. It is possible to just record a single interval from "Update Download" through "Update Download Ready" for this but the additional intervals will provide telemetry that we can use to better evaluate issues with the different phases and their affect on updating clients. The app version that was updated from. Bytes per second for the download. We won't always be able to record this for the full download in the BITS case. Total bytes downloaded. Since there are cases where different telemetry client ID's would submit individual intervals they will be stored in the active-update.xml until the update has finished so they are all submitted at the same time and by the same telemetry client ID.
Bug 1528278 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hi Saptarshi, We're limited in what data points we can get from BITS with just the BITS download implementation. We should be able to get many more BITS data points with the complete Update Agent implementation but with just the BITS download implementation the data points are much more limited. Below I've outlined the data points we can get for the BITS update download and the Firefox update download that I hope will suffice for the analysis. Telemetry for the overall measurement of the difference that downloading with BITS compared to downloading in Firefox can be achieved using the average time it takes to finish an update when using BITS update download and the Firefox update download. All intervals will be recorded in seconds. Interval from the start of the "Update Check" to the start of the "Update Download". Interval from start of the "Update Download" to "Update Download Ready". Note: The phrase "Update Download Ready" represents a couple of different possible next steps: 1. Start of "Update Staging" when staging is available. This will be followed by "Update Pending". 2. "Update Pending" when the update will be applied without staging. Interval from "Update Download Ready" to "Update Pending". This will be the time in seconds to stage the update or 0 when it isn't possible to stage the update. Interval from "Update Pending" to "Update Applied". To provide a consistent comparison for the difference in time that it takes for a client to update the intervals from start of "Update Check" or "Update Download" through any of the phases that come after "Update Download" can be added. I suggest using "Update Applied" to get the overall affect that using BITS to download an update has on getting clients updated though measuring the next phase of "Update Download Ready" would exclude failures that occur in later phases. Note: the initial implementation of BITS download will likely have little affect on the majority of clients which already update within a short period of time but it should show an improvement for clients that only run Firefox seldom and / or for short periods of time. The full Update Agent implementation which is planned to happen after BITS download should show an improvment for the majority of clients. It is possible to just record a single interval from "Update Download" through "Update Download Ready" for this but the additional intervals will provide telemetry that we can use to better evaluate issues with the different phases and their affect on updating clients. The app version that was updated from. Bytes per second for the download. We won't always be able to record this for the full download in the BITS case. Total bytes downloaded. Since there are cases where different telemetry client ID's would submit individual intervals they will be stored in the active-update.xml until the update has finished so they are all submitted at the same time and by the same telemetry client ID.
Hi Saptarshi, We're limited in what data points we can get from BITS with just the BITS download implementation. We should be able to get many more BITS data points with the complete Update Agent implementation but with just the BITS download implementation the data points are much more limited. Below I've outlined the data points we can get for the BITS update download and the Firefox update download that I hope will suffice for the analysis. Telemetry for the overall measurement of the difference that downloading with BITS compared to downloading in Firefox can be achieved using the average time it takes to finish an update when using BITS update download and the Firefox update download. All intervals will be recorded in seconds. Interval from the start of the "Update Check" to the start of the "Update Download". Interval from start of the "Update Download" to "Update Download Ready". Note: The phrase "Update Download Ready" represents a couple of different possible next steps: 1. Start of "Update Staging" when staging is available. This will be followed by "Update Pending". 2. "Update Pending" when the update will be applied without staging. Interval from "Update Download Ready" to "Update Pending". This will be the time in seconds to stage the update or 0 when it isn't possible to stage the update. Interval from "Update Pending" to "Update Applied". To provide a consistent comparison for the difference in time that it takes for a client to update the intervals from start of "Update Check" or "Update Download" through any of the phases that come after "Update Download" can be added. I suggest using "Update Applied" to get the overall affect that using BITS to download an update has on getting clients updated though measuring the next phase of "Update Download Ready" would exclude failures that occur in later phases. Note: the initial implementation of BITS download will likely have little affect on the majority of clients which already update within a short period of time but it should show an improvement for clients that only run Firefox seldom and / or for short periods of time. The full Update Agent implementation which is planned to happen after BITS download should show an improvment for the majority of clients. It is possible to just record a single interval from "Update Download" through "Update Download Ready" for this but the additional intervals will provide telemetry that we can use to better evaluate issues with the different phases and their affect on updating clients. The app version that was updated from. Bytes per second for the download. We won't always be able to record this for the full download in the BITS case but we can get bytes per second for BITS while Firefox is running. Total bytes downloaded. Since there are cases where different telemetry client ID's would submit individual intervals they will be stored in the active-update.xml until the update has finished so they are all submitted at the same time and by the same telemetry client ID.
Hi Saptarshi, We're limited in what data points we can get from BITS with just the BITS download implementation. We should be able to get many more BITS data points with the complete Update Agent implementation but with just the BITS download implementation the data points are much more limited. Below I've outlined the data points we can get for the BITS update download and the Firefox update download that I hope will suffice for the analysis. Telemetry for the overall measurement of the difference that downloading with BITS compared to downloading in Firefox can be achieved using the average time it takes to finish an update when using BITS update download and the Firefox update download. All intervals will be recorded in seconds. Interval from the start of the "Update Check" to the start of the "Update Download". Interval from start of the "Update Download" to "Update Download Ready". Note: The phrase "Update Download Ready" represents a couple of different possible next steps: 1. Start of "Update Staging" when staging is available. This will be followed by "Update Pending". 2. "Update Pending" when the update will be applied without staging. Interval from "Update Download Ready" to "Update Pending". This will be the time in seconds to stage the update or 0 when it isn't possible to stage the update. Interval from "Update Pending" to "Update Applied". To provide a consistent comparison for the difference in time that it takes for a client to update the intervals from start of "Update Check" or "Update Download" through any of the phases that come after "Update Download" can be added. I suggest using "Update Applied" to get the overall affect that using BITS to download an update has on getting clients updated though measuring the next phase of "Update Download Ready" would exclude failures that occur in later phases. Note: the initial implementation of BITS download will likely have little affect on the majority of clients which already update within a short period of time but it should show an improvement for clients that only run Firefox seldom and / or for short periods of time. The full Update Agent implementation which is planned to happen after BITS download should show an improvement for the majority of clients. It is possible to just record a single interval from "Update Download" through "Update Download Ready" for this but the additional intervals will provide telemetry that we can use to better evaluate issues with the different phases and their affect on updating clients. Additional data that will be submitted to telemetry: The app version that was updated from. Bytes per second for the download. We won't always be able to record this for the full download in the BITS case but we can get bytes per second for BITS while Firefox is running. Total bytes downloaded. Since there are cases where different telemetry client ID's would submit individual intervals they will be stored in the active-update.xml until the update has finished so they are all submitted at the same time and by the same telemetry client ID.