← Back to team overview

ac100 team mailing list archive

Re: Stability Under Load


On 08/20/2011 04:47 PM, Julian Andres Klode wrote:
On Sat, Aug 20, 2011 at 04:33:17PM +0100, Gordan Bobic wrote:
On 08/20/2011 04:07 PM, Julian Andres Klode wrote:
On Sat, Aug 20, 2011 at 03:31:56PM +0100, Gordan Bobic wrote:
Which kernel are you using?

A somewhat older build of Marc's kernel (one month), the one
I have in my Debian repository + the change to use 1000 instead
of 1200.

I presume you mean 1200mV rather than 1200MHz. If it's 1200MHz, I'd
like to know where to tweak that. ;)

I never said anything of Hz. It's all mV (if it's mV, what are 1.2V
used for? The voltage from the battery/charger is clearly 10-12V).

Not sure I follow what you mean. 1200mV is 1.2V.

Well, my testing has been going on for 6+ hours. Considering I
couldn't get an hour without errors before (and sometimes
several/hour, and that's just the detected ones), I'd say it's a
very definitive improvement. So much so that I'm vaguely tempted to
try reducing it to 950mV. ;)

Given that the minimum it currently scales to would be 725, 950
is certainly save.

I'll give it a go, see what happens.

While we're at it (questions for you, and my answers to them)
   (a) what cpufreq governor are you using? [performance]

Ondemand, but I haven't seen idle time move from 0.00%. each
instance of pbzip2 should be running 2 threads, and it's all running
in tmpfs. Plus the compiling job in the background for good measure.
It's a fair point, though, I should really be testing with the
performance governor.
But from my experience, scaling things are a bit broken, and you
do not get the same performance with ondemand, as it never really
tries to scale up much.

Well, when I checked with powertop, the CPU was running at 1000MHz 100% of the time, so it can't be that broken.

   (b) do you have battery plugged in? [no]

Yes. Why should this matter?
Don't know. Not enough power from the AC at some periods
or stuff like this?

I would expect the battery to smooth things out and make them better, actually, it should be acting as a huge capacitor and ironing out spikes.

   (c) where is gcc and source located? [btrfs on USB HDD]

All on the SD card, OS on ext4 without a journal, /usr/src
(~/rpmbuild symlinked to /usr/src/rpmbuild) on nilfs2. The iowait
time very rarely moves from 0%, and never exceeds low single figure
% points.

The problem here could also be related to the USB hard disk which
is powered by the AC100, or the btrfs filesystem going crazy from
time to time.

Plausible, but if you were seeing fs corruption, surely you'd have
had bigger problems by now. Why btrfs, BTW?
I'm building Debian packages using sbuild in chroots managed by
schroot where each build runs in its own snapshot of a base chroot,
thus ensuring that the build environment is clean.

I could now use ext4 + aufs, but it would probably be slower than
my btrfs with nodatasum and fsync() disabled. Furthermore, cleanups
would be slower, as its not just a "delete this snapshot" thing

Fair enough. I never liked btrfs much. The time I spent on the btrfs dev mailing list give me the impression that: 1) btrfs isn't entirely stable (but maybe my view is skewed by the fact that last time I was on the mailing list, the reports of data corruption were relatively common) 2) A number of design decisions taken are fundamentally wrong (especially the offline rather than online block deduplication) 3) They devs didn't understand the benefit of having CoW hard-links within a snapshot

After that I cannot imagine myself ever going back to using btrfs. There are much better, specialized alternatives for any use-case I can think of - ext4, nilfs2 and zfs between them cover any use-case I can think of way better than btrfs ever could.