In short words: I missused download limit to simulate a soft limit on upload by setting it lower than upload limit.
Down 16 kb/s -> starts load management before upload is full used (no hard limit) Up 20 kb/s -> starts load management at peak The result is a free portion of usable upload bandwith which should result in better latency. And this worked without getting load management nuts. This small portion is not unusable by the node, it can be used to speed things up short time and therefore ensure better latency. Short spikes of load can be compensated without loss of latency and load management (Down limit) would trigger if more than 16kb/s is used incoming. Based on the novel that 1 routed transfer should use the same volume of downbandwith and upload bandwith. So if upload is used with 19kb/s it should result in 19kb/s down and this triggers down limit befor upload limit is reached. Resulting in pinstant reject to slow down. The overhead between 16kb/s to 20kb/s is used to ensure low latency (short speedups). If i look at the stats page this seems to work: --------------------- Transferring Requests: sending 13, receiving 21 a.. Input Rate: 45.3 KiB/sec (of 34.1 KiB) a.. Output Rate: 66.9 KiB/sec (of 1.90 MiB) a.. Total Input: 164 MiB (35.4 KiB/sec) a.. Total Output: 196 MiB (42.2 KiB/sec) backoff and pinstantreject never go to high -- Ich verwende die kostenlose Version von SPAMfighter für private Anwender, die bei mir bis jetzt 6002 Spammails entfernt hat. Rund 5,8 Millionen Leute nutzen SPAMfighter schon. Laden Sie SPAMfighter kostenlos herunter: http://www.spamfighter.com/lde _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
