
| Key: |
SVC-3344
|
| Type: |
New Feature
|
| Status: |
Reopened
|
| Priority: |
Normal
|
| Assignee: |
Unassigned
|
| Reporter: |
Vex Streeter
|
| Votes: |
8
|
| Watchers: |
2
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Duplicate
|
|
|
|
This issue is original of duplicate:
|
|
SVC-3346
Put offending OS sims on servers together
|
|
|
|
|
Relates
|
|
This issue Relates to:
|
|
|
SVC-3335 OpenSpace Technical Limitations MetaIssue
|
|
|
|
|
|
MISC-1776 OpenSpace Sim Prices SHOULD NOT Be Going Up! VOTE To Stop This ridiculous increase!
|
|
|
|
|
|
|
|
Background:
- Open Space/Void/Quad sims compete directly for CPU resources with 3 others, leading to issues where over-use of one causes significant problems on the other co-resident sims.
- The recently announced Open Space SIM repricing is reacting to the over-use ("abuse") of OS Sims by upping the price to match the aggregate average use.
- IMHO, this will have exactly the opposite of the intended effect, driving out those who do not require high resource use and retaining the abusers. The latter group will still see Open Spaces as a bargain, and the former were using such sims in the way intended - a relatively inexpensive way to have light-use decorative sims requiring full space but few resources. Even those light users who pay the additional tier will be dissatisfied as their low resource sims will be sharing a cpu with (more than likely) 3 high-use sims.
Rather than attempting to fix the real problem with a repricing approach, I propose to solve the underlying problem using basic load-balancing algorithms in reverse:
1. Meter all OS Sims for a load factor, which is a combination of measured avatar traffic, script load, physical object count (or maybe just colliders?), and prim load (maybe only temprezzed?).
2. Compute a longer time load factor determined statistically. I'd suggest something like a max load for the previous 10 days.
3. keep database of sim and current average load.
4. on sim reboot, choose target based on minimum delta between "my" load factor and the average of other sims on the target.
5. force migration if the disparity of load factors grows too large (this would be per machine or per-cpu to avoid chaotic migration).
6. increase visibility of load factors, in viewer and LSL. Also make it possible for the viewer to see the names and load factors of co-resident OS sims. (optional, but helps people understand why they are migrating)
This sounds pretty straightforward and can be rolled out in phases. It will take some time to determine the correct factor values.
This puts everyone in control of their own destiny: Everyone rises (or sinks) to their level of resource use, and tolerates (or not) living with their peers.
- Too much lag? reduce your own resource use and you'll get migrated down.
- Want to open a round-the-clock club on an OS sim, go for it! but be you'll be sharing the CPU with 3 other clubs.
Note that this proposal very clearly changes the definition of "open space" sim somewhat. One could easily imagine sims at the top levels choosing to upgrade to a "half sim" and the ones at the bottom downgrading to an "eighth sim", rather like tier on mainland.
|
|
Description
|
Background:
- Open Space/Void/Quad sims compete directly for CPU resources with 3 others, leading to issues where over-use of one causes significant problems on the other co-resident sims.
- The recently announced Open Space SIM repricing is reacting to the over-use ("abuse") of OS Sims by upping the price to match the aggregate average use.
- IMHO, this will have exactly the opposite of the intended effect, driving out those who do not require high resource use and retaining the abusers. The latter group will still see Open Spaces as a bargain, and the former were using such sims in the way intended - a relatively inexpensive way to have light-use decorative sims requiring full space but few resources. Even those light users who pay the additional tier will be dissatisfied as their low resource sims will be sharing a cpu with (more than likely) 3 high-use sims.
Rather than attempting to fix the real problem with a repricing approach, I propose to solve the underlying problem using basic load-balancing algorithms in reverse:
1. Meter all OS Sims for a load factor, which is a combination of measured avatar traffic, script load, physical object count (or maybe just colliders?), and prim load (maybe only temprezzed?).
2. Compute a longer time load factor determined statistically. I'd suggest something like a max load for the previous 10 days.
3. keep database of sim and current average load.
4. on sim reboot, choose target based on minimum delta between "my" load factor and the average of other sims on the target.
5. force migration if the disparity of load factors grows too large (this would be per machine or per-cpu to avoid chaotic migration).
6. increase visibility of load factors, in viewer and LSL. Also make it possible for the viewer to see the names and load factors of co-resident OS sims. (optional, but helps people understand why they are migrating)
This sounds pretty straightforward and can be rolled out in phases. It will take some time to determine the correct factor values.
This puts everyone in control of their own destiny: Everyone rises (or sinks) to their level of resource use, and tolerates (or not) living with their peers.
- Too much lag? reduce your own resource use and you'll get migrated down.
- Want to open a round-the-clock club on an OS sim, go for it! but be you'll be sharing the CPU with 3 other clubs.
Note that this proposal very clearly changes the definition of "open space" sim somewhat. One could easily imagine sims at the top levels choosing to upgrade to a "half sim" and the ones at the bottom downgrading to an "eighth sim", rather like tier on mainland. |
Show » |
|
(when i proposed the idea, someone else already had it earlier, but well hidden away (meaning, not directly linked from MISC-1776))