i looked through some of TheFiend's posts on reddit:
Sensor's variable framerate is "independent" of the motion-sync implementation and does not need to be in multiples of 1000... The only thing affected is read timing i.e. which frame is being fetched and sent to the PC . The SPI clock and the PC's polling tick are sync'd to within 1% timing, so the frame data fetched from the sensor is always in sync with PC's polling ticks.
so here the claim is that motionsync is synchronization of SPI and the USB polling.
i don't understand the "hardware implementation" whatever from the previous post. this is something to do with timing of the firmware of the mouse mcu.
in any case, with my mouse running whatever test firmware it is running, "motionsync" whatever it is, is not synchonizing SPI and USB in wireless mode. it appears that the mouse is running it's own 1000Hz loop, which is not synchronized with the USB polls of the receiver, and hence the tolerances in crystal oscillators (some parts per million) lead to the drift as seen in the video.
The framerate of the mouse is already several times higher than the polling rate and it doesn't slow down. Just the "input frame selection" is optimized (by syncing it to the polling tick).
No smoothing all the way from 100-20000 dpi, variable frame rate, mad responsiveness thanks to motionsync which ensures that your mouse mcu and PC polling ticks are in-sync and the PC gets the latest frame before the tick, and not some arbitrary frame in the last millisecond (or averages).
see, this all makes sense if the SPI and USB are synchronized. in that case, you could make sure that every time you read from the sensor, you do so right before a USB poll arrives. this means that the input lag due to the gap between when you read from the sensor and when a usb poll arrives can be stable and minimized (to the time it takes for wireless signal to be transmitted and processed, plus a few tens of us of overhead). this is exactly what TheFiend means in these two posts.
but in wireless mode, as shown in my video, SPI and USB are not synchronized and there is some slow drift. given this, the best case scenario is that the input lag of this gap now fluctuates slowly between x and x + 1ms, where x is (the time it takes for wireless signal to be transmitted and processed plus a few tens of us of overhead).
tldr: if the goal of motionsync is to ensure that when a usb poll arrives, the most recent (or as much as possible) data from the sensor is what is transmitted, this is NOT currently done by the viper ultimate in wireless mode.
anyway, at least it seems they understand the importance of this synchronization so hopefully they will fix this in a firmware update.
and just for the record, this doesn't really matter in practice and logitech's wireless mice have the same issues. it's more about achieving exact parity with wired mice
edit: TheFiend mentioned in an email that motionsync is something done by the sensor. i cannot make any sense of this unless the 3399 is doing something quite different from other pixart sensors. so i'll wait for him to clarify
in any case, since data from the sensor has to go through the mouse mcu via SPI before reaching the receiver, my point about input lag fluctuating between x and 1+x still stands.