1,3x: Session Transfer Vs Actual Download (Fixed in 1.40)

[Jordan]

Also, I noticed when testing: when Transmission is completely idle (i.e. absolutely no torrents active/downloading/uploading,) the download/upload speeds go up to max 5 kb/s for a few seconds at a time at random intervals. Is this a bug, or is it some kind of overhead (Transmission checking the status of paused torrents?)

The bandwidth counters now include protocol overhead due to ticket #617 finally getting fixed. So that's unrelated to this bug...

So this bug was non-existent before 1.30 - is it not possible to just revert some of the code to how it was in 1.22?

Actually that's exactly what that last commit did -- reverted back to the 1.2x method of deciding which blocks to ask for from which peers, which is where the overdownloading was coming from.

[Jethryn Freyman]

The bandwidth counters now include protocol overhead due to ticket #617 finally getting fixed.

Excellent, those ridiculously high download speeds Transmission was reporting were making me feel way happier than I ought to be

[Toby]

The bandwidth counters now include protocol overhead due to ticket #617 finally getting fixed. So that's unrelated to this bug...

Does that mean the extra 15.2 MB (when I downloaded 173.3 MB of a file but the session transfer was 188.5 MB) would just be the protocol overhead?

[livings124]

Toby: what version is that for? A nightly build?

[alison87]

Okay i did a longer run last night with snapshot 6882.

Session transfer = 806.2MB
Torrent(s) downloaded total = 703.3MB

Losing 100MB is a bit of a pain, but it is nothing compared to the gigabytes that we were losing in 1.34. It could also be due to protocol overhead, if that's being recorded now.

What i would suggest is adding a debug log every time a chunk gets thrown away because we already have it. Imo that should also be added to the failed DL total, so it's more transparent to the user where the data is going. Perhaps you could split failed DL into failed-due-to-hash-fail and failed-due-to-already-having-it. Presumably the latter could hypothetically be optimized away in a "perfect" implementation.

As for the jumpy download - i wasn't here to watch the numbers this time, but what i saw the other day was jumping 4KB/s-15KB/s-30KB/s-45KB/s and back down again (or numbers around that vicinity). I don't think the protocol overhead would be that much, but i guess it's possible. That was also at the beginning of the torrent so i guess it could've still been winding up. It's not really a problem when you're downloading overnight, only when you're watching the kettle boil, as it were.

Either way, looking good guys - thanks.

[Toby]

Toby: what version is that for? A nightly build?

Nightly, r6882.

Losing 100MB is a bit of a pain, but it is nothing compared to the gigabytes that we were losing in 1.34. It could also be due to protocol overhead, if that's being recorded now.

Agreed. But surely the protocol overhead couldn't be that much... Is it possible that there's still a significant portion of the data being thrown out? (100MB is quite a bit.) Adding a new debug log is a very good idea.

[McFly3]

Today I downloaded the latest nightly and I am going to check the missing data with it. My first observations:

a) The speed fluctuates a lot and therefor the ETA of a download.
b) I am having only one torrent download concurrently. The total download/upload speed at the top of the window is different to the one that appears for at the bottom of the downloading torrent.

e.g. Total download / upload speed 17.5KB/s / 15.3 KB/s (this is consistent with activity monitor). This does not affect the download stats.
At torrent level it is 2.8KB/s / 2.6KB/s

Question: I doubt that this is overhead, what is transmission using that bandwidth for if not contributing to torrent download?

I am unable to comment on the amount of data downloaded right now. I'll wait for the download to complete. It might take a long time due to the speed.

1 hour later

If I look at only the total download stats against the actual download for a particular torrent, I see that the "data leakage / loss" seems to be less. But there is a problem with the download / upload speed, see observation B above. I am reverting to 1.22 since this is affecting my download quota with the service provider. Of course i will test nightly builds when new related patches are available.

[eisa01]

I hadn't really noticed this bug before today, so I tried out the latest nightly r6906. From my very limited testing, I would say it is fixed.

[Jordan]

Toby: what version is that for? A nightly build?

Nightly, r6882.

Losing 100MB is a bit of a pain, but it is nothing compared to the gigabytes that we were losing in 1.34. It could also be due to protocol overhead, if that's being recorded now.

Agreed. But surely the protocol overhead couldn't be that much... Is it possible that there's still a significant portion of the data being thrown out? (100MB is quite a bit.) Adding a new debug log is a very good idea.

My first guess is that if you watch the download, the overhead will mostly come in the last 5% (or so) of the torrent download. Can you test this out to confirm or refute this theory?

[jah]

Does overhead really take up around 10%? I'm afraid I'm here to report a similar experience on the latest nightly. Downloaded a 1004 MB torrent overnight, however the total session transfer was 1.09 gig (ie about 100mb/10% more).

If this is not a bug then so be it, I would be good to know though

[Yada]

A bit off-topic, but is the overhead also calculated into the ETA? Cause I would say that having the overhead showing up in the speeds is a good thing, but it should not be used when calculating the remaining time, as that jumps from 2 days to 9 days to 4 days to 6 days to 18 hours etc etc every other second on a big torrent I'm downloading currently.

I do realise there's still a ticket open for unreliable ETA's, so it could be planned to fix later on. I was just wondering.

[teedoff087]

Just downloaded the latest nightly build (6919). Tremendous improvement. The Have count actually reflects my transfer speed.

[Yada]

I launched Transmission earlier tonight to download two 350 MB files. When they were done, session transfer was up at about 850 MB, with no failed downloaded data at all. No idea where that extra 150 MB went.

[livings124]

Yada: version number would be appreciated.

[Yada]

I am sorry, I just realised I forgot to note that. That was on 1.34+ r6939.