| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
does not consume avaiable space, so reducing bandwidth
|
| | |
|
| |
|
|
| |
changed terrain send throotle to be by packets in queue, reduced odds of MTU violation on terrain send (still bad). Most UDP protocol implementations may not mind much, but our code still does
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
int64, etc. Limite brust bytes to the total rate client requested times a
look ahead estimation time, Avoid queues starvation with updates waiting...
|
| | | |
|
| | |
| |
| |
| | |
acumulated ( variable named BurtRate, not exactly a rate...)
|
| | | |
|
| | |
| |
| |
| | |
region with a lot of contents. Should not affect much average rates.
|
| | |
| |
| |
| | |
category in specified time
|
| |\ \
| | |
| | |
| | | |
Merge in the new throttle code.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
rather
than drop exponentially to 0 (and then adjust up for the minimum flow), drop on
the delta between current rate and the minimum rate. This should smooth the fallback
to minimum.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
adaptive throttle by a full MTU. This is consistent with some implementations
of congestion control algorithms and certainly has the effect of opening
the throttle window more quickly after errors. This is especially important
after initial scene load when the number and size of packets is small.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
throttles. Setting adaptive_throttle_min_bps will change the
minimum rate that the adapative throttles will drop to in case
of network packet loss. The current rate default rate is 256kbps.
The viewer can throttle rates under that amount, but the dynamic
adaptation will not.
|
| |/ / |
|
| | |
| |
| |
| | |
Extends regression tests to test response of adaptive throttles to ack'ed and expired packets.
|
| | |
| |
| |
| |
| |
| |
| | |
client throttles properly.
In "show throttles", also renames 'total' column to 'actual' to reflect that it is not necessarily the throttles requested for/by the client.
Also fills out 'target' in non-adapative mode to the actual throttle requested for/by the client.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
throttles would cause client throttles to be lower than expected when total requests exceeded the scene limit.
This was because specifying a max client throttle would always request the max from the parent server throttle, no matter the actual total requests on the client throttle.
This would lead to a lower server multiplier than expected.
This change also adds a 'target' column to the "show throttles" output that shows the target rate (as set by client) if adaptive throttles is active.
This commit also re-adds the functionality lost in recent 5c1a1458 to set a max client throttle when adaptive is active.
This commit also adds TestClientThrottlePerClientAndRegionLimited and TestClientThrottleAdaptiveNoLimit regression tests
|
| | |
| |
| |
| | |
make code analysis easier. No functional change.
|
| | |
| |
| |
| |
| | |
This only had one child, which is the 'adaptive' token bucket.
So from testing and currently analysis, we can use that bucket directly which simplifies the code.
|
| | | |
|
| | |
| |
| |
| | |
Can currently only set adaptive true|false, where adaptive = false
|
| | |
| |
| |
| | |
<avatar-last-name>" to control extra throttle related debug logging.
|
| |/
|
|
| |
is being throttled due to past poor performance.
|
| | |
|
| |
|
