The rebuilt Pi2 that was turning in 70k jobs is now turning in 55k jobs and running 3 consecutive jobs at a temp of ~40C.
I will push the other two Piz (a 2 and a 3) to 4 concurrent jobs and watch the temps.
I am running my PI2s 7/8 of my Pi 2s overclocked to 1Ghz and usually see 50K or less seconds for the results. My 900Mhz Pi 2 takes nearly 60K seconds. With a large fan and no enclosure of any kind in a 21-22C ambient room, they all keep 44-47C w/ heatsinks.
I am running all of mine off of the Raspbian "Lite" image, as I have no need for X.
I have been toying with getting one when I get a Pi 3 and using it as a network share for the boinc data directory for all the Pis. I have had terrible luck getting a E@H install on a SD card to last more than a few weeks. Start getting MMC errors then no longer boots. Have tried 4-5 different cards and always the same. Distributed.net does very few writes and runs fine for weeks on end. But bought the Pis for E@H.
If I do it, probably will, will post some info on it.
I have had terrible luck getting a E@H install on a SD card to last more than a few weeks. Start getting MMC errors then no longer boots. Have tried 4-5 different cards and always the same.
I've had no issues with the Samsung Evo 16Gb cards and the EMTEC Class 10 8 gig cards.
I have been toying with getting one when I get a Pi 3 and using it as a network share for the boinc data directory for all the Pis. I have had terrible luck getting a E@H install on a SD card to last more than a few weeks. Start getting MMC errors then no longer boots. Have tried 4-5 different cards and always the same. Distributed.net does very few writes and runs fine for weeks on end. But bought the Pis for E@H.
If I do it, probably will, will post some info on it.
In an earlier post of mine I noted using a USB-to-mSATA drive. In this configuration the /boot partition stays on the microSD card and the /root partition moves to the mSATA drive where the majority of the reads/writes occur. I have a procedure on my website for doing this. I just used it recently for the mSATA effort. It was originally used for a Rasparian distro so the "/dev/paths" might be the same or different. If using some other Pi distro the paths might also be different but "path substitution" in the procedure should be straight forward. Its fairly easy and straight forward and you can probably use it with the 314 gib drive. I had originally used this procedure for a large USB external powered from a hub attached to a Pi_early_early_model and it was fine. I quit using the Pi though because "back then" they really struggled to crunch. Now its a different story.
The /boot partition will be written to during kernel updates so do not "write protect" it. By using this configuration most of the uploads/downloads/processing will take place on this drive and should eliminate any issues with data corruption on an SD card. I have done it both ways and have not experienced the failure rate that you mention.
On a Pi2 when moving from 3 concurrent WUs to 4 concurrent Wus my processing time has moved from ~55k to 77k and the 4th job is "waiting for memory". I have reverted to 3 concurrent WUs on this Pi to see if it returns to 55K without the "wait for memory" condition. Two other Piz, a 2 and a 3 are not experiencing this "wait for memory" condition or increase in processing time.
but if i monitor it - it does not come close to that typically ~100M. I'm guessing you could override this limit via app_config.xml but the wiki doesn't provide details
edit: i've had a quick look at the source code and no you can't override from app_config.xml, so apologies for the red fish..
but if i monitor it - it does not come close to that typically ~100M. I'm guessing you could override this limit via app_config.xml but the wiki doesn't provide details
edit: i've had a quick look at the source code and no you can't override from app_config.xml, so apologies for the red fish..
hth.
looking at my client_state.xml files I see multiple entries like the following:
The rebuilt Pi2 that was
)
The rebuilt Pi2 that was turning in 70k jobs is now turning in 55k jobs and running 3 consecutive jobs at a temp of ~40C.
I will push the other two Piz (a 2 and a 3) to 4 concurrent jobs and watch the temps.
How about a 314 gig drive
)
How about a 314 gig drive designed just for the PI?
RE: The rebuilt Pi2 that
)
I am running my PI2s 7/8 of my Pi 2s overclocked to 1Ghz and usually see 50K or less seconds for the results. My 900Mhz Pi 2 takes nearly 60K seconds. With a large fan and no enclosure of any kind in a 21-22C ambient room, they all keep 44-47C w/ heatsinks.
I am running all of mine off of the Raspbian "Lite" image, as I have no need for X.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: How about a 314 gig
)
I have been toying with getting one when I get a Pi 3 and using it as a network share for the boinc data directory for all the Pis. I have had terrible luck getting a E@H install on a SD card to last more than a few weeks. Start getting MMC errors then no longer boots. Have tried 4-5 different cards and always the same. Distributed.net does very few writes and runs fine for weeks on end. But bought the Pis for E@H.
If I do it, probably will, will post some info on it.
P.S.
Did you see this?
http://wdlabs.wd.com/Support/#downloads
RE: I have had terrible
)
I've had no issues with the Samsung Evo 16Gb cards and the EMTEC Class 10 8 gig cards.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
Berryboot
)
Berryboot home
http://www.berryterminal.com/doku.php/berryboot
I tried it and it did install Raspian to a USB stick.
RE: RE: How about a 314
)
In an earlier post of mine I noted using a USB-to-mSATA drive. In this configuration the /boot partition stays on the microSD card and the /root partition moves to the mSATA drive where the majority of the reads/writes occur. I have a procedure on my website for doing this. I just used it recently for the mSATA effort. It was originally used for a Rasparian distro so the "/dev/paths" might be the same or different. If using some other Pi distro the paths might also be different but "path substitution" in the procedure should be straight forward. Its fairly easy and straight forward and you can probably use it with the 314 gib drive. I had originally used this procedure for a large USB external powered from a hub attached to a Pi_early_early_model and it was fine. I quit using the Pi though because "back then" they really struggled to crunch. Now its a different story.
The /boot partition will be written to during kernel updates so do not "write protect" it. By using this configuration most of the uploads/downloads/processing will take place on this drive and should eliminate any issues with data corruption on an SD card. I have done it both ways and have not experienced the failure rate that you mention.
On a Pi2 when moving from 3
)
On a Pi2 when moving from 3 concurrent WUs to 4 concurrent Wus my processing time has moved from ~55k to 77k and the 4th job is "waiting for memory". I have reverted to 3 concurrent WUs on this Pi to see if it returns to 55K without the "wait for memory" condition. Two other Piz, a 2 and a 3 are not experiencing this "wait for memory" condition or increase in processing time.
RE: On a Pi2 when moving
)
This i think, is boinc deciding, based on what the application says it needs - regards memory.
It shows up in the client_state.xml file as a rsc_memory_bound. I'm assuming you do have free memory to use?
I notice for example an OAS task is about 150M,
but if i monitor it - it does not come close to that typically ~100M. I'm guessing you could override this limit via app_config.xml but the wiki doesn't provide details
edit: i've had a quick look at the source code and no you can't override from app_config.xml, so apologies for the red fish..
hth.
RE: RE: On a Pi2 when
)
looking at my client_state.xml files I see multiple entries like the following:
p2030.20151015.G188.44+00.94.C.b5s0g0.00000_2257
einsteinbinary_BRP4
147
17500000000000.000000
350000000000000.000000
260000000.000000
20000000.000000
When you reference free memory where is this defined? It this set in the parameters: "Use at most XXX% of CPU time"