ac100 team mailing list archive

[Gordan Bobic <gordan@xxxxxxxxxx>]

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
> anymore.

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.

Gordan