Question about the speeds

[YegorStepanov]

qbittorrent has the next speed metrics:

Here I've found a three ones:

Manager.Monitor.DataBytesDownloaded 
Manager.Monitor.ProtocolBytesDownloaded
Manager.Monitor.DownloadSpeed

Can you clarify what these means and how to find the rest?

..

As I understand, to get payload speed, we should take the delta of DataBytesDownloaded.

DownloadSpeed is the payload+overhead.

ProtocolBytesDownloaded is the DHT+Tracker.

I'm just guessing because I can't find the regularity.

..

Thank you for maintaining the wonderful library!

[alanmcgovern]

The library currently exposes three things:

• 'DownloadSpeed' or 'DownloadRate' => total bytes received from the peer (overhead + payload)
• 'DataBytesDownloaded' or 'DataBytesReceived' => total bytes of payload received (the actual data which will be written to disk)
• 'ProtocolBytesDownloaded' or 'ProtocolBytesReceived' => Total bytes of non-payload data sent to/from the peer. This is every byte which is not written to disk as part of the files being downloaded.

i.e. A piece message typically has 17 bytes of overhead and 16kB of payload data, so every time a PieceMessage is received 'DataBytesReceived' is incremented by 16kB and 'ProtocolBytesReceived' is incremented by 17 bytes. This increases accuracy a tiny bit.

I'd love it if you could review the pull request listed above to make sure the new documentation is clear enough!

As I understand, to get payload speed, we should take the delta of DataBytesDownloaded.

If you want to get an accurate payload speed and protocol speed, it would be simpler to expose those two values in the library than compute them yourself. The data is already there, it just wasn't hugely important to anyone before so it hasn't been exposed in this way. Let me know if you'd like this added!

DownloadSpeed is the payload+overhead.
Exactly!

ProtocolBytesDownloaded is the DHT+Tracker.
Not quite - it's every message received from a peer which is not payload. Nothing (currently) tracks DHT or Tracker bytes.

It would be interesting, and easy, to add a SpeedMonitor which tracks DHT messages sent/received. I'll add that in a few minutes because it'd be a nice stat!

However, I don't see any real value in trying to record the amount of bytes sent to/from a HTTP or UDP tracker. While it would be easy to accurately track UDP tracker message sizes, it's harder for HTTP when you take into account SSL connection negotiation which happens under the hood. Also, trackers are typically contacted once every 10-30 minutes, so who cares about whether the request is 70 bytes or 70 kB if it occurs so infrequently?

[YegorStepanov]

@alanmcgovern I don't know why qbittorrent displays DHT/Tracker at the graph. I thought this information is useful for someone, but currently not sure.

Also, trackers are typically contacted once every 10-30 minutes, so who cares about whether the request is 70 bytes or 70 kB if it occurs so infrequently?

The qbittorrent's graph. :)

I'm trying to make the fresh client in WinUI 3 (it was my fault, but there is no turning back!).
So I'm need to display the payload download speed in datagrid and at the plots. It would be great, if you added it.
Thanks.

What you think about stats since the torrent added (not current session)? It's not hard to cache the values to user, but it would be an improvement.

[Edit] I mean about StartupDataBytesReceived only, but with better naming.
[Edit2]
It's easy to get: Manager.Size * Manager.PartialProgress / 100. I think the precision is fine.

You can easy add TimeOnly ETA too.

The last metrics like TimeActive, SeededTimeActive (time active of each states?) and the averages of speed will affect the performance for all. Unfortunately, I will have to do them myself :(

[alanmcgovern]

I added stats for DHT. Messages are constantly being sent so it's a fairly reasonable thing to track. #490

For trackers - I'm still not sure what metric makes sense here. The current measurement is an average over 10-12 seconds. This works well for peer connections and DHT as messages are sent 'all' the time.

Tracker scrapes/announces happen every 30 minutes normally. As such, what would bytes/second even mean in that context? Data would only be transferred for 1 second over a 30 minute time period.

What you think about stats since the torrent added (not current session)? It's not hard to cache the values to user, but it would be an improvement.

There is a pretty reasonable way to cache this information if you knew exactly what you wanted, and how you wanted it exposed in the library. ClientEngine.SaveStateAsync and ClientEngine.RestoreStateAsync are the two APIs you need to consider. It would be pretty reasonable/easy to add additional data when serializing the engine, and then you'd just have to load the values when deserializing it.

I'd be open to a patch which adds these kinds of metrics!
This would probably be best cached at the client level rather than the library level.

The last metrics like TimeActive, SeededTimeActive (time active of each states?) and the averages of speed will affect the performance for all. Unfortunately, I will have to do them myself :(

There's TorrentManager.StartTime which stores the most recent time StartAsync or HashAsync was invoked, but there's no API which tracks the amount of time the current state has been active for. It'd be easy enough to add another DateTime property which is updated every time the Mode changes. Is that all you'd need?

There are many unique stats different applications may need, so my personal preference would be to make sure there's a convenient way to derive the stats you want as opposed to building in every possible statistic.

[YegorStepanov]

The current measurement is an average over 10-12 seconds.

For some reason, I thought it takes one second. I can't use .Rate properties and should do it through delta.

I agree with you the metrics are very different.

ClientEngine.SaveStateAsync and ClientEngine.RestoreStateAsync are the two APIs you need to consider.

It seems, there are a bug [v2.0.1, winui3, sandboxed]:
If you add Torrent file the Manager.Torrent property will be filled.
But if you restore engine, some properties of Manager.Torrent will have ctor values

Pseudo-Code:

private async Task LoadTorrentAsync(Torrent torrent)
{
    TorrentManager manager = await engine.LoadTorrentAsync(torrent, SavedFolder.Path);
    await manager.StartAsync();
    await manager.Engine.SaveStateAsync();
    _ = manager.Torrent.CreationDate != new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
}


engine = await ClientEngine.RestoreStateAsync(stateFilePath);
bool always = engine.Torrents[0].Torrent.CreationDate == new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

It looks like SHA1, Publisher, PublisherURL, Comment, CreatedBy are default always too. Name, Files works correctly.

--

It would be nice if you add the engine property AutoSaveState. As I understand it after every engine.DoSmth() I should call engine.SaveStateAsync(). It's error-prone and not obvious.