Talk:Raspberry Pi

From ArchWiki
(Redirected from Talk:Raspberry)
Jump to: navigation, search

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)

I2C section: Add Install and links to packages

Re: My previous edit that was reverted: I propose adding the familiar Install link and links to the packages as follows (instead of native links to the i686/x86_64 I posted before):

   Install the i2c-tools and lm_sensors packages.

After reading the style guide, it seems there isn't much guidance about this situation and I can't find much precedence in similar situations (i.e., other architectures having their own repo), so this seems like the best option. I'll make this edit tomorrow unless I hear any feedback to the contrary. Etskinner (talk) 14:28, 1 April 2017 (UTC)

As this content is now maintained on the ALARM wiki, this article will be archived as indicated by the template. As such, I don't see the point in making these changes. -- Alad (talk) 15:37, 1 April 2017 (UTC)


RE: The archival tag and the response to my first message in discussion section 'I2C...' above.

I think it's a bad idea to rely on the ALARM wiki's page to provide an accessible platform for contributing to a wiki (having to do a git pull request just to contribute to a wiki isn't pragmatic in my opinion, it will discourage people from contributing). See also this discussion on the ARM category page, where the consensus was in line with what I'm saying. There are already several edits to this page since the merge into ALARM's wiki that haven't been reflected there.

As such, I propose that we remove the ArchWiki:Archive tag on this page (while preserving a link/disclaimer to the ALARM wiki article somewhere in the page) and continue contributions to this page as appropriate. Etskinner (talk) 14:33, 4 April 2017 (UTC)

Maintaining information in two places is also not pragmatic and even counterproductive. See also Help:Style#Hypertext_metaphor. If you have an issue with how ALARM manages their wiki, you should bring it up to them - e.g. [4]. -- Alad (talk) 13:07, 10 April 2017 (UTC)
Etskinner: also there has been contact with ALARM meanwhile on the topic, and time invested to sync content before archival. Think also about the new users of the supported devices: they would reasonably expect to find most up-to-date install info in the ALARM wiki. So, contributions there reach audience better. --Indigo (talk) 17:54, 10 April 2017 (UTC)