Difference between revisions of "Talk:Raspberry Pi"

From ArchWiki
Jump to: navigation, search
(Enable fsck on boot)
 
(35 intermediate revisions by 11 users not shown)
Line 1: Line 1:
19:39:03  +leming | yeah, i just saw that trash a few minutes ago
+
== Overclocking section ==
  
19:39:13  +leming | feel free to use some superpowers and make that disappear
+
"The overclocked setting for CPU clock applies only when the governor throttles up the CPU, i.e. under load. To query the current frequency of the CPU:"
  
19:40:24  +leming | not sure what logic was used in the decision to just duplicate random parts of our site
+
This is not entirely true. I had tried to post more information and it was edited. This is an overview wiki and it needs to be very concise, I get that. However, the problem is that the Pi kernel now defaults to the 'powersave' governor on boot up as a failsafe for an overclocking failure. After spending an afternoon playing around with minimum and maximum frequency settings I am convinced that the powersave governor is so safe that it ignores any use frequency range and the default factory Pi setting might be hard coded in (maybe a packager could verify that).
  
19:42:58  +leming | it would be one thing if it was done extraordinarily well, it's another being done in the most fantastically awful way possible
+
Things I noted in my tests with the powersave governor:
 +
* I set the minimum to the Modest setting in /boot/config and even with a 100% load of several dd commands running at a nice of -19 the overclocking never kicked in even with the processor.
 +
