On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote: > On Jan 5, 2008 5:11 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > > On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > > > NOT finding a file should be efficient. > > > > Yes. > > > > Where do the delay come from? Can anyone measure the LPC? > > I will try to measure for you but remember it is running uncached. > Each and every access is a full LPC cycle, which is not really fast.
True. It is definately LPC access time causing this. On Sun, Jan 06, 2008 at 05:17:31PM +0100, Carl-Daniel Hailfinger wrote: > IIRC the PCEngines alix.1c has parallel flash Nope. Both the soldered-on flash and obviously the LPC port are LPC. > for all boards with LPC-to-SPI translation through a IT8716F Super > I/O chip, the following applies: > My calculations suggest that for optimal reads (4 bytes at a 4 byte > boundary) with the IT8716F SPI translation function, we need (1 byte > opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI > bus alone. With a maximum of 33 MHz for the SPI clock on that particular > chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this > optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top > of the pure SPI bus time we have to add the time to transmit and receive > that data over LPC. Say 5 us per byte. That's rather slow for us, yes. On Mon, Jan 07, 2008 at 10:40:02AM +0100, Carl-Daniel Hailfinger wrote: > Well, we can't use CPU cache, but we can abuse CAR memory as cache I like this. > 1. Explicit "stop searching here" marker. Maybe. But I do not think this is very clean.. On Mon, Jan 07, 2008 at 08:40:31AM -0800, ron minnich wrote: > I would rather not walk all of empty space ever at any time. I think the cost of one walk is ok for the flexibility gained. > I like the end marker best. I think the runtime-created index is much more fun. It also keeps the lar format very clean. In practice, the marker is the most efficient method, but it is a bit of an abomination IMO. :p How do we handle the integrity issue when a single flash block that contains the start of a lar file is erased at runtime? (Thus breaking a link in the list.) That re-introduces the walking cost if we want to be able to find any files beyond the erased block. Maybe both run-time indexing and marker is good? But then there's no point in the marker. So only build the index when a hole is encountered. //Peter -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
