There's excellent news from the Lab
about plans to eventually support embedded MP4s. This has been a
problem because many videos, notably including those hosted on Vimeo,
use this format that does not work with out-of-the-box Chromium
Embedded Framework, the basis of parcel and shared ("Media on a
Prim") media as well as viewer browsers. Although there's no
schedule yet, it's an encouraging development compared to a previous
statement in the Jira that the Lab did NOT plan to support the
format. (This may affect plans for hosting SL-related video content
and for displaying that content.)
On an unrelated topic, there have long
been devices that measure visitor scripts with the goal of
controlling the lag they might cause. In a recent forums thread (
https://community.secondlife.com/forums/topic/448580-avatar-script-count-limit-on-homestead/) some of us took a deeper dive into what such devices might do to be
useful, and what they very often do that is useless -- or worse. To
summarize:
Scripts worn by visitors can lag other
scripts but generally do not contribute to the most common forms of
lag experienced by avatars in a busy region. That's because scripts
are the lowest priority of sim processes, so a lot of avatars in a
region will tax *other* sim resources, squeezing out scripts (and
making script-on-script lag more severe). It can be annoying that
scripts don't get much time to run, but that's rarely best addressed
by reducing the script load itself.
That said, reducing the load of the
most over-scripted visitors can improve responsiveness of other
scripts (such as vendors), and griefers can take over-scripting to
such an extreme that it hurts overall sim performance.
To efficiently find script offenders,
what to measure? Turns out that the simplest metric -- count of
running scripts -- is probably the best option. That's because, as
detailed in the cited thread, both Script Memory and Script Time are
actually measuring something very different from what the names
imply. Script Time in particular is almost impossible to use
responsibly because the more a region is having performance problems,
the less accurately Script Time can be measured in the region and the
longer it takes (20 minutes or more) to settle into a potentially
useful metric.
Worse, the *direction* of inaccuracy is
also a function of time and sim load: when an avatar first arrives in
a busy region, their Script Time measure will be (hugely)
*over*-estimated compared to a less busy region, but later when the
measure stabilizes, the same scripts will show *lower* Script Times
than when the sim is less busy. Indeed an avatar's Script Time
depends less on their scripts than on the performance of the region
and the time since the avatar arrived.
Reporter Qie Niangao
200206
No comments:
Post a Comment