I know all of the wrist watches experience this issue, but this was extreme like drop from 145->80 for like 60+ min then rapidly shopt back up. Not like a small couple min blip.
This was a near the top end model at the time, and after complaining Garmin support owned up that this was a firmware bug impact all sensors of that generation and it would take 2+ months to fix (took like 5).
But they did send me a HRM for free and I've been using that. So I am grateful that and using it since. But for short rides (like 90 min or less) I don't always remember to think to bring the HRM.
Prior to that I had two lower end Garmin watches, and despite having theoretically lower end HR sensors they did not experience such bugs or drop outs (an unexpected blip every once in a while).
But I think the main point still stands, their software/firmware/UX has not moved in relation with the hardware. Next time I'm in the market I will be consider all the options. Feels like Coros and others have come a long way.
Prob the biggest thing keeping me in their ecosystem is multi sport (variations of bike riding types -- I do all), hiking, strength training, erg, winter sports. But even there the list of strength exercises has not been updated in like a decade.
I have a Garmin "smart" watch (with every app notification etc disabled) and I love the fact that I can do almost two weeks of exercises (ride, walk, gym) without needing to charge it. The bike computers are also solid. But sadly the UX of the software on these leaves a bunch to be desired, and I've been bitten by many software and firmware bugs in the last years... Including months for which HRM would randomly and persistently drop it's value from say whatever the real value (say 145 for argument sake) to 80.
Please re-read my above comment. There is no new API. The DAX userspace API is mmap.
This work is experimental but you can mmap a single file on a filesystem on this device using new DAX capabilities. Most access will not longer require a syscall.
This comes with all the usual semantics and trappings of mmap plus some additional caveats as to how the filesystem / DAX / hardware is implemented. Most reads/writes will not require a trip to the kernel using the normal read()/write() syscalls. Additionally, there is no RAM page cache baking this mmap instead the device is mapped directly at a virtual address (like DMA).
LWN.net has lots of articles and links in their archives from 2016/2017. It's a really good read. Sadly I do not have time to dig more of them up for you. Do a search for site:lwn.net and search for DAX or MAP_DIRECT.
The claim is that it's 2% to 5% in most general uses on systems that have PCID support. If that's the case then I'm willing to bet that databases on fast flash storage are lot more impacted then this and pure CPU bound tasks (such as encoding video) are less impacted.
The reality is that OLTP databases execution time is not dominated by CPU computation but instead of IO time. Most transactions in OLTP systems fetch a handful of tuples. Most time is dedicated to fetching the tuples (and maybe indices) from disk and then sending them over network.
New disk devices lowered the latency significantly while syscall time has barely gotten better.
So in OLTP databases I expect the impact to be closer to 10% to 15%. So up to 3x over the base case.
If you bypass the page cache you do not have read()/write() and mmap you avoid the syscall overhead. This matters a lot for high IOPs devices. Also these new fangled devices claim support word cache line sync using normal cpu flush instructions. Also avoiding fsync syscall.
I think the model for cloud vendors would be quite complicated. Not every version of the CPU and not every application is impacted as much (new intel processors with PCID will suffer less).
Add on top of that the fact that a lot cloud customers over provision (there's good scientific papers on how much spare CPU capacity there is). Cloud service providers that sell things on a per request / real CPU usage model (vs reserved capacity) prob benefit more.
Also, you can't just separate trading in AWS or GCE from the rest of the core business.
Potentially business units of DELL, HP, IBM, ... should do better as people use this as a justification to upgrade overdue hardware they should cover 5% to 10% lower performance (needing more units to cover that).
In the future this possible on Linux with the filesystems that support DAX. Currently this all pretty experimental with lots of work being done in this space in the last two years.
But this will require you to have the right kind of flash storage, right kind of fs, right kind mount options, and probably a different code path in userspace for DAX vs traditional storage.
As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO.
And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
This whole sub-thread tangent-ed into C++ is bad because it's compilation causes this problem. Problems with C++ builds are well understood...
This specific issue prob impact other batch workloads with lots of small tasks (processes). There's no reason this should be happening on a 24 core machine.
This was a near the top end model at the time, and after complaining Garmin support owned up that this was a firmware bug impact all sensors of that generation and it would take 2+ months to fix (took like 5).
But they did send me a HRM for free and I've been using that. So I am grateful that and using it since. But for short rides (like 90 min or less) I don't always remember to think to bring the HRM.
Prior to that I had two lower end Garmin watches, and despite having theoretically lower end HR sensors they did not experience such bugs or drop outs (an unexpected blip every once in a while).
But I think the main point still stands, their software/firmware/UX has not moved in relation with the hardware. Next time I'm in the market I will be consider all the options. Feels like Coros and others have come a long way.
Prob the biggest thing keeping me in their ecosystem is multi sport (variations of bike riding types -- I do all), hiking, strength training, erg, winter sports. But even there the list of strength exercises has not been updated in like a decade.