iLiad Speeding up the system?

[firekat]

To all you hacker types out there one of the things that is frustrating is how slow the iLiad is.

With all the talent we have here is there any way that we can "turbo" the iLiad? I wouldn't know about all the details - I am just wondering if it is at all feasible?

Good Luck To Us All!

[pilotbob]

Originally Posted by firekat

To all you hacker types out there one of the things that is frustrating is how slow the iLiad is.

With all the talent we have here is there any way that we can "turbo" the iLiad? I wouldn't know about all the details - I am just wondering if it is at all feasible?

Good Luck To Us All!

If you can get to the bios you may be able to try to overclock it.

BOb

[rincewind]

The iLiad runs on a 400 mhz ARM which should be the same that is in tons of PDAs (ipaqs, sharp ++), and it should be able to provide vastly better performance. This is however a problem with two things: 1 - the software is badly written. For example, opening a PDF, ipdf must first be loaded, it then has to read the file, then render the page, then do a screen refresh (1 second). Saving render-state on close, load the last page (as a picture) etc would make this faster, but is more difficult. The Content lister for is another GREAT example. Show *6* files without even having any decent information about them except size, should NOT take more than the 1 second screen refresh. 2: The screen is slow. It will take a whole second to update. This means that the minimum time you could theoretically see is 1 second after any button press.

/R

[axel77]

I also always ask me what exactly takes 40 seconds to boot?

I guess networking will take some time, copying around the kernel in memory might also take some seconds..

Having done some embedded linux development in the past I know we once discovered that actually how the linux kernel works, it loads application from "disk" (copy flash memory to volatile memory) and then does the dynamic linking with the libraries... this all takes time, on an embedded device, technically, one could execute a static linked binary directly out of flash, saving quite some time and also memory use, but this kind of "execute from disk" is something not a linux kernel by default caters for. Never have implemented such a static direct execution, since its a big hack... and with usual development deadlines, it doesn't add functionality but "only" some speed on boot and when starting applications..

[joblack]

Originally Posted by axel77

I also always ask me what exactly takes 40 seconds to boot?

I guess networking will take some time, copying around the kernel in memory might also take some seconds..

Having done some embedded linux development in the past I know we once discovered that actually how the linux kernel works, it loads application from "disk" (copy flash memory to volatile memory) and then does the dynamic linking with the libraries... this all takes time, on an embedded device, technically, one could execute a static linked binary directly out of flash, saving quite some time and also memory use, but this kind of "execute from disk" is something not a linux kernel by default caters for. Never have implemented such a static direct execution, since its a big hack... and with usual development deadlines, it doesn't add functionality but "only" some speed on boot and when starting applications..

It's a normal Linux boot. To write the actual RAM data on disk should speed up the process. But on my Asus EEE Laptop the network card isn't working after I return from hibernation.

I'm wondering how Sony's Reader is doing it.

[sanders]

Originally Posted by rincewind

For example, opening a PDF, ipdf must first be loaded, it then has to read the file, then render the page, then do a screen refresh (1 second). Saving render-state on close, load the last page (as a picture) etc would make this faster, but is more difficult.

Saving the last-rendered page as a picture when quitting iPDF would only be useful if you load the exact same PDF next time you start up iPDF, i.o.w. only help as part of a quick-startup feature. Since the boot time is vastly longer, I don't think it would make much sense to add this optimization to iPDF (yet).

What would help a lot, in my humble opinion, is to get rid of X. The iLiad only uses full-screen, custom applications anyway. We would be deprived of some (cool) ported software, but gain a system with less overhead.

[orcinus]

Originally Posted by joblack

I'm wondering how Sony's Reader is doing it.

Extremely slowly...