Very interesting - your grid looks to have been up for 2 days now :). I had investigated the BeagleBone Blacks, but eventually decided that on paper the Raspberry Pi was a better very low end platform (2 USB host ports vs. 1 was more important to me than the BBB's better CPU and lower power draw) and was a bit cheaper, and the ODROID-U2 was a better low end platform (quad core ARM + 2GB RAM, still 2 USB host ports, still 100Mbps Ethernet but at least it's not on the USB bus anymore).
Did you check the Raspberry Pi's on-board voltage at the time of the brownouts/crashes, or can you help with with whatever test case crashed it, so I can check on that myself? From: [email protected] To: [email protected]; [email protected] CC: [email protected] Subject: RE: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial report Date: Fri, 4 Oct 2013 23:23:20 -0700 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: [email protected] [mailto:[email protected]] On Behalf Of Garonda Rodian Sent: Friday, October 4, 2013 9:11 PM To: Anders Genell Cc: [email protected] 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: [email protected]; [email protected] From: [email protected] Subject: Re: [tahoe-dev] Precise Puppy (linux) tahoe-lafs 1.10.0 initial report Date: Fri, 4 Oct 2013 06:43:55 +0200 To: [email protected] 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 <[email protected]>: 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: [email protected] > Date: Thu, 26 Sep 2013 19:54:44 +0200 > To: [email protected] > CC: [email protected] > 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 > [email protected] > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
