feat(ranking): bidirectional int64_t seq so past-active tracks rank above never-active#201
feat(ranking): bidirectional int64_t seq so past-active tracks rank above never-active#201
Conversation
…bove never-active When two tracks tie on a synthetic property value, a participant who was recently active and went quiet should rank above one that joined and never contributed. Early session join should not grant priority over an established contributor at the same level. Two counters manage arrivalSeq (int64_t): - nextSeqUp_ (non-negative, incrementing): stamped on registration and every value increase. Whoever rose to a given value first holds the lowest Up seq and wins ties — prior registration order is irrelevant. - nextSeqDown_ (negative, decrementing): stamped on every value decrease. Negative seqs always sort below non-negative ones, so any track that has decreased to a value outranks tracks that registered at or rose to that value. Rising again clears the negative history by stamping a fresh Up seq. Known trade-off: a track that decreased to a value beats any track that later rose to the same value even if the riser arrived more recently. Acceptable because the property is a synthetic application metric, so exact-value ties at active levels are rare in practice. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
afrind
requested review from
Oxyd,
TimEvens,
akash-a-n,
gmarzot,
michalhosna,
mondain,
peterchave and
suhasHere
as code owners
TimEvens
left a comment
TimEvens
left a comment
There was a problem hiding this comment.
Rise: fresh nextSeqUp_++ so whoever reached this level first keeps priority
// (early registration no longer displaces an established talker).
Stepping up with negative numbers will lead to those always being preferred over new/recently added tracks to the same value, which are technically more current and likely should have been selected first.
We can punt this to the app to solve by ensuring that the metric observed is correctly decreased when it should not be selected. If the app does not do it right, it will result in tracks getting stuck as selected just because it decreased a value. The other tracks that are active are positive (new, never decreased) and therefore may never be selected when there is a decreased/negative track in the list.
| // (early registration no longer displaces an established talker). | ||
| // Fall: nextSeqDown_-- (negative) so past-active tracks rank above | ||
| // never-active or just-rising tracks (non-negative) at the same value. | ||
| int64_t newSeq = (value > oldKey.value) ? nextSeqUp_++ : nextSeqDown_--; |
There was a problem hiding this comment.
This looks good for stepping down, but it seems that stepping up will suffer from previous negative (e.g., stepped down) values being preferred over the recently stepped up value.
There was a problem hiding this comment.
Yes, I don't really know what the "right" behavior is, and to some degree I rationalized it by saying that the relay can make the rules and the application can adapt.
So for a given level, you would see:
Most recently fallen to this level | Most recently started/rose to this level
<--- Higher Pri Lower Pri --->
So your best move to be seen is to scream and then start talking in a normal voice. You will beat the normal people who just talk normally all the time.
afrind
left a comment
afrind
left a comment
There was a problem hiding this comment.
The MOQT PR explicitly says that arrival time is the tiebreaker with earliest preferred, hence using positive seq for new arrivers at a given level.
@afrind made 2 comments.
Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on akash-a-n, gmarzot, michalhosna, mondain, Oxyd, peterchave, suhasHere, and TimEvens).
| // (early registration no longer displaces an established talker). | ||
| // Fall: nextSeqDown_-- (negative) so past-active tracks rank above | ||
| // never-active or just-rising tracks (non-negative) at the same value. | ||
| int64_t newSeq = (value > oldKey.value) ? nextSeqUp_++ : nextSeqDown_--; |
There was a problem hiding this comment.
Yes, I don't really know what the "right" behavior is, and to some degree I rationalized it by saying that the relay can make the rules and the application can adapt.
So for a given level, you would see:
Most recently fallen to this level | Most recently started/rose to this level
<--- Higher Pri Lower Pri --->
So your best move to be seen is to scream and then start talking in a normal voice. You will beat the normal people who just talk normally all the time.
mondain
left a comment
mondain
left a comment
There was a problem hiding this comment.
@mondain reviewed 4 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on akash-a-n, gmarzot, michalhosna, Oxyd, peterchave, suhasHere, and TimEvens).
|
I spoke offline to @suhasHere who seemed to think this was not correct. Handing off to him to make the close/merge decsision here. |
4 participants
When two tracks tie on a synthetic property value, a participant who was recently active and went quiet should rank above one that joined and never contributed. Early session join should not grant priority over an established contributor at the same level.
Two counters manage arrivalSeq (int64_t):
Known trade-off: a track that decreased to a value beats any track that later rose to the same value even if the riser arrived more recently. Acceptable because the property is a synthetic application metric, so exact-value ties at active levels are rare in practice.
This change is