[Feature Request] Queue-Like System. #493

New Issue

MrUnknownDE · 2026-04-05T19:16:09+02:00

MrUnknownDE commented

2026-04-05 19:16:09 +02:00

Originally created by @WuDoMiRa on 2/17/2025

I'd like for there to be an option/toggle called 'Queue' or something like that, which basically enables the usage of a queue-like-system.

Currently, residential people may face issues with using slimevr-firmware-flashed trackers (this inclues DiY, and vanilla/stock SVR trackers) due to possible congested channels, leading to non-smooth tracking experience, and spikes in the ping of individual/all trackers, this is present within the direct discord server of SlimeVR, and there has been many posts on this already.

My presented suggestion: A queue-like system, where instead of one tracker sending 96 KBS (96 KBS at rapid/constant movement, 8-16 KBS at near-idle) constantly (no end, no pause, sort of like DDOSing when there's multiple trackers), one tracker will only send the necessary data when given a signal from the server.

A proposed idea on how this could work:

Server sends a packet to the tracker, the tracker returns with data (location/rotation/battery/etc)
No other trackers send their data, until the server gives it the signal.

This may not stop a tracker alone from simply sending concurrent/mass requests, so this would also need to be implemented directly into the firmware of the tracker, SlimeVR/SlimeVR-Tracker-ESP.

Of course, there may be LAG, however this can be mitigated and/or fully nullified by leveraging existing filters like prediction. And if you use a third-party application to smooth the trackers, this should not be a big problem.

This suggestion and proposed solution may provide better smooth tracking for people in residential, and potential non-residential areas, so they won't need to buy a separate router, which may not even help.

I used Windows 11's hotspot for better performance with 11-point tracking. Just for reference with 11 point tracking, and 96 KBS of constant movement, this becomes around 1.056 MB/s a second of constant packets, resulting in non-smooth tracking, where I could only use a few of my trackers (like 4-5) and then tracking suddenly becomes smoother again.

If I connect the trackers to my router, I get even worse spikes, and I can get higher MS.

*Originally created by @WuDoMiRa on 2/17/2025* I'd like for there to be an option/toggle called 'Queue' or something like that, which basically enables the usage of a queue-like-system. Currently, residential people may face issues with using `slimevr-firmware-flashed` trackers (this inclues DiY, and vanilla/stock SVR trackers) due to possible congested channels, leading to non-smooth tracking experience, and spikes in the ping of individual/all trackers, this is present within the direct discord server of SlimeVR, and there has been many posts on this already. My presented suggestion: A queue-like system, where instead of one tracker sending 96 KBS (96 KBS at rapid/constant movement, 8-16 KBS at near-idle) constantly (no end, no pause, sort of like DDOSing when there's multiple trackers), one tracker will only send the necessary data when given a signal from the server. A proposed idea on how this could work: - Server sends a packet to the tracker, the tracker returns with data (location/rotation/battery/etc) No other trackers send their data, until the server gives it the signal. This may not stop a tracker alone from simply sending concurrent/mass requests, so this would also need to be implemented directly into the firmware of the tracker, [SlimeVR/SlimeVR-Tracker-ESP](https://github.com/SlimeVR/SlimeVR-Tracker-ESP). Of course, there may be LAG, however this can be mitigated and/or fully nullified by leveraging existing filters like prediction. And if you use a third-party application to smooth the trackers, this should not be a big problem. This suggestion and proposed solution may provide better smooth tracking for people in residential, and potential non-residential areas, so they won't need to buy a separate router, which may not even help. I used Windows 11's hotspot for better performance with 11-point tracking. Just for reference with 11 point tracking, and 96 KBS of constant movement, this becomes around 1.056 MB/s a second of constant packets, resulting in non-smooth tracking, where I could only use a few of my trackers (like 4-5) and then tracking suddenly becomes smoother again. If I connect the trackers to my router, I get even worse spikes, and I can get higher MS.

Sign in to join this conversation.

Branches Tags

main

sapphire/diy-fw-tool-version-sort

aed/grammar-police

battery-0

bscotch/server-rewrite-temp

hannah/steam

pontoon

hannah/keybinds

server-rewrite

bscotch/accel-mount

dependabot/github_actions/gradle/actions-6

dependabot/github_actions/pnpm/action-setup-5

dependabot/github_actions/actions/upload-artifact-7

dependabot/github_actions/actions/download-artifact-8

FloorClipSteamLinkInteractionFix

sapphire/trim-vrm-json

llelievr/trackers-udp-tests

sapphire/linux-bridge-kotlin

sapphire/linux-vrchat-compatdata-path

smol-sleep-state

sapphire/stay-aligned-setup-no-step-skip

sapphire/steamvr-hands-warning

sapphire/proportions-import-skeleton-request

sapphire/bone-mask-update

llelievr/settings-profiles

bscotch/proguard

bscotch/bvh-fix

mitten

bscotch/reset-proof-tests

hannah/install-from-server

smol-buttons

TheButlah-patch-1

sapphire/update-solarxr

sapphire/kotlin-flatbuffers

csv-data-export

feat_flashmode

bscotch/remove-drift-compensation

llelievr/kotlin-config

bscotch/fix-osc-duplication

llelievr/keep-battery-value

rest-calibration-support

tracker-graph

fingertracking

update-eslint

tauri-android

hide-new-resets

height-config

snap-serial

feat/new-updater

support-inches

vrc-fix-ik-key

llelievr/3dmodel-preview

accel-mapping-fixes

llelievr/manual-proportions-rework

llelievr/put-automatic-steamvr-tracker-assigment-first

llelievr/remove-manual-mounting-onboarding

onboarding-usage-step

oldflex

motion-compensation

kotlin-warnings-fix

accessories

tpose

foxvr

No Label Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Hardware Protocol Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Area: Server Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Priority: Low Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/SlimeVR-Server#493