* There is not really a better way to switch modules at boot time than using userspace systemd tools (and defaulting to a sane frequency in the most desired behavor for an experimental platform). (See this-> [http://www.freedesktop.org/software/systemd/man/modules-load.d.html])
 +
* The config.txt file on my Pi is incorrect in the comment '## Some over clocking settings, govenor already set to ondemand'
  
19:43:18  +leming | nevermind wholly off-topic for the arch (read: x86) wiki
+
This should possible be noted in the Troubleshooting section? (e.g., cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq never reflects overclock setting even under high load. Make sure the powersave governor is not loaded).
[[User:Danielwallace|gtmanfred]] ([[User talk:Danielwallace|talk]]) 23:44, 22 October 2012 (UTC)
+
  
I am not for duplicating stuff at [http://archlinuxarm.org/ archlinuxarm.org] but it'd be silly not to put a little mention to there..[[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 14:43, 5 November 2012 (UTC)
+
I will file a bug report to have the incorrect comment replaced in config.txt.
  
== deletion ==
+
{{unsigned|20:44, 20 August 2014‎|Adsicks}}
why delete this site? does it hurt? archlinuxarm.org is linking to the archlinux wiki in general [[User:Markuman|Markuman]] ([[User talk:Markuman|talk]]) 10:51, 12 January 2013 (UTC)
+
 
 +
:Assuming that the ''powersave'' governor does not throttle up the CPU, the note is still accurate. But I can confirm that Arch Linux ARM still uses ''ondemand'' as the default governor. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 August 2014 (UTC)
 +
 
 +
== Benchmarking comments ==
 +
Alad - I believe these additions offer the layman some guidance when dealing with slow performance [http://archlinuxarm.org/forum/viewtopic.php?f=64&t=9467 inspired by this forum post], not knowing why, and wanting to remedy it.  I carefully selected the wording and metrics to avoid any particular brand promotion and to provide not objective but quantitative results that users can use as a point of comparison back to their own systems.  How would you propose changing the content to not give, "an objective measure?"  [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 22:55, 9 November 2015 (UTC)
 +
 
 +
:I looked over the section again, and the first part (up until ".. for illustrative purposes") does look good - encouraging users to compare their own results, rather than try to make something conclusive for everyone like the old [[SSD benchmarking]] article. I'm still unconvinced on the part after. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:00, 10 November 2015 (UTC)
 +
 
 +
::Well, one hallmark of a correctly designed scientific experiment is results relative to a control.  Since there is not reference hardware available to users, I used my own experiences with a "slow" and "fast" card to serve as surrogates for people.  I don't know how else to provide a positive control and I respectfully disagree with your assessment of that section. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 08:51, 10 November 2015 (UTC)
 +
 
 +
:::Why is the section on the Raspberry Pi page on ArchWiki? It is neither specific to Rpi nor Arch.
 +
:::What is the purpose of the section? If people have fast enough card from the beginning, they don't care about the section, and if their card is slow, they don't need to be told how to verify that their card is slow.
 +
:::As to the scientific accuracy, why do you compare only Class 10 vs. UHS-I? Some more extensive benchmarks show that even Class 6 or 4 can be faster on random write than Class 10 [http://www.tomshardware.com/reviews/microsdhc-memory-card-performance,3011-12.html], and similarly some Class 10 cards can be faster than UHS-I [http://www.tomshardware.com/reviews/sdxc-sdhc-uhs-i,2940-10.html]. Your experiments only shows the results for your particular cards, in a totally unreproducible way without even mentioning the vendor and model names. From what I can tell you're comparing an aged low-end Class 10 card with a brand new high end UHS-I model. '''Edit:''' Also, the conditions of the experiment are subjective, because the performance depends on the used filesystem, kernel version and configuration (namely the [[Sysctl#Virtual_memory|virtual memory]] settings). Optimizing performance is not solely about the hardware.
 +
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:03, 10 November 2015 (UTC)
 +
 
 +
::::the answer to your first question is in the text I wrote.  Yes, there is disagreement on the web on the topic to your 2nd point as is the case for many topics on the web.  Yes, my results are consistent with my hardware; I also explained this in the text. I disagree with your assessment that what I wrote is "totally unreproducible" for the reasons you cited.  I would challenge you to take two different cards of different vintages and show similar differences in the random writes and in a discrete pacman installation as I have done.  I suspect you draw similar conclusions.  You aren't looking for exactly the same values I show but you are looking for similar fold differences.  Finally, I providing additional details can be done, but I want to keep the section brief.  Perhaps breaking it out into its own page, distilling the main point down to a few sentences, and linking it is more appropriate for the article. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 09:45, 11 November 2015 (UTC)
 +
 
 +
:::::See what [[wikipedia:reproducibility|reproducibility]] is about. Without exact description of the subject of the experiment (i.e. the card's vendor and model names), it cannot be reproducible. Even then the conclusion would be subjective because 2 cards is not statistically significant sample. The point of citing the external benchmarks above was that you don't necessarily need UHS-I card to achieve better performance than Class 10, as your text was suggesting. Therefore, even the relative difference in the performance of your own 2 cards is meaningless. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 11 November 2015 (UTC)
 +
 
 +
::::::I guess I don't really care about the edits enough to further the discussion here.  I will consider some transition between the iozone bit I wrote, and the link you provided when I get a minute.  I do feel that capturing the delay during system updates is key since that is what alerted me and at least one other user (see the arch arm forum post I linked) to the problem.  It stands to reason that others might have these RPi2/RPi delays on file writes and think that somehow the distro is to blame, or the IO bus is saturated when in fact neither is the cause. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 21:38, 12 November 2015 (UTC)
 +
 
 +
:::::::The key to the interruptions during system updates is the [[Sysctl#Virtual_memory|virtual memory]] options. If you e.g. increase {{ic|vm.dirty_ratio}}, you will get ''less frequent'' interruptions, but obviously they will be longer. This configuration is completely general, only desktop users don't care anymore since the HDDs and SSDs are so damn fast these days... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:29, 14 November 2015 (UTC)
 +
 
 +
== Enable fsck on boot ==
 +
 
 +
My install did not fsck at boot when maximum mount counts was exceeded. /boot/cmdline.txt was mounting root rw. Changing ro to rw made systemd-fsck pick it up.
 +
 
 +
I guess the bootloader does not include an fsck hook like an initrd can. If that is correct than the "default" way to fsck at boot can not work, and users must go for the systemd fsck, which seems to be triggered by mounting root ro.
 +
 
 +
I propose to add this to the paragraph when sending users to the fsck wiki page.
 +
 
 +
[[User:E-type|E-type]] ([[User talk:E-type|talk]]) 17:47, 9 October 2016 (UTC)
 +
 
 +
I think that's true (bootloader that doesn't support a fsck hook).  You might wanna search or post on the Arch ARM bbs to verify the solution you propose if the recommended one and then make the modification.
 +
 
 +
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:01, 9 October 2016 (UTC)

Latest revision as of 20:01, 9 October 2016

Overclocking section

"The overclocked setting for CPU clock applies only when the governor throttles up the CPU, i.e. under load. To query the current frequency of the CPU:"

This is not entirely true. I had tried to post more information and it was edited. This is an overview wiki and it needs to be very concise, I get that. However, the problem is that the Pi kernel now defaults to the 'powersave' governor on boot up as a failsafe for an overclocking failure. After spending an afternoon playing around with minimum and maximum frequency settings I am convinced that the powersave governor is so safe that it ignores any use frequency range and the default factory Pi setting might be hard coded in (maybe a packager could verify that).

Things I noted in my tests with the powersave governor:

  • I set the minimum to the Modest setting in /boot/config and even with a 100% load of several dd commands running at a nice of -19 the overclocking never kicked in even with the processor.
  • There is not really a better way to switch modules at boot time than using userspace systemd tools (and defaulting to a sane frequency in the most desired behavor for an experimental platform). (See this-> [1])
  • The config.txt file on my Pi is incorrect in the comment '## Some over clocking settings, govenor already set to ondemand'

This should possible be noted in the Troubleshooting section? (e.g., cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq never reflects overclock setting even under high load. Make sure the powersave governor is not loaded).

I will file a bug report to have the incorrect comment replaced in config.txt.

—This unsigned comment is by Adsicks (talk) 20:44, 20 August 2014‎. Please sign your posts with ~~~~!

Assuming that the powersave governor does not throttle up the CPU, the note is still accurate. But I can confirm that Arch Linux ARM still uses ondemand as the default governor. -- Lahwaacz (talk) 20:58, 20 August 2014 (UTC)

Benchmarking comments

Alad - I believe these additions offer the layman some guidance when dealing with slow performance inspired by this forum post, not knowing why, and wanting to remedy it. I carefully selected the wording and metrics to avoid any particular brand promotion and to provide not objective but quantitative results that users can use as a point of comparison back to their own systems. How would you propose changing the content to not give, "an objective measure?" Graysky (talk) 22:55, 9 November 2015 (UTC)

I looked over the section again, and the first part (up until ".. for illustrative purposes") does look good - encouraging users to compare their own results, rather than try to make something conclusive for everyone like the old SSD benchmarking article. I'm still unconvinced on the part after. -- Alad (talk) 08:00, 10 November 2015 (UTC)
Well, one hallmark of a correctly designed scientific experiment is results relative to a control. Since there is not reference hardware available to users, I used my own experiences with a "slow" and "fast" card to serve as surrogates for people. I don't know how else to provide a positive control and I respectfully disagree with your assessment of that section. Graysky (talk) 08:51, 10 November 2015 (UTC)
Why is the section on the Raspberry Pi page on ArchWiki? It is neither specific to Rpi nor Arch.
What is the purpose of the section? If people have fast enough card from the beginning, they don't care about the section, and if their card is slow, they don't need to be told how to verify that their card is slow.
As to the scientific accuracy, why do you compare only Class 10 vs. UHS-I? Some more extensive benchmarks show that even Class 6 or 4 can be faster on random write than Class 10 [2], and similarly some Class 10 cards can be faster than UHS-I [3]. Your experiments only shows the results for your particular cards, in a totally unreproducible way without even mentioning the vendor and model names. From what I can tell you're comparing an aged low-end Class 10 card with a brand new high end UHS-I model. Edit: Also, the conditions of the experiment are subjective, because the performance depends on the used filesystem, kernel version and configuration (namely the virtual memory settings). Optimizing performance is not solely about the hardware.
-- Lahwaacz (talk) 14:03, 10 November 2015 (UTC)
the answer to your first question is in the text I wrote. Yes, there is disagreement on the web on the topic to your 2nd point as is the case for many topics on the web. Yes, my results are consistent with my hardware; I also explained this in the text. I disagree with your assessment that what I wrote is "totally unreproducible" for the reasons you cited. I would challenge you to take two different cards of different vintages and show similar differences in the random writes and in a discrete pacman installation as I have done. I suspect you draw similar conclusions. You aren't looking for exactly the same values I show but you are looking for similar fold differences. Finally, I providing additional details can be done, but I want to keep the section brief. Perhaps breaking it out into its own page, distilling the main point down to a few sentences, and linking it is more appropriate for the article. Graysky (talk) 09:45, 11 November 2015 (UTC)
See what reproducibility is about. Without exact description of the subject of the experiment (i.e. the card's vendor and model names), it cannot be reproducible. Even then the conclusion would be subjective because 2 cards is not statistically significant sample. The point of citing the external benchmarks above was that you don't necessarily need UHS-I card to achieve better performance than Class 10, as your text was suggesting. Therefore, even the relative difference in the performance of your own 2 cards is meaningless. -- Lahwaacz (talk) 13:45, 11 November 2015 (UTC)
I guess I don't really care about the edits enough to further the discussion here. I will consider some transition between the iozone bit I wrote, and the link you provided when I get a minute. I do feel that capturing the delay during system updates is key since that is what alerted me and at least one other user (see the arch arm forum post I linked) to the problem. It stands to reason that others might have these RPi2/RPi delays on file writes and think that somehow the distro is to blame, or the IO bus is saturated when in fact neither is the cause. Graysky (talk) 21:38, 12 November 2015 (UTC)
The key to the interruptions during system updates is the virtual memory options. If you e.g. increase vm.dirty_ratio, you will get less frequent interruptions, but obviously they will be longer. This configuration is completely general, only desktop users don't care anymore since the HDDs and SSDs are so damn fast these days... -- Lahwaacz (talk) 12:29, 14 November 2015 (UTC)

Enable fsck on boot

My install did not fsck at boot when maximum mount counts was exceeded. /boot/cmdline.txt was mounting root rw. Changing ro to rw made systemd-fsck pick it up.

I guess the bootloader does not include an fsck hook like an initrd can. If that is correct than the "default" way to fsck at boot can not work, and users must go for the systemd fsck, which seems to be triggered by mounting root ro.

I propose to add this to the paragraph when sending users to the fsck wiki page.

E-type (talk) 17:47, 9 October 2016 (UTC)

I think that's true (bootloader that doesn't support a fsck hook). You might wanna search or post on the Arch ARM bbs to verify the solution you propose if the recommended one and then make the modification.

Graysky (talk) 20:01, 9 October 2016 (UTC)