bugmldonkey, a multi-networks file-sharing client - Bugs: bug #19520, The download 'rate' or speed for a...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #19520: The download 'rate' or speed for a given file as displayed by the html display is completely inaccurate

Submitter:  Nick <steelskin>
Submitted:  Thu 05 Apr 2007 11:47:21 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Program malfunction Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2.8.4 Release:  2.8.4
Operating System:  Linux Binaries Origin:  Binary from Savannah
CPU type:  Intel x86

Sun 08 Apr 2007 03:11:00 PM UTC, comment #4: 

"setting the 'download_sample_size' to 100 makes a big improvment"

Patch #5853 is in CVS now.

spiralvoice <spiralvoice>
Group administrator
Thu 05 Apr 2007 10:17:47 PM UTC, comment #3: 

"Is there any reason this could not be set as 100 as the default ?"

No, check patch #5853 for an updated default.

"In your opinion, do you think the way the rates are computed could be improved ?"

Yes, but on my to-do list GUI stuff has lower priority.

For example, the DL speed code still shows data transfered when
the connection to the other client is already closed. It takes
about 10s for the code to notice that the connection was closed.

You can easily verify this by comparing HTML, downloaders with
the GUI display of downloading files. Sometimes files show
data transfered when HTML, downloaders already does not show
the file anymore. I think this is because of higher
download_sample_size, the time used to collect DL speed values
is now longer and data is considered which was received from
already disconnected clients.

spiralvoice <spiralvoice>
Group administrator
Thu 05 Apr 2007 09:50:23 PM UTC, comment #2: 

Yes, setting the 'download_sample_size' to 100 makes a big improvment, many more files are now shown downloading with much improved download rates, although sometimes the individual rates still seem not to add up the total rate, but most of the time they give a fair indication of what files are downloading. There's still something not quite right with the algorithm that computes the individual rates when compared to the likes of emule.

However having said that, your suggestion makes a big improvement compared to the display as it was. Is there any reason this could not be set as 100 as the default ?

I did have a quick look at the section of code that computes these rates however I'm not familiar with the ocaml language, so ended up reading the tutorials and haven't spend any time figuring out how the rate calculations are done. In your opinion, do you think the way the rates are computed could be improved ?

Thanks again for your help, much appreciated.

Nick <steelskin>
Thu 05 Apr 2007 08:55:08 PM UTC, comment #1: 

"I know the HTML GUI auto updates every 12 ? seconds"

Option vd_reload_delay controls this, default is 120s.

"the rate should then be averaged over the last 12 seconds"

Options controlling the computation of download rates are
download_sample_rate and download_sample_size.

The default for download_sample_size of 10 may be too low,
please test values like 100.

spiralvoice <spiralvoice>
Group administrator
Thu 05 Apr 2007 11:47:21 AM UTC, original submission:  

I just want to say what a great job spiralvoice & the devs are doing on mldonkey. It's an excellent program except for one annoying bug it's always had.

First some background ...
I've been using mldonkey with the kmldonkey front end since version 2.8.1 or maybe even earlier. I also use the kmldonkey applet on the taskbar that shows the total upload/download speed. This bug has always been present since at least 2.8.1 and probably has always been there.

Why do I think this bug is important. ?
It's important because it does not show downloads that are in progress when in fact they are, and I believe that new users of mldonkey stop using it because it gives the impression that mldonkey does not download as quickly as other clients. Also note kmlapplet is probably not installed by newbies until they realize it's available.

Observations.
ok, here's an example...
I'm downloading 21 files ...
MLapplet says my upload/download speeds are 10.0/8.5
the html mldonkey gui says for all 21 file '-' (ie nothing) the total download speed for all the files as displayed at the top of the html mldonkey download page is 8.5, ie the same as mlapplet (as you would expect) ... so if we have 8.5 being downloaded why does the rate for each file say nothing is being downloaded.
... and it gets worse ...

For some reason when a rate is shown against a file it has a speed of 18.0. This seems to be a magic number because it keeps showing this number ... not 17.0 not 19.0 not even 17.9 always 18.0. It's as if the speed for that files goes over 18.0 it always shows 18.0

Now, of course the KMLdonkey GUI shows exactly the same ridiculous download rates.

I know the HTML GUI auto updates every 12 ? seconds however that should not matter because the rate should then be averaged over the last 12 seconds. Say for one of those seconds the file in question downloaded 35kb/s and 0kb/s for the remaining 11 seconds the rate should read 2.9kb/s. This would then reflect far more accurately the rate for each download.

In summary..
The total download rates for all the files seems to be accurate for both the mldonkey html display and also the KMLdonkey applet.

The download rates for each individual file are completely inaccurate or don't even show any value at all, even when a file is actually being downloaded.


Nick <steelskin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by spiralvoice (Posted a comment)
  • -email is unavailable- added by steelskin (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-04-08 spiralvoice StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code