...just continuing discussion from http://bugs.kde.org/show_bug.cgi?id=113170

Here's the KT source that will log all needed data for testing.
http://bugs.kde.org/attachment.cgi?id=12844&action=view

Example output is:

Code: Select all

TEST:{torrent_name}:number_of_sample,current_speed,bytes_downloaded

NOTE: Speed is BYTES/second

Samples should be taken at 500msec (update is triggered every 500msec) but due to bad accuracy this might not be just so.

After KT finishes dl. just grep the log file for TEST:{torrent_name} and import the data in some spreadsheet application (i.e. oocalc).

For my calculations, it is necessary to include for each sample the current time in seconds since epoch (QDateTime::currentDateTime().toTime_t()).

Also, "bytes left" is useful. This could be also calculated from total size and bytes downloaded, but for total size, the log would need some kind of header...

Apart from that, I would log information like leechers/seeders total/connected. It haven't used it yet, but it's thinkable, and the more information the collected logs contain, the better.

State changes: If the user stops the download, quits, the tracker is down/can't be reached etc., this would break the log. So it would be good to log three state transitions:

- ACTIVATED: the torrent becomes active, i.e. "stalled" or "downloading".
- DEACTIVATED: the torrent is not seeding nor stalled nor downloading. This must be logged when there is an error, the user stops the torrent manually, or quits ktorrent
- FINISHED: the download finished, and the torrent switches to "seeding".
After that, no further logging is needed.

This could be logged like
12345678 ACTIVATED
12345800 DEACTIVATED
12349000 FINISHED
(the number is the timestamp)

Then a script can remove the state changes and adjust the time stamps of the samples accordingly.

Ok. So something like this will do?

Code: Select all

{TIMESTAMP},{STATE},{SPEED},{BYTES_DOWNLOADED},{BYTES_LEFT},{SEEDERS},{LEECHERS}

STATE is (activated, deactivated, finished or running)

I have it done. Finally, test header turned out to be something like this:

Code: Select all

{TORRENT_NAME},{TIMESTAMP},{SPEED},{BYTES_DOWNLOADED},{BYTES_LEFT},{PEERS},{STATE}

Notice that {PEERS} is total number of seeders and leechers we are connected to. I had to do this since there is no easy way to find out weather peer is seeder or leecher (at least not without complicating the code).

