The torrent piece size is set at torrent creation time by [torrentool](https://github.com/idlesign/torrentool/blob/5f37d6dcc304758bae46d01c63e5be0f0a348bfc/torrentool/torrent.py#L354).
Since what we get are piece indices and they might be out of order, we need to actually count how many pieces were downloaded by the node up until a given instant:
```{r}
downloads <- downloads |>
group_by(node, seed_set, run) |>
arrange(timestamp) |>
mutate(
piece_count = seq_along(timestamp)
) |>
ungroup() |>
mutate(completed = piece_count / n_pieces)
```
We can have a brief look at the data to see that it makes sense.
As we can see, the data seems to make sense. To the left we see the "download times" for seeders, which is almost instantaneous, followed by the downloads for the leechers. We see some variability across experiments, with some nodes seemingly struggling to complete their downloads at times.
## Results
### Sanity Checks
Have any nodes failed to download the entire file?
```{r}
downloads |>
group_by(node, seed_set, run) |>
count() |>
ungroup() |>
filter(n != n_pieces)
```
Do we have as many runs and seed sets as we expect?
```{r}
downloads |>
select(seed_set, node, run) |>
distinct() |>
group_by(seed_set, node) |>
count() |>
filter(n != experiment_meta$repetitions)
```
### Computing Download Times
We define the _download time_ for a Deluge node $d$ as the time elapsed from the client's response to an $\addtorrent$ request and the time at which the client reports having received the last piece of the downloaded file. Since seeders are already in possession of the file by construction, we only measure download times at _leechers_.