summaryrefslogtreecommitdiff
path: root/indra/newview/llviewerthrottle.cpp
diff options
context:
space:
mode:
authorAndrey Lihatskiy <118752495+marchcat@users.noreply.github.com>2026-08-13 20:18:46 +0300
committerGitHub <noreply@github.com>2026-08-13 20:18:46 +0300
commit039c1b4b027a5f34449a934d9aea0cea8a2c7659 (patch)
treef27a36ca21ab04d7e3ddb0c65ea39ee063252611 /indra/newview/llviewerthrottle.cpp
parentc8730531ee1a030c4e71f2b7ddb7d3394c9af7b7 (diff)
parentf376c52ee2a22b3b58263d86566394e80626fc1a (diff)
Merge pull request #6133 from secondlife/marchcat/lua-linux-develop
geenz/linux-to-develop to lua_editor
Diffstat (limited to 'indra/newview/llviewerthrottle.cpp')
-rw-r--r--indra/newview/llviewerthrottle.cpp23
1 files changed, 21 insertions, 2 deletions
diff --git a/indra/newview/llviewerthrottle.cpp b/indra/newview/llviewerthrottle.cpp
index 3ccfbea6e2..90a60c7a94 100644
--- a/indra/newview/llviewerthrottle.cpp
+++ b/indra/newview/llviewerthrottle.cpp
@@ -45,8 +45,8 @@ using namespace LLOldEvents;
const F32 MAX_FRACTIONAL = 1.5f;
const F32 MIN_FRACTIONAL = 0.2f;
-const F32 MIN_BANDWIDTH = 50.f;
-const F32 MAX_BANDWIDTH = 6000.f;
+const F32 MIN_BANDWIDTH = 50.f; // Kbps
+const F32 MAX_BANDWIDTH = 6000.f; // Kbps
const F32 STEP_FRACTIONAL = 0.1f;
const F32 HIGH_BUFFER_LOAD_TRESHOLD = 1.f;
const F32 LOW_BUFFER_LOAD_TRESHOLD = 0.8f;
@@ -244,6 +244,8 @@ void LLViewerThrottle::sendToSim() const
F32 LLViewerThrottle::getMaxBandwidthKbps()
{
+ // Why are thse different than the constants with the same names higher up?
+ // Anybody know? -- Leviathan
constexpr F32 MIN_BANDWIDTH = 100.0f; // 100 Kbps
constexpr F32 MAX_BANDWIDTH = 10000.0f; // 10 Mbps
@@ -309,6 +311,21 @@ void LLViewerThrottle::resetDynamicThrottle()
void LLViewerThrottle::updateDynamicThrottle()
{
+ // User configurable bandwidth settings are merely vague aspirations. Translating those
+ // to what should be sent to the servers is complicated. Servers will tend to spike data
+ // transmission upon arrival, packets will arrive faster than we can process them, and this
+ // can overflow the buffer, which causes packet loss.
+ //
+ // In an attempt to avoid catastrophe we periodically measure buffer load and packet loss
+ // and then transmit a modified desired bandwidth to the server. Unfortunately, this system
+ // does not work well for spikey data bursts because:
+ // (1) the response takes too long (up to 5 seconds) to kick in
+ // (2) once it starts it tends to ramp up too slowly
+ // (3) it doesn't know which region is providing the flood; it just assumes it is
+ // all from the main region
+ //
+ // TODO: fix those ^^^ problems
+
if (mUpdateTimer.getElapsedTimeF32() < DYNAMIC_UPDATE_DURATION)
{
return;
@@ -347,5 +364,7 @@ void LLViewerThrottle::updateDynamicThrottle()
LL_INFOS() << "Easing network throttle to " << mCurrentBandwidth << LL_ENDL;
}
+ // Now that we've used mBufferLoadRate we reset it to zero because otherwise it only
+ // increases (see clamping behavior in setBufferLoadRate()).
mBufferLoadRate = 0;
}