4 ms·
JS code or containerized code running on shared hardware are one thing. But crippling all userspace applications seems like going too far. Especially considerin
by the8472 9y ago
JS code or containerized code running on shared hardware are one thing. But crippling all userspace applications seems like going too far. Especially considering this is just papering over the problem instead of fixing it.
Also note that if you reduce precision you might still be able to tease out the data simply by gathering more samples. An exploit that gets you 1000bytes per minute might take an hour instead, but that could be enough to find cryptographic keys.
- r00fus 9y agoCan you tell me which apps would suffer because of timer coarsening?
- macawfish 9y agoSimulations, real time audio applications (filters, effects, etc.), real time anything for that matter, performance profilers... just of the top of my head.
- r00fus 9y agoat a granularity of 20µs?
- macawfish 9y agoWell, since 1/20µs = 50 kHz, it strikes me that this threshold was probably chosen with audio in mind. I agree that for a lot of cases, it's plenty. But if you're trying to account for phase differences in multiple data sources, this puts a major blindfold on. Let's think about it in terms of lower frequencies. Imagine that you're sampling from a pool of events that occur roughly 100 times/hour. Let's say you want to sample 2 event per hour. Well you might say "since you're only sampling at a rate of 2/hr, why would you need any better granularity than 30 minutes?" Here's the catch: you need to get the event that's closest to the 15 minute mark of each hour and the one that's closest to the 30 minute mark; you will then put those two together using your special formula. Imagine that all your events came into a mailbox on an half-hourly basis. Imagine a stack of ~100 envelopes, each labeled "8 - 8:30 A.M." or "8:30 - 9 A.M.". You're tasked tasked with the job of trying to pick the two closest to 8:15 A.M. and 8:30 A.M. Good luck! It's gonna be hard, if not impossible, to do this consistently with any accuracy. (Even if you had 15 minute granularity, you'd still have to pick from each one from either 25 or 50 envelopes, depending on where the windows fall relative to the 15 minute marks.) Now, to make matters even more complicated, imagine a situation where you're integrating each hour's result with the previous hours' result, e.g. taking a rolling sum or product, or computing some kind of feedback/delay/reverb filter. In cases like that, you're done for. Full disclosure, I'm coming at this from the perspective of an experimental digital artist who some day would like to do interesting creative things with high frequency sources, like the sounds of bugs, dolphins, and higher frequency ambient sounds. I'm also interested in building applications that crowd-source and integrate audio from multiple smart-phones in a room. The web seemed like a perfect platform for this.
- rphlx 9y ago> crippling all userspace applications seems like going too far. Depends on the system IMO. I certainly want the TSC when I'm profiling something highly-performance-sensitive on my workstation. Yet I am hard-pressed to see why any userspace app on my Mom's chromebook requires a ~1ns counter.. some stuff there may be currently using it, but that is different from "actually requires it"/"should continue to have it from an overall cost/benefit point of view".
- macawfish 9y agoSpeak for yourself, but I've been totally pumped about web audio for the last few years. This casts dark shadows across my dreams.
- rphlx 9y agoWell, web pages that have a legit need for higher res could request it in the same way that webcam or location access is requested today.
- gizmo686 9y agoExcept that a typical user understands the implications of giving camera or location access. I doubt most would understand the implication of giving clock access.