[tahoe-dev] Recommendations for minimal RAM usage ?

Johannes Nix Johannes.Nix at gmx.net
Wed Mar 7 23:37:22 UTC 2012


just to acknowledge Zooko's comment, it's clear to me that there
are multiple more important topics than adjusting Tahoe-LAFS
to minimal RAM. 

Maybe I should take the way of least resistance and try to make an
upgrade to some more modern, powerful and fatter hardware.... such as
the Rasperry Pi *g*. The Rasperry is going to ship with 256 MB RAM but
its CPU is said to be relatively slow. I also tried (so far
unsuccessfully) to install Tahoe on a Nokia N900 Phone which has a
OMAP3 SoC with ARM Cortex A8 CPU and, for purposes of cryptography much
more interesting, an integrated TMS320C64x DSP. This platform is
certainly more powerful than my NAS, so I think it's completely
realistic to run a Tahoe-LAFS client on a N900 or comparable open

I would love to help a bit, it's interesting enough for me. I'll try to
dig a little into the code at least. I think if I can do
something, it would be rather highly focused changes in some 
hot spots than general overhauls.

OTOH I currently also have to address some job-related issues...
I would love to get paid for work at that level, heck.

What Brian does around Ed25519 looks great.... What are the main speed
bottlenecks  in Tahoe-LAFS now? Could it be grid latencies / network
bandwidth for fast systems and encoding for slow processors? 
And would a parallelized variant of the encoding make sense for a
typical multicore consumer laptop?


- Johannes

On Mon, 5 Mar 2012 15:49:43 -0700
"Zooko Wilcox-O'Hearn" <zooko at zooko.com> wrote:

> I wrote:
> On Mon, Mar 5, 2012 at 12:24 PM, Zooko Wilcox-O'Hearn
> <zooko at zooko.com> wrote:
> >
> > Just to be explicit about this, I'm not going to start doing these
> > experiments myself anytime soon. I would love for Tahoe-LAFS to get
> > slimmer on memory usage, and to continue to fit into more and more
> > cute little ARM devices. (I just ordered my Raspberry Pi!) But, I
> > have higher priorities in Tahoe-LAFS development right now. I'll
> > offer
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > encouragement, advice, feedback, and patch review.
> For the record, my highest priorities in life nowadays are my family
> and Least Authority Enterprises. LAE work often contributes directly
> or indirectly to Tahoe-LAFS development (we have a policy of
> contributing all of the source code that we write, plus trying to give
> back in terms of documentation, knowledge we've gained, etc.). But it
> isn't primarily about Tahoe-LAFS development.
> In the context of Tahoe-LAFS development, my first priority right now
> is unblocking Brian's accounting work by releasing a version of
> pycryptopp with his Ed25519 port in it:
> https://tahoe-lafs.org/trac/pycryptopp/milestone/0.6.0
> I'm the limiting factor in that, since we decided to use pycryptopp as
> the vehicle for tahoe-lafs to use Ed25519, and since I want to do the
> API and the new pycryptopp release my way.
> Once Brian is sufficiently unblocked, my next priority within
> Tahoe-LAFS development will be helping Kevan and others address the
> regressions and bugs in the new 1.9 code:
> https://tahoe-lafs.org/trac/tahoe-lafs/milestone/1.9.2
> Regards,
> Zooko
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

More information about the tahoe-dev mailing list