Because you then have to check and store 10 minutes worth of packets instead of only one number and the query lifetime worth of packets.

And because a slowly changing "connection quality" is a neat GUI feature. :)

To make it visually appealing it would be possible to just substract the minimum connection quality and multiply the result with (1/(1 - min. quality)), so users see "OK, it went negative, so the node was disconnected". Could even be done with a simply 0%-100% "progressbar" which goes red when it closes in on 0 and turns dark read when the node gets disconnected (<=0).

you only need to store 2 additional numbers.. total packages and dropped packages since last check.

You're right - I had a wrong preconception in my mind (store every packet info instead of just adding them up).

But please use TCPs algorithm at least for incoming traffic - there the faster update time is more important, since we replicate the queries.

Besides: Should I keep spending quite some time to find elegant solutions, or should I rather first write a short idea and only do more extensive thinking/testing when you did a test (and save time which might else be wasted on stuff which never gets in)?

You should find time to use a more comfortable communication device then a forum... like IRC maybe

The problem with IRC is that we have different IRC times (I'm online a couple of times per week).

Cant we just disable the allow to become UltraPeer in the UI? Or are you strictly speaking about being an ultrapeer and then trying to normalize traffic?

Or did i misunderstand?

Well the rules apply to both, UP and leafs. After going through some tests and algorithm tuning we pretty much implemented Arnes idea of connection quality calculation.
It's not as smart as Arne would like it to be ;) but should do a better job then the old one.

Just looking a the code :)

Host.calcSentQuality()
in case you have not found it already.