[Freedombox-discuss] [tahoe-dev] Recommendations for minimal RAM usage ?

[Eugen Leitl]

----- Forwarded message from Johannes Nix <Johannes.Nix at gmx.net> -----

From: Johannes Nix <Johannes.Nix at gmx.net>
Date: Fri, 16 Mar 2012 08:19:39 +0100
To: tahoe-dev at tahoe-lafs.org
Subject: Re: [tahoe-dev] Recommendations for minimal RAM usage ?
X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Reply-To: Tahoe-LAFS development <tahoe-dev at tahoe-lafs.org>

Hello Brian,

> Upload and download some large files and then look at the "Recent
> Upload/Download Status" pages for them (linked from the Welcome Page):
> that should give you some idea of how much time is spent for various
> operations. Zfec encoding and AES encryption are pretty minimal: they
> run at 10s or 100s of megabytes per second, at least on regular
> laptop/desktop CPUs. SHA256 hashing is also really fast.

Yes, I see that encryption times don't really matter on a desktop CPU.

> We're really interested in smaller CPUs, like ARM-based FreedomBox /
> PogoPlug / NAS boxes. My first interest is in making these into good
> servers, which means minimzing the work that a storage server must
> perform. 

I think there are two interesting uses for these chips:
Inexpensive, quiet and low-power home servers and mobile
devices such as smart phones.

I have here sitting around a PandaBoard ES which came
yesterday by mail. This is a cheap ARM-based development
board for OMAP4 system-on-a-chips featuring an ARM Cortex-A9 and
a Texas Instruments TMS320C40x DSP. I am interested to learn how to use
the DSP on these boards. While the DSP is mainly intended for
power-efficient media decoding, I think getting to run core crypto
routines like in ge25519.c on the DSP based on the gstreamer / dsplink
framework could be relatively easy to begin with. But I have still no
idea how big the effort is really.

> Minimizing RAM usage (perhaps by making some features
> optional, so we can load less code into memory) should help make them
> work better as clients too. 

Of course this would help. However, main memory sizes of this device
class are increasing fast. Maybe it's worth the effort if it 
improves the overall organization of the code, e.g. to separate client,
server and common stuff. Such a separation of stuff might be 
helpful later if some application wants to use a grid like a "slim" 
client, perhaps for storing of some application configuration /
roaming data, like browser bookmarks.


> And having something to cross-compile the
> binary packages that tahoe needs should help get tahoe installed on
> those boxes faster: currently it can take a couple of hours to
> compile everything necessary. 

Well, to compile a large software on a NAS isn't fun. There
are a number of mini-distributions for such devices emerging 
like Angstrøm Linux. For a single-purpose device this is
arguable the most convenient way. I think the long-term tendency is to
just put Debian on them.


Cheers,

Johannes
_______________________________________________
tahoe-dev mailing list
tahoe-dev at tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE