forked from I2P_Developers/i2p.i2p
bbf68cd9a8
if they would exceed the currently available # of tokens, letting through those operations in the order they are called. like the old trivial bandwidth limiter, this uses a token bucket approach (keeping a pool of 'available' bytes, decrementing on their use and periodically refilling it [up to a max limit, to prevent absurd bursts]). on the other hand, it doesn't have the starvation issues the old one had, which would continue to let small operations go through (e.g. 8 byte write) and potentially block large operations indefinitely (e.g. 32KB write). However, this new version is, how shall I put it, context switch heavy? :) We'll revise with a scheduling / queueing algorithm once we're away from transports that require threads per connection The two directions (input and output) are managed on their own queues, and if/when things are backed up, you can see the details of what operations have been requested on the router console. Since we still need better router throttling code (to reject tunnels and back off more accurately), I've included a minimum KBps on the limiter, currently set to 6KBps both ways. Once there is good throttling code, we can drop that to 1-2KBps, and maybe even less after we do some bandwidth usage tuning. There were also a few minor touch ups to handle message data being discarded earlier than it had been before (since write/read operations can now take a long period of time in the face of contention) The five config properties for the bandwidth limiter are: * i2np.bandwidth.inboundKBytesPerSecond * i2np.bandwidth.outboundKBytesPerSecond (you can guess what those are) * i2np.bandwidth.inboundBurstKBytes * i2np.bandwidth.outboundBurstKBytes the burst KBytes specify how many bytes we'll let accumulate in the bucket, allowing us to burst after a period of inactivity. excess tokens greater than this limit are discarded. * i2np.bandwidth.replenishFrequencyMs this is an internal setting, used to specify how frequently to refil the buckets (min value of 1s, which is the default) You may want to hold off on using these parameters though until the next release, leaving it to the default of unlimited. They are read periodically from the config file however, so you can update them without restart / etc. (if you want to have no limit on the bandwidth, set the KBytesPerSecond to a value <= 0)