Closed Bug 1403817 Opened 7 years ago Closed 7 years ago

Split out cache stats by whether user has SSD or not

Categories

(Core :: Networking: Cache, enhancement, P2)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jduell.mcbugs, Assigned: michal)

References

Details

(Whiteboard: [necko-triaged])

It looks like there's a way to detect if we're on an SSD (at least on windows and IIRC Linux--haven't checked for OSX): https://msdn.microsoft.com/en-gb/library/windows/desktop/aa364939(v=vs.85).aspx Let's break out our RCWN and other interesting cache stats by SSD/legacy hard drive type. Other people may be interested in breaking their telemetry down by SSD/legacy, so it'd be nice to add a standard way to check for SSD as part of this bug.
Here's what Microsoft's Disk Defragmenter program allegedly does: https://stackoverflow.com/questions/13726522/what-is-the-easiest-way-in-c-sharp-to-check-if-hard-disk-is-ssd-without-writing Not sure what to do with hybrid disks (spinning disks with a RAM-based cache). Maybe it'll be enough to split out just pure SSDs vs everything else? We're really just looking to see if 1) the long tail for cache response times happens on SSDs, and maybe 2) if there's any differences in RCWN performance that might result in us wanting to tweak our racing algorithms when we're on SSD. And 3) anything else interesting in cache perf on SSDs--we've never focused on it before, so worth a look with fresh eyes.
Priority: -- → P2
Whiteboard: [necko-triaged]
This difference is going to be very interesting to Product in order to better understand what the performance limitations are for most users. Intuitively we think that users experience much better perceived performance on a slower system with SSDs than a faster system with spinning disks. We need to have a much better idea of things like: * how many users have one vs the other * using this new understanding as a guide, what performance characteristics of Firefox are common in each group I'd really like to see this in Q4, if possible.
Flags: needinfo?(jduell.mcbugs)
Yes, we're planning to do this in Q4 if possible.
Flags: needinfo?(jduell.mcbugs)
This would be great to have as a component of our understanding for when we'd like to update our reference hardware, as well as tying back to many perf related concerns. Hopefully still on track for Q4!
Jason, this is late. What is the current status?
Flags: needinfo?(jduell.mcbugs)
Sorry for the delay. Michal, can you post some notes here on the differing APIs you've been looking into? Honza is going to help on Windows here as well.
Flags: needinfo?(jduell.mcbugs) → needinfo?(michal.novotny)
On Windows, we can check if trim command is available for the drive. Example code is here https://stackoverflow.com/questions/5814371/get-rotation-speed-of-disk-sample-code On Linux, we can read /sys/dev/block/.../queue/discard_max_bytes which should be non-null in case trim is available. Other possibility is to read /sys/dev/block/.../queue/rotational On Mac, I don't know.
Flags: needinfo?(michal.novotny)
(In reply to Michal Novotny (:michal) from comment #7) > On Windows, we can check if trim command is available for the drive. Example > code is here > https://stackoverflow.com/questions/5814371/get-rotation-speed-of-disk- > sample-code Other possibility on Windows is to check MediaType in MSFT_PhysicalDisk, https://msdn.microsoft.com/en-us/library/windows/desktop/hh830532(v=vs.85)
(In reply to Michal Novotny (:michal) from comment #7) > On Windows, we can check if trim command is available for the drive. Example > code is here > https://stackoverflow.com/questions/5814371/get-rotation-speed-of-disk- > sample-code > > On Linux, we can read /sys/dev/block/.../queue/discard_max_bytes which > should be non-null in case trim is available. Other possibility is to read > /sys/dev/block/.../queue/rotational > > On Mac, I don't know. Windows is definitely the priority here.
Instead of just pinging on this bug to ask for status, thought I'd fill in why I think this is important and what my plans are for it. Post-multi what we're seeing is a lot of people who are very happy with Firefox performance and some people with really terrible performance. Anecdotally the people we're seeing with bad performance are people that have older systems[1] or very under-powered systems. I'm very interested in collecting the right data from our user's systems to do some analysis and be able to identify older / slower systems and adjust their e10s configuration to suit. Understanding system performance based on telemetry measures is tricky, we get some cpu information around cores and threads, chipset information, GPUs, etc. We also know intuitively that hard drive *type* hugely impacts performance, when we identified the reference hardware we used to test Quantum progress last year we saw huge differences in performance characteristics between that hardware using a spinning disk and other similar systems using SSD drives. Generally speaking my hypotheses are: * there is a cohort or set of cohorts out there who would benefit from having e10s multi configured to use only 1 content process * the age of a system is not a strong predictor or performance * the number of physical cores and threads is * the amount of RAM * hard drive speed, especially in cheaper machines with lower ram, an SSD hugely mitigates the penalty of swapping out vs a 4200rpm laptop drive. I want to develop a study, develop performance or satisfaction feedback channels and publish our findings. [1] https://twitter.com/fwuffydragon/status/950496089576222720
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #10) > Post-multi what we're seeing is a lot of people who are very happy with > Firefox performance and some people with really terrible performance. > Anecdotally the people we're seeing with bad performance are people that > have older systems[1] or very under-powered systems. I'm very interested in > collecting the right data from our user's systems to do some analysis and be > able to identify older / slower systems and adjust their e10s configuration > to suit. Why do you think that changing number of content processes will have any effect on cache stats? Both networking and caching happen only in parent process... Did you choose any particular cache probe that you're interested in?
(In reply to Michal Novotny (:michal) from comment #11) > (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #10) > > Post-multi what we're seeing is a lot of people who are very happy with > > Firefox performance and some people with really terrible performance. > > Anecdotally the people we're seeing with bad performance are people that > > have older systems[1] or very under-powered systems. I'm very interested in > > collecting the right data from our user's systems to do some analysis and be > > able to identify older / slower systems and adjust their e10s configuration > > to suit. > > Why do you think that changing number of content processes will have any > effect on cache stats? Both networking and caching happen only in parent > process... > > Did you choose any particular cache probe that you're interested in? I think you misunderstand me, I just want to know ( roughly ) the type of hard drive in the client machine. I believe cache stats in this context is an implementation detail for getting this info. The ultimate goal is to have a graph in the Firefox Hardware report ( and telemetry data ) that shows the proportions of users on SSDs vs spinning hard drives. Let me know if this isn't clearer. Would also like an update on eta for this bug.
(forgot to mention that in the necko meeting: I was looking at how to recognize if a file path is backed by a spinning or solid disk and it seems quite complicated. I will look further into it and do some experiments with it and let you know)
One more way to decide SSD/HDD when you have a physical drive number: https://stackoverflow.com/questions/23363115/detecting-ssd-in-windows Now I have to find a way to get PD number from a file path.
Depends on: 1452966
It doesn't make sense to implement this for other platforms when we cannot have it on Windows.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Jeff, since there doesn't seem to be a good direct way to do this, what do you think about tracking r/w speeds and determining "fast vs slow" drives (kind of a proxy for SSD vs HDD). Another option, do we ask for elevated privileges during installation? Could we check at that point for some subset of users? Perhaps also a one-time update that asks as well? Depends how important this is :)
Flags: needinfo?(jgriffiths)
(In reply to Stuart Philp :sphilp from comment #17) > Jeff, since there doesn't seem to be a good direct way to do this, what do > you think about tracking r/w speeds and determining "fast vs slow" drives > (kind of a proxy for SSD vs HDD). > > Another option, do we ask for elevated privileges during installation? Could > we check at that point for some subset of users? Perhaps also a one-time > update that asks as well? Depends how important this is :) These all sounds like fairly exotic / less dependable directions. I would love to have something relatively quick and easy and if it isn't possible or especially if it take a bunch of time doing bespoke work and doesn't produce reliable results, we should skip.
Flags: needinfo?(jgriffiths)
You need to log in before you can comment on or make changes to this bug.