[tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial report

jason.johnson at p7n.net jason.johnson at p7n.net
Sat Oct 5 06:23:20 UTC 2013


I have been using BeagleBone Blacks with debian wheezy. So far so good the
grid is located https://tahoe.netgreen.us there is 8 bbb in this grid. PI
seemed to brown out or crash on me during testing. Just thought I would toss
this in incase you wanted to take a look.

 

Jason

 

From: tahoe-dev-bounces at tahoe-lafs.org
[mailto:tahoe-dev-bounces at tahoe-lafs.org] On Behalf Of Garonda Rodian
Sent: Friday, October 4, 2013 9:11 PM
To: Anders Genell
Cc: tahoe-dev at tahoe-lafs.org
Subject: Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial
report

 

Thank you for the feedback, Anders!

I'm definitely not starting X on the Pi (model B), though I had not yet
lowered the GPU RAM to 16MB.

Can you give me an idea of what "a bunch of very large files" means -
100x100MB?  50x10GB?  4x1TB?  I can say I almost always use Sandisk Ultra or
Extreme SD cards, though I was honestly planning on having the storage be on
a USB flash drive, leaving the SD 100% for the boot drive and OS.

I was actually hoping to run two storage nodes, with either two USB flash
drives on the same grid, or one USB flash drive and one USB hard drive, each
on different grids (a "small storage" grid and a "large storage" grid).

Back to the original topic, Precise Puppy 5.7.1 on a physical box, quad core
i7 with 4GB of RAM has now successfully completed one test, 100% local, with
two storage nodes, one Introducer, and on client/Gateway, once I figured out
which ports in the config files are used for what.  Up to a 1GB file was
uploaded without a problem, though it appears that the bottleneck was the
gateway with a CPU bottleneck.  Regrettably, it looks like profiling the
Python code will require altering the python code, so I've got to figure out
how to do that so I can see where the slow point is.

Does anyone know if it's OK on Debian/Ubuntu to statically assign ports from
the IANA dynamic port range of 49152 to 65535 if the system is also likely
to assign some dynamic ports?  I'm a big fan of knowing what your ports are,
and that'll be critical once I toss a firewall or two into the mix.

  _____  

CC: zookog at gmail.com <mailto:zookog at gmail.com> ; tahoe-dev at tahoe-lafs.org
<mailto:tahoe-dev at tahoe-lafs.org> 
From: anders.genell at gmail.com <mailto:anders.genell at gmail.com> 
Subject: Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial
report
Date: Fri, 4 Oct 2013 06:43:55 +0200
To: deepside at hotmail.com <mailto:deepside at hotmail.com> 

Hi again, sorry for replying so late...

 

The Pis used for storage nodes are in general not used for anything else,
and we try to keep X turned off to save resources. You can also lower the
amount of RAM reserved for the GPU to a minimal 16 Mb in the config.txt file
in the Pi boot partition. 

 

Also, some of our Pis krashed when stressed, e.g. by uploading a bunch of
very large files, until the SD card was replaced by a Sandisk
SDSDX-016G-X46. The Pi is notoriously sensitive about what card is being
used. 

 

Finally, if lack of memory is limiting performance, it is possible to set up
a swap partition on the Pi. It will slow things down horribly, of course,
but may just get the job done. 

 

Regards,

Anders

 


28 sep 2013 kl. 05:20 skrev Garonda Rodian <deepside at hotmail.com
<mailto:deepside at hotmail.com> >:


Thank you for the report on the Raspberry Pi being used in production - are
you and your friends running just one storage node on the Pi, or are you
also running any other software (second storage node, Tor, I2P, OpenVPN?).
My RPi consistently simply dies during the trial - no errors, it just...
stops, but based on your feedback, I'll continue.

As I'm hoping to run some medium scale tests, I'm going to have to have
something to generate a lot of nodes all at once, and I hate wasting effort.
At this point, I'm targetting something more like the old terminal/3270/DOS
menus and/or wizards - simple walkthroughs with questions to answer that can
be used to create the files for an entire grid, or add to an existing grid's
files, hopefully with some manner of "wrapper" (Tor, I2P, OpenVPN)
capabilities available as well.

Does anyone have a good Python tutorial for experienced programmers?  My C
and assembly used to be pretty good and my SQL is excellent, but I haven't
picked up a new language in a long time, and I never dealt with
parallelization much.

P.S. the Precise Puppy 5.7.1 VM at 768MB fails with the GUI, but succeeds at
the command line with everything nonessential (cups printer daemon)
disabled, so the critical memory limit for the trial is very close to there,
OS overhead included.

> From: anders.genell at gmail.com <mailto:anders.genell at gmail.com> 
> Date: Thu, 26 Sep 2013 19:54:44 +0200
> To: zookog at gmail.com <mailto:zookog at gmail.com> 
> CC: tahoe-dev at tahoe-lafs.org <mailto:tahoe-dev at tahoe-lafs.org> 
> Subject: Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial
report
> 
> 
> > 
> >> P.S. If I'm lucky, the Raspberry Pi has completed its trial run, though
if this is the RAM requirement, I'm not holding out much hope.
> > 
> > It is too bad about #1476, because I really like to be able to run
> > unit tests everywhere and all the time. However, I believe that the
> > gateway or storage-server itself will run fine on Raspberry Pi, even
> > if (due to #1476) the tests will fail.
> > 
> > 
> 
> Just to chime in: We have several storage nodes running off of RPis in our
friendnet, and they seem to work fine as such. 
> 
> We would absolutely love a setup menu - many of our participating friends
have never used a terminal. Looking forward to be dazzled!!
> 
> Regards,
> Anders
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org <mailto:tahoe-dev at tahoe-lafs.org> 
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20131004/830b0c62/attachment-0001.html>


More information about the tahoe-dev mailing list