-
-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about the speeds #488
Comments
The library currently exposes three things:
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!
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!
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? |
@alanmcgovern I don't know why
The I'm trying to make the fresh client in WinUI 3 (it was my fault, but there is no turning back!). 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 You can easy add TimeOnly 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 :( |
Add docs covering each property, describing exactly how the value is calculated. Addresses #488
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.
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. I'd be open to a patch which adds these kinds of metrics!
There's 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. |
For some reason, I thought it takes one second. I can't use I agree with you the metrics are very different.
It seems, there are a bug [v2.0.1, winui3, sandboxed]: Pseudo-Code:
It looks like -- It would be nice if you add the engine property |
qbittorrent has the next speed metrics:
Here I've found a three ones:
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!
The text was updated successfully, but these errors were encountered: