Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4047 closed Bug (fixed)

Transfer speed shown as 0

Reported by: andlommy Owned by: jordan
Priority: Normal Milestone: 2.22
Component: libtransmission Version: 2.21
Severity: Normal Keywords:
Cc:

Description

After a while, all torrent upload/download speeds are displayed as 0 in the web interface, and in RPC clients, although transfers are happily running and progress bar is being updated with current progress. Running on Synology DS410 platform. not sure whether bug is specific to the version

Attachments (1)

transfers.jpg (234.6 KB) - added by andlommy 11 years ago.
Screenshot showing the bug, and measurment of network bandwidth on the box running the daaemon

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by andlommy

Screenshot showing the bug, and measurment of network bandwidth on the box running the daaemon

comment:1 Changed 11 years ago by KyleK

I experience the same thing. Restarting the daemon helps, but after a yet undetermined amount of time the displayed speeds go towards 0.

comment:2 Changed 11 years ago by jordan

Could someone who's experiencing this behavior please attach a log of some of the RPC messages that contain speed information? I'd like to see the raw speeds that get sent over via json.

comment:3 Changed 11 years ago by jusid

I also noticed that when a Transmission 2.20 daemon runs for a while, and then I start a new torrent download, the displayed download speed is very low for whole torrent and for individual peers. In the peers view I see, that only few of peers are sending data to me. I don't know if data is transferred at full speed and this is only a display bug. Restart of the daemon resolves the problem and speeds are displayed correctly. For some time... There were no such problem with Transmission 2.1x

Last edited 11 years ago by jusid (previous) (diff)

comment:4 Changed 11 years ago by KyleK

jordan: I don't have any logged RPC messages at hand, but that was the first thing I checked, and the speed values were wrong already (eliminating a problem with transmission-remote).

Out of a hunch (and with pure intuition), I decided to do a rollback of r11783, which seems to have fixed the problem. Don't ask me why though, that code is all voodoo to me :)

comment:5 Changed 11 years ago by jordan

KyleK: so, just to make sure I understand comment:4 correctly, you're saying trunk - r11783 works correctly?

If so, then *nice* detective work KyleK... :)

comment:6 Changed 11 years ago by KyleK

Yes, you understand correctly. Current trunk minus r11783 and displayed speeds are in line of what my router reports, even after the daemon ran over a day. (Before, displayed speed dropped to 0 after 3 or so hours).

It wasn't detective work at all, it was pure and utter luck :) I very vaguely remembered an earlier issue (many revisions before this one) that involved caching of gettimeofday() values to reduce CPU usage. r11783 was the most recent changeset that did something similar so I decided to just revert and and see what happens. The patch is fairly trivial after all.

So, before you revert the changeset on the trunk, please check if my actions weren't insane :)

comment:7 Changed 11 years ago by KyleK

I was wondering though: Since this is a a change in libtransmission, shouldn't it have affected all versions of Transmission (including the MacOS GTK clients)?

comment:8 Changed 11 years ago by jordan

Many people on several platforms have reported that speeds are being misreported in 2.20 and 2.21... so, yes. :)

comment:9 Changed 11 years ago by jordan

  • Component changed from Daemon to libtransmission
  • Milestone changed from None Set to 2.22
  • Owner set to jordan
  • Status changed from new to assigned

jordan * r12059 libtransmission/ (peer-io.c peer-mgr.c session.c session.h): (trunk libT) #4047 "transfer speed shown as 0" -- revert r11783 (#3950) because it caused speed misreporting.

jordan * r12060 /branches/2.2x/libtransmission/ (peer-io.c peer-mgr.c session.c session.h): (trunk 2.2x) #4047 "transfer speed shown as 0" -- revert r11783 (#3950) because it caused speed misreporting.

comment:10 Changed 11 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:11 Changed 11 years ago by livings124

#4030 is most likely a duplicate of this.

Note: See TracTickets for help on using tickets.