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@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
