Nice I will remember that
On 06/10/13 04:23:30, Ed Kapitein <[email protected]> wrote: >I am running one node of the testgrid on a pi, without any problems. >One of the things that might kill your pi is the oomkiller. >I had numerous ocasions where the oomkiller did not kill a job, but >froze the pi itself. >adding the following lines to /etc/sysctl.conf >vm.overcommit_memory = 2 >vm.overcommit_ratio = 80 >made the crashes go away. > >Just my 0.02 BTC > >Kind regards, >Ed > > >On 10/06/13 04:07, Garonda Rodian wrote: >> 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] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]> >> From: [email protected] <mailto:[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] <mailto:[email protected]> >> >> 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 <[email protected] >> <mailto:[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] <mailto:[email protected]> >> > Date: Thu, 26 Sep 2013 19:54:44 +0200 >> > To: [email protected] <mailto:[email protected]> >> > CC: [email protected] <mailto:[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] <mailto:[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 > > >_______________________________________________ >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
