Opened 11 years ago

Closed 11 years ago

#3106 closed Bug (invalid)

transmission-remote's reported up/down speeds differ from the web client's reported values

Reported by: krx Owned by:
Priority: Lowest Milestone: None Set
Component: Daemon Version: 1.92
Severity: Minor Keywords:
Cc:

Description

Transmission command line client, transmission-remote, reports incorrect total speeds in both Up and Down counters in full torrents report list (switch "-l"). Web client reports correctly, routers interface reports more or less correct link utilization in both directions. For example:

"-st" switch report:

Upload speed limit: 10 KB/s  (Enabled limit: 20 KB/s; Enabled turtle limit: 10 KB/s)
Download speed limit: 45 KB/s  (Enabled limit: 120 KB/s; Enabled turtle limit: 45 KB/s)

Web client reports 45 and 10 as expected, with expected small fluctuations. Router's external interface speed also fluctuates as expected around these values. Meanwhile "transmission-remote -l":

Sum:          202.8 GB               5.0    22.5
or
Sum:          202.8 GB               7.5    33.8

As you see, the difference is some % of the actual speed - respectively missing by 25% or 50%, and I have seen more error % level, but they are both the same for UP and DOWN.

Some time ago I have thought, that it is limit's problem (http://trac.transmissionbt.com/ticket/2442), but it is not. Only the reporting sum is bad. Perhaps it was some problem after this code: http://trac.transmissionbt.com/ticket/1833?

Change History (6)

comment:1 Changed 11 years ago by charles

  • Component changed from Transmission to Daemon
  • Summary changed from Reporting of the up/down speeds in command line client is incorrect to transmission-remote's reported up/down speeds differ from the web client's reported values

comment:2 follow-up: Changed 11 years ago by charles

  • Are remote's values consistently wrong? That is, are you certain this isn't just a side-effect of speeds varying a little bit from second to second?
  • Are the per-torrent up/down speeds wrong in transmission-remote too?

comment:3 in reply to: ↑ 2 ; follow-up: Changed 11 years ago by krx

Replying to charles:

  • Are remote's values consistently wrong? That is, are you certain this isn't just a side-effect of speeds varying a little bit from second to second?
  1. Yes, it is.
  2. Yes, I am sure.

In both cases I was running in testing mode atleast a few hours in different circumstances. It is definetelly systemic issue, albeit more annoying, than real problem. Before I was conviced, that it is up/down limits, which are floating (#2442), but I was wrong, or at least the problem was fixed in the meantime. Now I have found out, that the Web client is correct on actual bandwidth usage. I tripple-checked the Web client output with the WAN interface fluctations graph (DD-WRT does not regress-round spikes), and fluctuations are aproximate limit set in the transmission and show by the Web client (there is no any other traffic except of transmission (its DNS queries/etc).

  • Are the per-torrent up/down speeds wrong in transmission-remote too?

I will look up and do this simple arithmetics, when the Transmission will get back from yet another long verify :-)

comment:4 in reply to: ↑ 3 Changed 11 years ago by charles

Replying to krx:

  • Are the per-torrent up/down speeds wrong in transmission-remote too?

I will look up and do this simple arithmetics, when the Transmission will get back from yet another long verify :-)

Is the verify done yet? :)

comment:5 Changed 11 years ago by charles

After testing this quite a bit on my end, I'm not seeing the same behavior. I agree that the speeds never quite add up the same because the different clients are polling the session at different moments in time, but the trends definitely follow each other. I'm not seeing transmission-remote consistently show 1/3 to 1/2 the speed of the web client....

comment:6 Changed 11 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

Another tester in #transmission couldn't reproduce this either.

Closing this ticket as "invalid" for now. Please feel free to reopen this ticket when more information is available about how to reproduce this issue.

Note: See TracTickets for help on using tickets.