Hi,
On Mon, 12 Sep 2016, Rob van der Hoeven wrote:
Hi Georg,
I think the behavior you see can be explained by an overloaded download server. From the initial downloads graph you can see that there are on average 80.000 downloads a day. From the update pings and update requests graphs you can estimate that there are about 800.000 active Tor browser users. So, when there is a new version of Tor browser the number
We can estimate about 800.000 active daily users if we assume that they are all running their browser at different times during the day to make two pings a day. But some of them probably run it only during some part of the day that is less than 12 hours, which is not enough to make two pings per day. So I think from the update pings, we can only estimate that we have more than 800.000 active daily users, and less than 1.600.000.
To get a more precise estimate of active users, we could maybe count the total of update downloads for each version (in an other graph). Although this would be different from the update pings, as it would also include the occasional users who don't use it everyday.
of update requests massively overloads the download server. The saw-tooth form of the update requests graph is what you expect in this situation. First you get an update request from all users, the next day you get a request from all users minus the users who were updated the previous day (max 80.0000) and so on.
I wonder if it is possible that failed downloads are counted too? That would explain the spikes. But systems that are so heavily overloaded can generate all kinds of weird results.
I think it is possible that failed downloads are counted too. What we are counting is the number of http 302 responses (redirect) to initiate a download. If the redirect works but the actual download fails, it is still counted.
Nicolas