Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[goose]

Hi,

It would be great if the statistic could show the summary of alle recovered parts and the summary of all compressed traffic.

Last but not least i want to thank all amule dev's and testers for their great work !

Greetings

Sebastian

[Jacobo221]

ye, this has already been asked several times on this forums. I guess it must be already somewhere listed in the ToDo list... or as a side-note on someone's mind
Thanks!

[lfroen]

Assuming that we do add "number of recovered parts" in statistics (total, current, running average, whatever),  can someone tell what this information is good for ?

As I see it, there's no technical problem to display such on amuleweb page for example. But I'm really curious - why someone want to know it ?

I mean - if I tell you "there's X recovered parts in last Y minutes" - what you gonna do about it ?

[djtm]

maybe for WLAN environment, a sort of connection quality pointer

[skolnick]

It could also be an indicator of hardware problems (memory failures, or something like that)

Regards.

[lfroen]

It could also be an indicator of hardware problems

No, not really.

sort of connection quality pointer

Definintly no. Have you ever heard that TCP have checksum ? That every ethernet packer have CRC at the end ? And number of erroneous packets is automatically counted by every standard MAC ?

If you succeded to download something, that :
1. CRC was OK on every packet
2. TCP checksum was OK on every packet
3. Same on every packet amule used in control connection

I hope you've got and idea of how far appication checksum stand from "connection quality" whatever it is

[goose]

Hi,

I just asked for these statistic features because i would like to check the advantage from compression / i.c.h.

These numbers would be informative for me.

Greetings

[Jacobo221]

well, eMule has a much verbose Statistics than aMule has, that's a fact. also, in the statistics window, any information is cool. that's what it's for. it's a place where you go to see any infor that can't been gathered anywer else in the app. more over, aMule's statistics code hasn't been touched for... what? a year? half-a-year?

I'm ok in whatever is about adding info into statistics. problem is... someone has to code it volunteers wanted hehe

[lfroen]

Gathering statistics means overhead. More statistics - more overhead in both memory and cpu time. So it's not innocent like adding picture to dialog.
But ask yourself a question each time you want to add some statistic info - what kind of decision I will make basing on this information ? If you can't point to such action, it really doesn't matter what you write there.
Personally, I never looked to "stats" page of amule - all nessesery "stats" are in "Transfers" page. But this of course is personal preference.

aMule's statistics code

 hasn't been touched for...

The code will be touched when it will be separated away from GUI. Yes, amule holding stats data IN GUI elements ...

[Jacobo221]

lfroen:
the memory overhead that stats suppose can be considered null. one single client or the meta data of a single partfile is occupies more in memory than the whole statistics data (talking about the internal representation, ot about the GUI items). about CPU.. well, stats are refreshed every 5 or 6 seconds (don't remember now). so I don't think taking 10000 CPU cycles (much less in reality I guess, but just to take it to the limits) every 5 seconds is much of a hog

Greetings!

[lfroen]

Jacobo221: Did you read the post before answering ? 2 posts before ?

This information is really just for nice look - you can't make any conclusion looking at it. Read my previos pos for more explanation.

Regarding overhead:

add "number of recovered parts" in statistics (total, current, running average, whatever),

Let's take it one by one:
1. Total - memory O(1), cpu O(1)
2. Current - wtf is it ? There's no such thing as "current". Sum of last X seconds is not "current" if you ask.
3. Running average - memory K*O(size_of_window) cpu - K*O(1) if implemented as FIFO, but the using stl or wx linked list will cause quite big "K".

[Jacobo221]

i just said i think statistics is the place where verbose info goes. and there's never verbose enough to mi opinion.
i did read your posts, all. as i do with all the posts in this forums. you said you see it pointless. i said i think no information is pointless. you said it's too CPU and mem heavy. i said it isn't since it's about 0.00000001% of aMule's needed resources.
who might need that info? i don't know. whill i? mostñy now. but, i do quite often see the clients which are connected to me. whether they are aMule, eMule, x/lMules, shareazas, etc. you don't since you said you never go into the statistics window. well, the fact that yuo don't care about the statistics window doesn't mean that noone does either. do you use categories in downloadlist? i do, and I would be very disapointed if anyone removed them. and i know lots of ppl who don't even know about categories. but since there's someone somewhere who might use it, there they are. features are wellcome from my point of view.

anyway, the thing is, i won' code it. at elast not for the time being. you won't either. k, this dicussion is pointless until someone applies for coding the statistics code. but the feature request is kept in forums, like all threads so twhen someone goes into the statistics code, he can take a look here to see what is wanted.

that is my honest opinion. end if my participation in this thread

Greetings!