On Thursday 15 January 2009 23:35, [email protected] wrote:
> 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.

Output bandwidth liability limiting (the main factor on most nodes in 
determining which requests to accept) already tries to take overhead into 
account. So I don't see what the difference is.
> 
> 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.

Maybe ... at a cost in throughput. As I mentioned, the upload limit is the 
scarce resource here. Usually the average upload usage is slightly over the 
average download because of locally satisfied requests.
> 
> 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 

Attachment: pgpSv474Zse0W.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to