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

4.1.4 speed estimate is not completely innacurate #9946

Open
CyrusNajmabadi opened this Issue Dec 1, 2018 · 10 comments

Comments

Projects
None yet
6 participants
@CyrusNajmabadi

CyrusNajmabadi commented Dec 1, 2018

image

Something in the latest release has changed with speed estimate. It now is often wildly wrong. My home connection is 150mbps. So i'm obviously not downloading at PB/s or EB/s ranges (yes, i've seen the latter). There must be something wrong in the speed estimator where it occasionally divides by an incredibly tiny value, producing some massive value like this. Obviously, this makes the speed chart totally useless. This definitely did not occur in 4.1.3.

@glassez

This comment has been minimized.

Member

glassez commented Dec 1, 2018

@MarkoXD

This comment has been minimized.

MarkoXD commented Dec 1, 2018

If I remember correctly, that was reported before, as well as, different speed in status bar and in the list of torrents.

@dzmat

This comment has been minimized.

Contributor

dzmat commented Dec 2, 2018

For an unknown reason here slips in a single reading circa 2^63 from underlying code. Divided by 72 (averaging interval for 6 hour graph) it gives spikes of 114 PBytes/s on 6hour graph and 1.3 EBytes/s on 30min graph. But this event happens too rarely and unpredictably to be effectively debugged. Personally I suspect some change in libtorrent, but have no proves here :( .

May be it worth to add some filtering / logging for incoming data?

@CyrusNajmabadi

This comment has been minimized.

CyrusNajmabadi commented Dec 2, 2018

Can you not clamp or filter out clearly excessive values. In general when I've coded up speed estimating software, the greater the deviation from the average, the more samples you need to take to get certainly that things are actually changing. At most you let things grow by 2x per sample. In a bandwidth scenario that means it would take a full 40 samples to truly reach PB/s from MB/s. Since, in reality, people will only go up/down a couple of orders of magnitude, for normal speed changes, you catch up in just a handful of samples. Whereas, if you get utterly crazy values above/below the real value, you aren't really affected unless you keep getting them coming in.

@CyrusNajmabadi

This comment has been minimized.

CyrusNajmabadi commented Dec 3, 2018

Note: it's not just PB or EB range. I also get stuff like this:

image

It seems like there really needs to be something to prevent scaling from going out of control.

@FranciscoPombal

This comment has been minimized.

Contributor

FranciscoPombal commented Dec 3, 2018

@CyrusNajmabadi
Does this happen before/after suspending your system, by any chance? I think I remember seeing this happen once in such circumstances.

@CyrusNajmabadi

This comment has been minimized.

CyrusNajmabadi commented Dec 3, 2018

Nope system never suspends

@CyrusNajmabadi

This comment has been minimized.

CyrusNajmabadi commented Dec 4, 2018

Note that the spikes are completely bizarre:

image

Here we can see a gentle ramp up at a consistent pace. Then, right in the middle, an outlier value that skews the entire result.

@MarkoXD

This comment has been minimized.

MarkoXD commented Dec 6, 2018

Does anyone know when this problem is going to be fixed? It's happening ever since v4.

screenshot_1

@ltGuillaume

This comment has been minimized.

ltGuillaume commented Dec 14, 2018

image

Ooh, I win! Only been seeing this behavior since v4.1.4, too. System wasn't suspended before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment