4 ms·

I don't think this could be interpreted as a visual lag. fsync() is usually used by databases, not UI libraries. So the title is misleading. My chinese Android

I don't think this could be interpreted as a visual lag. fsync() is usually used by databases, not UI libraries. So the title is misleading. My chinese Android phone has a more annoying hardware lag - a delay between touching the screen and touch event processing is over 100 ms. Any drum app is unusable. And if you try to scroll something up and down fast it is easy to see how the content on the screen lags behind finger movements.

daenney 10y ago
> I don't think this could be interpreted as a visual lag. fsync() is usually used by databases, not UI libraries. As others have pointed out, a lot of apps do I/O related work in the UI thread, mostly b/c people don't care enough not to (and sometimes it's hard). Flipping a toggle somewhere can easily cause a write to a sqlite database to need to happen. And it's for far more than just databases. > So the title is misleading. I don't think the title is that misleading, it is very much and significantly faster at storage operations than the Pixel, and those matter quite a bit in your daily usage.
- kllrnohj 10y ago
  > I don't think the title is that misleading, it is very much and significantly faster at storage operations than the Pixel, and those matter quite a bit in your daily usage. All that was tested was fsync(), not "storage operations", and the Moto Z was faster at fsync() because it turns off fsync. But it's not clear why this matters to anything. Lag is usually the result of file system reads being slow (paging in code/resources), not writes being slow, so how does fsync performance matter?
  - daenney 10y ago
    > All that was tested was fsync(), not "storage operations", and the Moto Z was faster at fsync() because it turns off fsync. That's not what was tested, that's only what is shown in the graph. The lack of fsync contributes to it. I wrote a little fio benchmark driver to fill all available device storage with random 4k writes, print perf stats along the way One of the other things clearly mentioned is that b/c of Google's use of an additional FUSE filesystem they take a 30% performance hit: This means that on the Pixel every user IO gets a round-trip back into user-space before hitting the NAND. Fuse burns more CPU and slows down IO by up to 30%. Sure, the nobarrier trick makes a lot of difference but it's not the only thing in that post, nor was that the actual benchmark.
    - kllrnohj 10y ago
      Ok maybe the author tested other things but he didn't REPORT on anything but fsync results. There's no comparison at all of file system performance other than fsync() numbers. > One of the other things clearly mentioned is that b/c of Google's use of an additional FUSE filesystem they take a 30% performance hit Only on one mount point which isn't used for anything lag-related. There's no code on that mount point. There's nothing UI-critical on that mount point. It means your photos might load a bit quicker, but again given that there was no actual numbers or objective information we don't actually know how the two compared. Good job to Motorola to handle that in the kernel, but it contributes nothing to the spectacular claim that the Pixel has 10x more lag than the Moto Z. But given this claim: "They got Moto-Z to performing close to high-end laptop SSDs." I think it's pretty obvious the author only actually looked at fsync(). Unless somehow the Moto-Z is ~5x faster than the storage in an iPhone 7 (which is the gap between an iPhone 7's storage and a high-end laptop SSD), it's obvious bullshit.
    - strcat 10y ago
      Google uses FUSE for shared storage, not internal app storage. Apps are supposed to keep most of their data in internal storage since shared storage breaks the whole isolated security model. Content providers and other intents are supposed to be preferred for sharing data. It might a good thing that doing things properly is faster... and throwing everything into the kernel means more and more attack surface. Google maintain the kernel implementation (sdcardfs) too... they choose to use the FUSE implementation for good reasons. Of course, most other vendors only care about benchmarks, not things like robustness / security.
digi_owl 10y ago
I suspect that the kernel prioritize getting fsync done above all else. This because data written to disk is data safe from sudden power loss. This means that all other calls, ui draw calls included, gets put aside until the fsync is done. And that depends on the IO speed of the hardware, and the amount of data in the queue. On older android devices i have run apps that could show IO rates. And invariably when things would lag or freeze the IO would be maxed out (one offender would be Facebook and their Messenger, because after each update they would force a recompile or something).
BearOso 10y ago
Android 7.1 is supposed to have updates to the graphics stack that improve input lag. Apparently the Nexus devices went from 48ms lag to 18ms lag with the release.

daenney 10y ago

> I don't think this could be interpreted as a visual lag. fsync() is usually used by databases, not UI libraries. As others have pointed out, a lot of apps do I/O related work in the UI thread, mostly b/c people don't care enough not to (and sometimes it's hard). Flipping a toggle somewhere can easily cause a write to a sqlite database to need to happen. And it's for far more than just databases. > So the title is misleading. I don't think the title is that misleading, it is very much and significantly faster at storage operations than the Pixel, and those matter quite a bit in your daily usage.

kllrnohj 10y ago
> I don't think the title is that misleading, it is very much and significantly faster at storage operations than the Pixel, and those matter quite a bit in your daily usage. All that was tested was fsync(), not "storage operations", and the Moto Z was faster at fsync() because it turns off fsync. But it's not clear why this matters to anything. Lag is usually the result of file system reads being slow (paging in code/resources), not writes being slow, so how does fsync performance matter?
- daenney 10y ago
  > All that was tested was fsync(), not "storage operations", and the Moto Z was faster at fsync() because it turns off fsync. That's not what was tested, that's only what is shown in the graph. The lack of fsync contributes to it. I wrote a little fio benchmark driver to fill all available device storage with random 4k writes, print perf stats along the way One of the other things clearly mentioned is that b/c of Google's use of an additional FUSE filesystem they take a 30% performance hit: This means that on the Pixel every user IO gets a round-trip back into user-space before hitting the NAND. Fuse burns more CPU and slows down IO by up to 30%. Sure, the nobarrier trick makes a lot of difference but it's not the only thing in that post, nor was that the actual benchmark.
  - kllrnohj 10y ago
    Ok maybe the author tested other things but he didn't REPORT on anything but fsync results. There's no comparison at all of file system performance other than fsync() numbers. > One of the other things clearly mentioned is that b/c of Google's use of an additional FUSE filesystem they take a 30% performance hit Only on one mount point which isn't used for anything lag-related. There's no code on that mount point. There's nothing UI-critical on that mount point. It means your photos might load a bit quicker, but again given that there was no actual numbers or objective information we don't actually know how the two compared. Good job to Motorola to handle that in the kernel, but it contributes nothing to the spectacular claim that the Pixel has 10x more lag than the Moto Z. But given this claim: "They got Moto-Z to performing close to high-end laptop SSDs." I think it's pretty obvious the author only actually looked at fsync(). Unless somehow the Moto-Z is ~5x faster than the storage in an iPhone 7 (which is the gap between an iPhone 7's storage and a high-end laptop SSD), it's obvious bullshit.
  - strcat 10y ago
    Google uses FUSE for shared storage, not internal app storage. Apps are supposed to keep most of their data in internal storage since shared storage breaks the whole isolated security model. Content providers and other intents are supposed to be preferred for sharing data. It might a good thing that doing things properly is faster... and throwing everything into the kernel means more and more attack surface. Google maintain the kernel implementation (sdcardfs) too... they choose to use the FUSE implementation for good reasons. Of course, most other vendors only care about benchmarks, not things like robustness / security.

digi_owl 10y ago

I suspect that the kernel prioritize getting fsync done above all else. This because data written to disk is data safe from sudden power loss. This means that all other calls, ui draw calls included, gets put aside until the fsync is done. And that depends on the IO speed of the hardware, and the amount of data in the queue. On older android devices i have run apps that could show IO rates. And invariably when things would lag or freeze the IO would be maxed out (one offender would be Facebook and their Messenger, because after each update they would force a recompile or something).

BearOso 10y ago

Android 7.1 is supposed to have updates to the graphics stack that improve input lag. Apparently the Nexus devices went from 48ms lag to 18ms lag with the release.