View Single Post
Old 11-06-2020, 07:24 PM   #11
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,506
Karma: 26047202
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
Okay, finally had time to ran some minimal tests with the (scrambled, Calibre'd) books @Mrs_Often sent me.

As a reminder, I'm on a Forma, on FW 4.24. It was unplugged, with Wi-Fi enabled and an SSH shell session open, and at the battery sweet spot of ~70%.

Given that the sources were scrambled (straight) ePubs, I tested both those and a kepubified copy.

The "good" news is that they behave roughly like any other book I'm used to.

In terms of purely computational power required by (forward) page-turn on *pure text* pages (via the HW buttons) [i.e., that's plain old (real) CPU time, for you *nix nerds out there]:

* KOReader (CRe, on the ePub, not that it matters much): ~60ms
* ACCESS (KePub): ~200-250ms
* RMSDK (ePub): ~450-600ms (a.k.a., Sleepy ;p)

The "faster" the renderer is, the easier it is to catch outliers in actual perceived latency (outside of flashing pages).
There *may* indeed be instances where the CPU is veeeeeery slightly slower to clock up. Or if not that exactly, where there's a more noticeable bottleneck somewhere fairly low-level.

(Again, text only, that means no image, and keeping to the same document shard, because ACCESS is noticeably hitchy when crossing a file border, as is RMSDK, to a lesser extent (mainly because it's so slow in general that you don't really notice the difference ;p)).

(A Kindle with the KF8 renderer used to sit in the sub-100ms range, last I checked, sometimes going neck to neck with KOReader. Which is exceedingly good, as the Kindle *is* a chunked renderer, unlike CRe, which requires a longer (a couple of seconds here) caching step on *first* open to be able to deliver such runtime performance).

Massive grain of sand: Actual latency is *extremely* hard to measure accurately. I don't have the hardware nor skills to make a definitive assertion, so, this is more of a very vague feeling. I tend to notice it more in ACCESS, but I won't lie by saying I've never felt it in KOReader .

I have no actual clue how well the SoC itself is supposed to clock up and down (in terms of latency), and the CPU governor in use (interactive) is notoriously tricky to tune right, and as theses devices run an old-ish kernel, it makes the whole thing even murkier.

I *do* notice it having clocked up (and to the max speed, which is typical of interactive) in all cases, so, that's at least a good thing .

And, yes, if you're sensitive to latency issues, as far as I'm concerned, a 50ms difference is noticeable, and a 100ms one starts to get annoying.
(Fair warning: I've done a fair share of competitive first person shooter gaming (or, hell, playing a healer in a mythic raider group in WoW, which might actually be worse ;p) in my days, so I may be more sensitive than most).

Last edited by NiLuJe; 11-06-2020 at 07:45 PM.
NiLuJe is offline   Reply With Quote