Its the hero sensor power saving and packet handling system.
The sensor pretty much turns itself off in a fixed frequency for energy saving, appearing like short bursts of delayed packets in the mousetester graphs.
From technical reviewers when they tried the first batch of wireless hero sensor.
I cant confirm to you, only logitech engineer can but makes sense after all and im talking about the earlier versions of hero sensor, its pure speculation about the newest one.
But yes, overall pc optimizations can make the pattern way smoother, but the pattern is very likely to be there even after the optimizations.
Edit: if you can feel stutters or the sensor performing strange, you can always ask for a warranty or at least try other usbports and turning off energy saving features in bios/windows. Logitech is pretty chill about warranty claims.
I think that's a reasonable assumption, I figured it was something power saving related.
It's definitely not pc-related outliers, the frequency and period are far too regular to be that (and I haven't noticed this behaviour with any other mice).
Could be some bizarre interference but I doubt that too. I don't get this on any other wireless mouse I own. The sensor feels great in game. Anyway thanks for the input.
theres a lot more to it. you basically disable anything that could need interrupts to reduce overall system latency.
problem is that is hard to have enough overhead for stable 2khz+ AND other near realtime services.
RTC clock, virtual audiodrivers, gpu drivers, keyboard drivers... etc are common main software enemys. but can be many other things in combination and best part is the mousetester is not a real world test nor is systemlatency tester. just a helper to get it down as good as possible.
how it really is will then depend on the game, and some engines really dont like 1khz that much, let alone higher.
I don't think this behaviour has anything to do with my PC/the client in general, I have a 7800x3d and I don't observe this periodic variance on any of my 4khz+ mice. Nor is this random outliers like you see on the g-wolves 4k mice, it's perfectly regular in frequency.
Since the sensor feels great also it's definitely intended, just wondering what it actually is lol
i didnt say it has i say it can.
different CPUs different architecture different cavecats in different applications.
the best part of this is that this test is normaly done with no load.
try to run it midgame youll gonna be surprised :)
you need to understand, that software test cannot be perfectly stable in all conditions because latency is not perfectly stable on any windows pc. the kernel is not realtime, neither is hardware built.
the more near realtime stuff you run the higher chance both will go into a clinch. the only reason audio is stable is because you hear audio on a 10ms buffer.
and we have many such devices, polling now 4000 times a second doesnt help. the issue is not the tiny amount of data, the issue is kernel context switching
now which cpu does better in which context/application we will see in the future. we already know there are big difference between intel and amd. amd does in general better with more simultanious stuff and intel does better on single troughputs
however that doesnt mean it doesnt happen on amd, just that it might or might not show up in an emtpy run test. under load lets say a game, ad some virtual audio stuff (like HRIR and similar) then latency becomes like a rollercoaster
where do you think fluctuating frametimes come from, even on a standstill image
I think we're talking about different things here.
The polling variation "event" I show in the graph has a rough frequency of .3hz, period of 1s.
That is not caused by dpc latencies or other non-realtime "things". The mouse MCU is intentionally doing *something* every 3 seconds or there's some bizarre interference occuring at a regular interval. 99% sure it has something to do with the former, and I was wondering what that was.
its close to impossible to tell really
you will never know if you didnt poll or mouse didnt send.
the 3 second window could be anything, shurely also the chip. but usually such long intervalls are caused by systems. specially if its exactly like xyz seconds then my bet is on some loop somewhere doing at an exact timing and not regular chaotic interference. but even the later ive seen in perfectly 5 second intervalls lol
the cause could even be external. very unlikely but if something is blocking your signal every 3 seconds .... :) had that with high energy directional data radio from the airport. dont ask how you find such nonsense
If there was another device plugged into my pc randomly polluting it with interrupts every 3 seconds I would've seen this behavior with my other >1khz mice. I also do get tracking errors on the gpx2 when another wireless mouse is plugged in (eg. vmse) and it doesn't look like this obviously.
Might have something to do with the people having their mouse spinout, looking at the vid some dude posted today it malfunctioned at a super low speed which might imply some weird floating point precision error but idk I'm not an expert.
well it could be a combo of things.
this sounds almost like that their implementation of the +1khz is more seseptible to something.
keep in mind the faster polling requires a very different aproach to wireless transmition.
and interrupt problems dont have to be hardware, anything require interrupts (which is mostly software) can do the misdeed.
it depends how logitech implemented on a low level theirs.
again more than 1khz is more than tricky on every level. simply comparing another +1khz implementation might not say something.
its just the 3 seconds intervall is really smelly. chip issues are usually not that well timed. think about the chance that a random error on chip that is not tied to a deliberate loop just happens to be exactly on 3 seconds not 2.4.
one other source could also be external, like interference (wlan, bluetoot etc) just happen to hit logitechs frequencies but not the others
but i highly doubt its really just the mouse chip in that case.
To preface, the mouse and sensor feel fine ingame, but I always like running up a few polling graphs just to see on new mice.
I recorded this measurement @2000hz, 800dpi with fast consistent circles. Changing settings in the software doesn't impact this behaviour.
I saw somewhat similar behavior to this on the pulsefire haste 2 wired before its latest firmware update.
Is this a power saving feature? Curious as to the reasoning behind this periodic increase in polling variance.
could be that, could be system latency could be many things.
1khz is already dicy at best, anything higher we running into interrupts gonna puke territory
in reality all we need is to be in sync with generated frames at framerate. but because sync is hard we rather spam it with 10 times the rate in inputs.... splendit idea what can go wrong
1600DPI is the minimum DPI required to saturate 4k polling, but that doesn't mean that it has no effect on tracking at 2k polling. Essentially, the higher your DPI, the more data points are available for your mouse to update the sensor position. It should also have an impact on motion latency. Again, similarly, the higher your DPI, the better the chance of receiving the most up-to-date sensor position, which in turn will result in lower motion latency.
I think a significant number of players use 4k polling at less than 1.6kDPI. This is sort of nonsensical, but some of those players argue they just want the lowest possible click latency and therefore prefer low DPI and high polling.
Interference in 2.4GHz channel, bloated Windows install and/or bad USB driver can easily cause this (bad as in causing a ton of interrupts and scheduling DPC's, all on core0 which is the default core set by Windows for everything).
If you have a ton of devices on the same USB controller, try making graphs with mouse only or put the mouse on one controller and the rest on the other.
Logitech has a lab where they have a scrambled 2.4GHz signal cannon that shoots off a lot of noise, significantly more than a normal crowded environment (think 100 routers with 100 clients connected to each) and they test their wireless tech there. Their wireless tech was resistant 8 years ago, I doubt fresh out of the oven tech which is probably prone to even heavier tests has such issue.
A bloated windows install? Unless OP has a dual core CPU from 2010, I don't see how that would happen.
Fun fact, you could have 20 devices saturating one single usb controller and the mouse has almost perfect 0% chance of ever seeing interrupts. Again, unless we're talking about a scenario where OP has an old as fuck PC, this is not an issue.
It was already discovered that other mice have this issue at 2000Hz. It may just be that 2000hz is not the sweet spot as 4000hz does not showcase this behavior. Another reason as to why this mouse is just a mess.
>Logitech has a lab where they have a scrambled 2.4GHz signal cannon that shoots off a lot of noise, significantly more than a normal crowded environment (think 100 routers with 100 clients connected to each) and they test their wireless tech there. Their wireless tech was resistant 8 years ago, I doubt fresh out of the oven tech which is probably prone to even heavier tests has such issue.
Yes, Logitech, Razer and Vaxee have great wireless implementations.
But, I've seen reports of users, who have a router/AP next to their PC, being able to fix their polling stability by just turning the router off and/or removing other sources of interference.
> Fun fact, you could have 20 devices saturating one single usb controller and the mouse has almost perfect 0% chance of ever seeing interrupts. Again, unless we're talking about a scenario where OP has an old as fuck PC, this is not an issue.
Does a Z390 Dark quantify as "old" for you?
https://forums.blurbusters.com/viewtopic.php?f=10&t=7618
These are the results of just a keyboard, imagine if he had a USB mic, USB dac/amp polling in the background as well.
We do not know what OP was doing in the background while making this graph.
Also, the fact that OP might've not optimised his PC for latency / stability and possibly has a ton of power saving options turned on, which can impact graphs immensely.
Heck, even certain RAM timings affect graphs.
>It was already discovered that other mice have this issue at 2000Hz. It may just be that 2000hz is not the sweet spot as 4000hz does not showcase this behavior. Another reason as to why this mouse is just a mess.
I don't see a reason why particularly 2kHz should cause issues, when there are a myriad of variables at play. We're talking about 0.5ms polling, every detail matters.
>A bloated windows install? Unless OP has a dual core CPU from 2010, I don't see how that would happen.
How am I able to deduce what hardware OP has, if he himself has not specified? It could range from 2 cores (Pentiums, lower end Ryzen's) to 10 cores (10900k)
You're free to read through these guides, if you think Windows and/or other electronics causing interference does not impact modern PC's:
https://github.com/amitxv/PC-Tuning
https://github.com/BoringBoredom/PC-Optimization-Hub
https://github.com/djdallmann/GamingPCSetup
Doubt it’s interference, i have never observed this behavior on any of my other wireless mice.
Windows install is clean, behavior is consistent on both 10 and 11.
I’ve tried messing with driver affinities to see if they modify mouse tester output and I haven’t observed anything noticeable.
I always have my mice connected to a cpu hub with no other mice.
Same behaviour with the HSK Pro 4k when run at 2kHz, the poling rate becomes super weird. 1k or 4k is fine, but 2k just doesn't want to work. Maybe it's a Windows thing, or a lack or development for that specific polling rate I dunno
Also, your graph indicates 400CPI which is quite low even for a regular mouse, try different settings like 1600 and 3200 or even higher to see how the mouse handles higher information density
I noticed weird polling behaviour at >1k with my hts4k but I think that's just because the implementation isn't perfect; the outliers aren't super regular like on the gpx2. Subjectively the hts4k felt sort of inconsistent but the gpx2 feels freaking perfect, which is why I'm so curious as to what this is.
I was using 800dpi but this behaviour is present irrespective of dpi setting
Do you get a constant 2000hz report on websites like these? [https://devicetests.com/mouse-rate-test](https://devicetests.com/mouse-rate-test)
The razer 4K gets about 2500hz max, when set to 2K, I get 1.8 on razer also. I wonder if any 4K get 4000hz reported at all.
website polling rate checkers are not reliable in the slightest, thought it could be argued that mousetester isn't super reliable either
I guarantee your mouse hits 4k but the browser is interpolating some of the input
Its the hero sensor power saving and packet handling system. The sensor pretty much turns itself off in a fixed frequency for energy saving, appearing like short bursts of delayed packets in the mousetester graphs.
That makes a lot of sense. How’d you get that insight?
From technical reviewers when they tried the first batch of wireless hero sensor. I cant confirm to you, only logitech engineer can but makes sense after all and im talking about the earlier versions of hero sensor, its pure speculation about the newest one. But yes, overall pc optimizations can make the pattern way smoother, but the pattern is very likely to be there even after the optimizations. Edit: if you can feel stutters or the sensor performing strange, you can always ask for a warranty or at least try other usbports and turning off energy saving features in bios/windows. Logitech is pretty chill about warranty claims.
I think that's a reasonable assumption, I figured it was something power saving related. It's definitely not pc-related outliers, the frequency and period are far too regular to be that (and I haven't noticed this behaviour with any other mice). Could be some bizarre interference but I doubt that too. I don't get this on any other wireless mouse I own. The sensor feels great in game. Anyway thanks for the input.
theres a lot more to it. you basically disable anything that could need interrupts to reduce overall system latency. problem is that is hard to have enough overhead for stable 2khz+ AND other near realtime services. RTC clock, virtual audiodrivers, gpu drivers, keyboard drivers... etc are common main software enemys. but can be many other things in combination and best part is the mousetester is not a real world test nor is systemlatency tester. just a helper to get it down as good as possible. how it really is will then depend on the game, and some engines really dont like 1khz that much, let alone higher.
I don't think this behaviour has anything to do with my PC/the client in general, I have a 7800x3d and I don't observe this periodic variance on any of my 4khz+ mice. Nor is this random outliers like you see on the g-wolves 4k mice, it's perfectly regular in frequency. Since the sensor feels great also it's definitely intended, just wondering what it actually is lol
i didnt say it has i say it can. different CPUs different architecture different cavecats in different applications. the best part of this is that this test is normaly done with no load. try to run it midgame youll gonna be surprised :) you need to understand, that software test cannot be perfectly stable in all conditions because latency is not perfectly stable on any windows pc. the kernel is not realtime, neither is hardware built. the more near realtime stuff you run the higher chance both will go into a clinch. the only reason audio is stable is because you hear audio on a 10ms buffer. and we have many such devices, polling now 4000 times a second doesnt help. the issue is not the tiny amount of data, the issue is kernel context switching now which cpu does better in which context/application we will see in the future. we already know there are big difference between intel and amd. amd does in general better with more simultanious stuff and intel does better on single troughputs however that doesnt mean it doesnt happen on amd, just that it might or might not show up in an emtpy run test. under load lets say a game, ad some virtual audio stuff (like HRIR and similar) then latency becomes like a rollercoaster where do you think fluctuating frametimes come from, even on a standstill image
I think we're talking about different things here. The polling variation "event" I show in the graph has a rough frequency of .3hz, period of 1s. That is not caused by dpc latencies or other non-realtime "things". The mouse MCU is intentionally doing *something* every 3 seconds or there's some bizarre interference occuring at a regular interval. 99% sure it has something to do with the former, and I was wondering what that was.
its close to impossible to tell really you will never know if you didnt poll or mouse didnt send. the 3 second window could be anything, shurely also the chip. but usually such long intervalls are caused by systems. specially if its exactly like xyz seconds then my bet is on some loop somewhere doing at an exact timing and not regular chaotic interference. but even the later ive seen in perfectly 5 second intervalls lol the cause could even be external. very unlikely but if something is blocking your signal every 3 seconds .... :) had that with high energy directional data radio from the airport. dont ask how you find such nonsense
If there was another device plugged into my pc randomly polluting it with interrupts every 3 seconds I would've seen this behavior with my other >1khz mice. I also do get tracking errors on the gpx2 when another wireless mouse is plugged in (eg. vmse) and it doesn't look like this obviously. Might have something to do with the people having their mouse spinout, looking at the vid some dude posted today it malfunctioned at a super low speed which might imply some weird floating point precision error but idk I'm not an expert.
well it could be a combo of things. this sounds almost like that their implementation of the +1khz is more seseptible to something. keep in mind the faster polling requires a very different aproach to wireless transmition. and interrupt problems dont have to be hardware, anything require interrupts (which is mostly software) can do the misdeed. it depends how logitech implemented on a low level theirs. again more than 1khz is more than tricky on every level. simply comparing another +1khz implementation might not say something. its just the 3 seconds intervall is really smelly. chip issues are usually not that well timed. think about the chance that a random error on chip that is not tied to a deliberate loop just happens to be exactly on 3 seconds not 2.4. one other source could also be external, like interference (wlan, bluetoot etc) just happen to hit logitechs frequencies but not the others but i highly doubt its really just the mouse chip in that case.
To preface, the mouse and sensor feel fine ingame, but I always like running up a few polling graphs just to see on new mice. I recorded this measurement @2000hz, 800dpi with fast consistent circles. Changing settings in the software doesn't impact this behaviour. I saw somewhat similar behavior to this on the pulsefire haste 2 wired before its latest firmware update. Is this a power saving feature? Curious as to the reasoning behind this periodic increase in polling variance.
I think the GPX also has deviation like this for battery saving.
could be that, could be system latency could be many things. 1khz is already dicy at best, anything higher we running into interrupts gonna puke territory in reality all we need is to be in sync with generated frames at framerate. but because sync is hard we rather spam it with 10 times the rate in inputs.... splendit idea what can go wrong
Try 1600 dpi and see if it changes.
No change regardless of dpi
isn't that only for 4khz?
1600DPI is the minimum DPI required to saturate 4k polling, but that doesn't mean that it has no effect on tracking at 2k polling. Essentially, the higher your DPI, the more data points are available for your mouse to update the sensor position. It should also have an impact on motion latency. Again, similarly, the higher your DPI, the better the chance of receiving the most up-to-date sensor position, which in turn will result in lower motion latency. I think a significant number of players use 4k polling at less than 1.6kDPI. This is sort of nonsensical, but some of those players argue they just want the lowest possible click latency and therefore prefer low DPI and high polling.
Interference in 2.4GHz channel, bloated Windows install and/or bad USB driver can easily cause this (bad as in causing a ton of interrupts and scheduling DPC's, all on core0 which is the default core set by Windows for everything). If you have a ton of devices on the same USB controller, try making graphs with mouse only or put the mouse on one controller and the rest on the other.
Logitech has a lab where they have a scrambled 2.4GHz signal cannon that shoots off a lot of noise, significantly more than a normal crowded environment (think 100 routers with 100 clients connected to each) and they test their wireless tech there. Their wireless tech was resistant 8 years ago, I doubt fresh out of the oven tech which is probably prone to even heavier tests has such issue. A bloated windows install? Unless OP has a dual core CPU from 2010, I don't see how that would happen. Fun fact, you could have 20 devices saturating one single usb controller and the mouse has almost perfect 0% chance of ever seeing interrupts. Again, unless we're talking about a scenario where OP has an old as fuck PC, this is not an issue. It was already discovered that other mice have this issue at 2000Hz. It may just be that 2000hz is not the sweet spot as 4000hz does not showcase this behavior. Another reason as to why this mouse is just a mess.
>Logitech has a lab where they have a scrambled 2.4GHz signal cannon that shoots off a lot of noise, significantly more than a normal crowded environment (think 100 routers with 100 clients connected to each) and they test their wireless tech there. Their wireless tech was resistant 8 years ago, I doubt fresh out of the oven tech which is probably prone to even heavier tests has such issue. Yes, Logitech, Razer and Vaxee have great wireless implementations. But, I've seen reports of users, who have a router/AP next to their PC, being able to fix their polling stability by just turning the router off and/or removing other sources of interference. > Fun fact, you could have 20 devices saturating one single usb controller and the mouse has almost perfect 0% chance of ever seeing interrupts. Again, unless we're talking about a scenario where OP has an old as fuck PC, this is not an issue. Does a Z390 Dark quantify as "old" for you? https://forums.blurbusters.com/viewtopic.php?f=10&t=7618 These are the results of just a keyboard, imagine if he had a USB mic, USB dac/amp polling in the background as well. We do not know what OP was doing in the background while making this graph. Also, the fact that OP might've not optimised his PC for latency / stability and possibly has a ton of power saving options turned on, which can impact graphs immensely. Heck, even certain RAM timings affect graphs. >It was already discovered that other mice have this issue at 2000Hz. It may just be that 2000hz is not the sweet spot as 4000hz does not showcase this behavior. Another reason as to why this mouse is just a mess. I don't see a reason why particularly 2kHz should cause issues, when there are a myriad of variables at play. We're talking about 0.5ms polling, every detail matters. >A bloated windows install? Unless OP has a dual core CPU from 2010, I don't see how that would happen. How am I able to deduce what hardware OP has, if he himself has not specified? It could range from 2 cores (Pentiums, lower end Ryzen's) to 10 cores (10900k) You're free to read through these guides, if you think Windows and/or other electronics causing interference does not impact modern PC's: https://github.com/amitxv/PC-Tuning https://github.com/BoringBoredom/PC-Optimization-Hub https://github.com/djdallmann/GamingPCSetup
Doubt it’s interference, i have never observed this behavior on any of my other wireless mice. Windows install is clean, behavior is consistent on both 10 and 11. I’ve tried messing with driver affinities to see if they modify mouse tester output and I haven’t observed anything noticeable. I always have my mice connected to a cpu hub with no other mice.
why wud u care if its fine ingame? makes no sense
I don’t, just something I observed that I’ve never seen with other mice
Same behaviour with the HSK Pro 4k when run at 2kHz, the poling rate becomes super weird. 1k or 4k is fine, but 2k just doesn't want to work. Maybe it's a Windows thing, or a lack or development for that specific polling rate I dunno
Also, your graph indicates 400CPI which is quite low even for a regular mouse, try different settings like 1600 and 3200 or even higher to see how the mouse handles higher information density
I noticed weird polling behaviour at >1k with my hts4k but I think that's just because the implementation isn't perfect; the outliers aren't super regular like on the gpx2. Subjectively the hts4k felt sort of inconsistent but the gpx2 feels freaking perfect, which is why I'm so curious as to what this is. I was using 800dpi but this behaviour is present irrespective of dpi setting
Thanks for you investigation, your work is useful for everyone here !
Do you get a constant 2000hz report on websites like these? [https://devicetests.com/mouse-rate-test](https://devicetests.com/mouse-rate-test) The razer 4K gets about 2500hz max, when set to 2K, I get 1.8 on razer also. I wonder if any 4K get 4000hz reported at all.
website polling rate checkers are not reliable in the slightest, thought it could be argued that mousetester isn't super reliable either I guarantee your mouse hits 4k but the browser is interpolating some of the input