Samples are taken every second (it's easier to deal with that 500msec), though actuall updates are happening every 500msec.

I just need to test it a bit more before I post the source for testing.

Peer::isSeeder() is the function to use to see if a Peer is a seeder or not.

Ivan wrote:I have it done. Finally, test header turned out to be something like this:

Code: Select all

{TORRENT_NAME},{TIMESTAMP},{SPEED},{BYTES_DOWNLOADED},{BYTES_LEFT},{PEERS},{STATE}

Yeah, that should be fine. Maybe log state changes separately, TorrentControl would need a signal like "stateChanged(oldState, newState)" then which could be connected to the logger.

if the state changes, the logger would write

torrentname,timestamp,state

Ivan wrote:Notice that {PEERS} is total number of seeders and leechers we are connected to. I had to do this since there is no easy way to find out weather peer is seeder or leecher (at least not without complicating the code).

Hmm, what about TorrentControl::getSeederInfo(), and TorrentControl::getLeecherInfo()? Don't they work correctly?

Where is the info logged to? It would be good to have it in a file like .kde/share/apps/ktorrent/log, that would be the most convenient way. I'd write a simple script then to split it in separated logs for every torrent download.

Here's a part from my log file:

Code: Select all

 
{NAME},1128521067,0,3588096,218639203,0,ACTIVATED
{NAME},1128521067,0,3588096,218639203,0,RUNNING
{NAME},1128521068,0,3588096,218639203,0,RUNNING
{NAME},1128521069,0,3588096,218639203,1,RUNNING
{NAME},1128521070,0,3588096,218639203,3,RUNNING
{NAME},1128521071,0,3588096,218639203,3,RUNNING
{NAME},1128521072,0,3588096,218639203,3,RUNNING
{NAME},1128521073,0,3588096,218639203,3,RUNNING
{NAME},1128521074,0,3588096,218639203,3,RUNNING
{NAME},1128521075,0,3588096,218639203,3,RUNNING
{NAME},1128521076,0,3588096,218639203,3,RUNNING
{NAME},1128521077,0,3588096,218639203,3,RUNNING
{NAME},1128521078,0,3588096,218639203,3,RUNNING
{NAME},1128521079,0,3588096,218639203,3,RUNNING
{NAME},1128521080,0,3588096,218639203,3,RUNNING
{NAME},1128521081,2026,3588096,218639203,3,RUNNING
{NAME},1128521082,2292,3588096,218639203,3,RUNNING
{NAME},1128521083,6605,3588096,218639203,3,RUNNING
{NAME},1128521084,6167,3588096,218639203,3,RUNNING
{NAME},1128521085,6421,3588096,218639203,3,RUNNING
{NAME},1128521086,3483,3604480,218639203,3,RUNNING
{NAME},1128521087,2677,3604480,218639203,3,RUNNING
{NAME},1128521088,3014,3604480,218639203,3,RUNNING
{NAME},1128521089,1639,3604480,218639203,3,RUNNING
{NAME},1128521090,1333,3604480,218639203,3,RUNNING
{NAME},1128521091,476,3604480,218639203,3,RUNNING
{NAME},1128521092,476,3604480,218639203,3,RUNNING
{NAME},1128521093,0,3604480,218639203,3,RUNNING
{NAME},1128521094,0,3604480,218639203,3,RUNNING
{NAME},1128521095,0,3604480,218639203,3,RUNNING
{NAME},1128521096,1387,3620864,218639203,3,RUNNING
{NAME},1128521097,1863,3620864,218639203,3,RUNNING
{NAME},1128521098,1863,3620864,218639203,3,RUNNING
{NAME},1128521099,476,3620864,218639203,3,DEACTIVATED

So this should be fine, I think.

Hmm, what about TorrentControl::getSeederInfo(), and TorrentControl::getLeecherInfo()? Don't they work correctly?

Yes they do, same as Peer::isSeeder(), but in that case I'd need Peer id which I can get only by iterating through all peers connected. I wanted to avoid those complications since I don't think having the exact number of seeders/leechers would be of the highest importance. If you insist I can do it...

Where is the info logged to?

It is logged to ~/.kde/share/apps/ktorrent/log

Ivan wrote:I wanted to avoid those complications since I don't think having the exact number of seeders/leechers would be of the highest importance. If you insist I can do it...

Yeah, should be fine. Is there an easy way to get peers total/peers connected? Or does that also need iterating over all peers?

However, if you upload the modified code (maybe a svn diff would do it?), I'll play with it, adjust my scripts, and the logging if I run into problems.

Ok then. I've uploaded the patch file and you can download it here

Hopefully, I'll have my test results tomorrow and I'll place them here.

I put a first script online for extracting the single torrents from the logfile:

http://www-user.rhrk.uni-kl.de/~f_osterf/projekte/estimation/

Frank wrote:I put a first script online for extracting the single torrents from the logfile:

http://www-user.rhrk.uni-kl.de/~f_osterf/projekte/estimation/

I updated the page, including Sample class and estimators. Have to bundle it together at some point and make the hackish script I use for evaluation right now to create a bit more useful output.
Any statistics and/or gnuplot experts around?

I only see ruby script that was here before, maybe you forgot to update the site?

ps: I did use 'refresh' in browser

Ivan wrote:I only see ruby script that was here before, maybe you forgot to update the site?

ps: I did use 'refresh' in browser

Hmm, it shows up here and the file on the server is up-to-date.
But you can also try

http://www-user.rhrk.uni-kl.de/~f_oster ... ation.html

It's the same file, I accidentally copied it twice to the server.

Weird. That last link works. The old one still shows only processlog.rb...

Nevermind, I'll do some testing. Thanks a lot for these scripts.