Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210035 > unrolled thread

System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

Back to article view | Back to linux.debian.user

Contents

  System on a chip - performance relative size and setup (how can the  (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-18 14:30 +0200
    Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) songbird <songbird@anthive.com> - 2019-06-18 15:10 +0200
    Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-18 15:20 +0200
    Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Andy Smith <andy@strugglers.net> - 2019-06-18 15:20 +0200
      Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) rhkramer@gmail.com - 2019-06-18 16:10 +0200
        Example of an M2 form factor SSD (was: Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) rhkramer@gmail.com - 2019-06-19 14:30 +0200
          Re: M2 form factor SSD Peter Ehlert <peter@sdi-baja.com> - 2019-06-19 18:10 +0200
      Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-18 17:30 +0200
        Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) rhkramer@gmail.com - 2019-06-18 17:40 +0200
          Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Dan Ritter <dsr@randomstring.org> - 2019-06-18 17:50 +0200
        Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-18 17:50 +0200
          Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-18 18:20 +0200
            Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-18 21:10 +0200
              Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-18 23:20 +0200
                Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Dan Ritter <dsr@randomstring.org> - 2019-06-19 00:00 +0200
                  Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-19 12:00 +0200
                    Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-19 12:30 +0200
                      Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) deloptes <deloptes@gmail.com> - 2019-06-19 12:50 +0200
                        Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-19 13:20 +0200
                          Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-19 13:40 +0200
                            Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-19 14:10 +0200
                              Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-20 09:00 +0200
                                Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-20 09:40 +0200
                    Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Dan Ritter <dsr@randomstring.org> - 2019-06-19 16:00 +0200
                Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-19 00:00 +0200
                Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-19 01:40 +0200
    Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Jochen Spieker <ml@well-adjusted.de> - 2019-06-18 21:50 +0200
    Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) David Christensen <dpchrist@holgerdanske.com> - 2019-06-19 03:40 +0200
      Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-19 04:10 +0200
      Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) deloptes <deloptes@gmail.com> - 2019-06-19 12:50 +0200
        Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) David Christensen <dpchrist@holgerdanske.com> - 2019-06-20 02:20 +0200
      Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-21 09:30 +0200
        Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-21 12:20 +0200
          Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-21 15:10 +0200
            Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Andy Smith <andy@strugglers.net> - 2019-06-22 22:30 +0200
              Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-23 07:50 +0200
                Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-23 08:50 +0200
                  Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-23 15:50 +0200
                    Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Jonas Smedegaard <jonas@jones.dk> - 2019-06-23 17:10 +0200
        Re: System on a chip - performance relative size and setup (how can  the (Debian) setup make a difference?) David Christensen <dpchrist@holgerdanske.com> - 2019-06-22 01:10 +0200
          Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?) Erik Josefsson <erik.hjalmar.josefsson@gmail.com> - 2019-06-22 11:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#210097 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-19 13:38:32)
> On 6/19/19 1:15 PM, Jonas Smedegaard wrote:
> 
> > Quoting deloptes (2019-06-19 12:42:13)
> >> Jonas Smedegaard wrote:
> >>
> >>> In short, you really_really_ want netinstall from MicroSD!
> >> What about debootstrap? IS it possible to use it for that SoC?
> > Certainly.  Debian-installer uses debootstrap internally so that is 
> > a must.  The images Erik has used until now -http://box.redpill.dk/ 
> > - are also built with debootstrap (or rather the more flexible 
> > multistrap) using the framework I referenced in my previous post: 
> > https://salsa.debian.org/tinker-team/box
> >
> > My point in above quote is which_medium_ you want to boot from 
> > initially on a Teres-I: MicroSD rather than USB (not which method of 
> > installation you want).
> >
> > My work specifically explores how to avoid the tedious process of 
> > running debian-installer on the relatively slow Teres-I but 
> > reach_same_ result as if doing so - because in my experience running 
> > debootstrap directly can easily lead to a slightly broken system.
> 
> It is quite possible that my impression that the Ubuntu instance that 
> Teres-I is shipped with is significantly faster than your redpills is 
> just imaginary, but then Dan Ritter seemed to confirm that that 
> "native Ubuntu" probably is 2x to 8x faster.
> 
> If "native Ubuntu" is faster than "SD redpill", then I wonder how the 
> Olimex people got their Ubuntu installed in the first place? They 
> couldn't have used the Debian Installer, could they?
> 
> Or, a better question, is it within reach to run a Debian Pure Blend 
> on Teres-I without an external SD card? If so, is Dan Ritter right 
> that it will be 2x to 8x faster?

Yes, it certainly is within reach, just needs someone to do the 
reaching.

This seems a good starting point for such adventure: 
https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210127 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

On 6/19/19 2:04 PM, Jonas Smedegaard wrote:
>> Or, a better question, is it within reach to run a Debian Pure Blend
>> on Teres-I without an external SD card? If so, is Dan Ritter right
>> that it will be 2x to 8x faster?
> Yes, it certainly is within reach, just needs someone to do the
> reaching.
>
> This seems a good starting point for such adventure:
> https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install
>
Very good!

Indeed, one of the comments to the code on that page says ""In case of 
eMMC it's also possible to transfer the bootloader to eMMC in a single 
step so from then on running without SD card is possible.".

Somehow the Olimex folks managed to make Teres-I run Ubuntu without SD card.

Grateful for advice who to talk to!

Best regards.

//Erik

[toc] | [prev] | [next] | [standalone]

#210132 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-20 08:58:34)
> On 6/19/19 2:04 PM, Jonas Smedegaard wrote:
> >> Or, a better question, is it within reach to run a Debian Pure 
> >> Blend on Teres-I without an external SD card? If so, is Dan Ritter 
> >> right that it will be 2x to 8x faster?
> > Yes, it certainly is within reach, just needs someone to do the 
> > reaching.
> >
> > This seems a good starting point for such adventure: 
> > https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install
> >
> Very good!
> 
> Indeed, one of the comments to the code on that page says ""In case of 
> eMMC it's also possible to transfer the bootloader to eMMC in a single 
> step so from then on running without SD card is possible.".
> 
> Somehow the Olimex folks managed to make Teres-I run Ubuntu without SD 
> card.
> 
> Grateful for advice who to talk to!

The authors of above script: https://forum.armbian.com/

Board makers: https://www.olimex.com/wiki/GTC-FAQ

SoC developers: https://linux-sunxi.org/Category:Community

Happy hacking!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210100 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

Erik Josefsson wrote: 
> Hi Dan,
> 
> On 6/18/19 11:57 PM, Dan Ritter wrote:
> > Nicholas Geovanis wrote:
> > > On Tue, Jun 18, 2019, 4:10 PM Erik Josefsson <
> > > erik.hjalmar.josefsson@gmail.com> wrote:
> > > 
> > > > The Ubuntu version that Teres-I comes with feels almost as good, which is
> > > > why I still don't understand why running Debian from the SD-card doesn't.
> > > > 
> > > Then I would be interested to know which release of Ubuntu and see an
> > > installed package list. But i will hit the websites, no need to post here.
> > He seems to be comparing speed of Ubuntu on an internal eMMC
> > storage (16GB, 8 bit interface) to the speed of Debian on an
> > SD card interface (either 4 bit or 1 bit interface, depending
> > on what they chose).
> > 
> > The eMMC should transfer twice as fast at minimum, and possibly
> > 8x as fast as the SD card.
> 
> I obviously didn't get that memo.
> 
> > -dsr- (I looked at the spec.)
> > 
> You don't happen to see in the spec. which boot key to press to get Teres-I
> to start a netinstall from USB?

Sorry, I was looking at the hardware spec. I don't see any info
on boot sequences.

-dsr-

[toc] | [prev] | [next] | [standalone]

#210077 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 18, 2019, 4:10 PM Erik Josefsson <
erik.hjalmar.josefsson@gmail.com> wrote:

> The Ubuntu version that Teres-I comes with feels almost as good, which is
> why I still don't understand why running Debian from the SD-card doesn't.
>
Then I would be interested to know which release of Ubuntu and see an
installed package list. But i will hit the websites, no need to post here.

>
> //Erik
>

[toc] | [prev] | [next] | [standalone]

#210083 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-18 23:10:03)
> Because PureOS is a Debian Pure Blend, isn't it?

No, PureOS is Debian Blend (one of my main tasks in the company is to 
work on that) but not a Pure Blend: It contains non-Debian parts and 
will likely always due to a core aim of complying with both Debian and 
FSF principles so as long as Debian and FSF disagrees on some marginal 
details PureOS will stay a "non-pure" Debian Blend: 
https://wiki.debian.org/DebianPureBlends#Terminology


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210070 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Erik Josefsson:
> 
> As far as I understand, it is quite recent that SD cards are fast and large
> enough to be able to carry and run an entire Debian instance.

The capacity is not a problem for quite some time, depending on your
space requirements. You can still run a minimal Debian on way less than
1GB. The same is true for the speed. SD cards tend to be used with and
optimized for large(ish) files like photos and videos. Reading and
writing these files should be quite fast, but I would not expect great
performance for random I/O on small files.

> If this is the case, maybe there is only theory available regarding whether
> you can make a computer "run faster" on a 64GB SD card than on a 32GB SD
> card when cards are otherwise identical.

I don't know.

> I don't really know how swap works on a standard computer, even less how it
> works when the whole computer runs from/on a SD card.

The same as with other storage. Swap means using persistent, slow and
cheap storage as RAM. It is exactly that, cheap and painfully slow.
Under normal circumstances you should avoid swapping like the plague.
(Yes, the Linux kernel tends to make use of swap in the background "just
in case". It does not need necessarily to worry you if free(1) or top(1)
report swap usage.)

> Swap is supposed to be make your computer pretend that you have more RAM
> than it actually has, but if the whole computer is running from/on RAM (or
> is it?), then what does swap mean?

What do you mean, running from RAM? I do not see a connection of this
sentence with your previous questions about SD cards. In any case,
swapping to SD card may be even worse than swapping to traditional hard
disks.

> On Teres-I with redpill RC2 (now there is a RC3 that I have not yet
> installed) an unfortunate website with pop up commercials (like dn.se) can
> eat all performance there is and freeze the mouse for hours. I would guess
> that could have been fixed on a normal computer with "more RAM", i.e., "more
> swap"? But is the same true for e.g. Teres-I?

I don't know that hardware except for what I was able to google quickly.
But "more RAM" and "more swap" are very different things. Swap does not
help your computer to perform better. It helps your computer to do
things very, very slowly that it otherwise would not be able to do at
all.

> Second question is if it is meaningful to buy a "super duper blazing fast"
> SD card for the task to run a whole Debian system?
> 
> There is a very expensive 64GB SD card from SanDisk that is called Extreme
> Pro that costs twice as much as same size Extreme Plus. Specs say it is
> "super duper blazing fast" for video in "Ultra HD 4K", but would Pro also be
> faster than Plus for the task of running Thunderbird and Firefox at the same
> time?

Not necessarily. I would try to look for benchmarks that also test
random I/O. Also, it sounds more like your system is memory-constrained
and even the fastest SD cards will not help you with that, see above.

J.
-- 
I think the environment will be okay.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

[toc] | [prev] | [next] | [standalone]

#210084 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

On 6/18/19 5:26 AM, Erik Josefsson wrote:
> This is another quite open question that I probably could research 
> myself, if I had the time.
> 
> As far as I understand, it is quite recent that SD cards are fast and 
> large enough to be able to carry and run an entire Debian instance.
> 
> If this is the case, maybe there is only theory available regarding 
> whether you can make a computer "run faster" on a 64GB SD card than on a 
> 32GB SD card when cards are otherwise identical.
> 
> I don't really know how swap works on a standard computer, even less how 
> it works when the whole computer runs from/on a SD card.
> 
> Swap is supposed to be make your computer pretend that you have more RAM 
> than it actually has, but if the whole computer is running from/on RAM 
> (or is it?), then what does swap mean?
> 
> On Teres-I with redpill RC2 (now there is a RC3 that I have not yet 
> installed) an unfortunate website with pop up commercials (like dn.se) 
> can eat all performance there is and freeze the mouse for hours. I would 
> guess that could have been fixed on a normal computer with "more RAM", 
> i.e., "more swap"? But is the same true for e.g. Teres-I?
> 
> 
> Second question is if it is meaningful to buy a "super duper blazing 
> fast" SD card for the task to run a whole Debian system?
> 
> There is a very expensive 64GB SD card from SanDisk that is called 
> Extreme Pro that costs twice as much as same size Extreme Plus. Specs 
> say it is "super duper blazing fast" for video in "Ultra HD 4K", but 
> would Pro also be faster than Plus for the task of running Thunderbird 
> and Firefox at the same time?
> 
> 
> Best regards.
> 
> //Erik


The best way to answer your question regarding performance of a size N 
SD card vs. a size 2*N SD card is to buy two cards and benchmark them 
using your workload.  Please publish your findings.


I have considered installing and running Debian on SD cards.  At this 
point, I would probably choose a "high endurance" device rather than a 
"fast' device, because I want the system to last.  (The few solid-state 
device failures I have seen all followed the same pattern:  working to 
non-working, with no warning and little or no recovery.  At least one 
included the smell of roasting electronics; e.g. "let the smoke out".)


I have tried running machines without swap, but found that they crashed. 
  Now I always include a 1 GB swap partition when installing.


I have run Debian on USB flash drives 24x7 in headless servers and in 
desktops, but cheap used SSD's are better.  (That said, a USB flash 
drive install is invaluable for trouble-shooting and maintenance.)


"Run from RAM" means "Live CD".  I created my own Debian-based live CD 
in the past.  I believe the starting point was here:

     https://wiki.debian.org/DebianLive


If the Teres-I is a "Do It Yourself Open Source Hardware and Software 
Hacker's friendly Modular Laptop", where are the downloads?

     https://www.olimex.com/Products/DIY-Laptop/


David

[toc] | [prev] | [next] | [standalone]

#210085 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting David Christensen (2019-06-19 03:38:56)
> On 6/18/19 5:26 AM, Erik Josefsson wrote: If the Teres-I is a "Do It 
> Yourself Open Source Hardware and Software Hacker's friendly Modular 
> Laptop", where are the downloads?
> 
>      https://www.olimex.com/Products/DIY-Laptop/

Olimex Armbian-based downloads are documented 2 levels deeper (follow 
"Kits" in the menu): 
https://www.olimex.com/Products/DIY-Laptop/KITS/TERES-A64-BLACK/open-source-hardware 
https://www.olimex.com/Products/DIY-Laptop/KITS/TERES-A64-WHITE/open-source-hardware

My alternative Debian-based images are at http://box.redpill.dk/


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210093 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

David Christensen wrote:

> I have considered installing and running Debian on SD cards.  At this
> point, I would probably choose a "high endurance" device rather than a
> "fast' device, because I want the system to last.  (The few solid-state
> device failures I have seen all followed the same pattern:  working to
> non-working, with no warning and little or no recovery.  At least one
> included the smell of roasting electronics; e.g. "let the smoke out".)
> 

CF cards are much better but also more expensive. 
No electronic device is meant to work forever - disaster recovery should be
always considered.

Depends on how your setup looks like, typically Debian is <4GB. I have
installations from 450MB to 2GB.

> 
> I have tried running machines without swap, but found that they crashed.
> Now I always include a 1 GB swap partition when installing.

why not using swap (if disk space is available) disk space is cheap.

regards

[toc] | [prev] | [next] | [standalone]

#210119 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

On 6/19/19 3:40 AM, deloptes wrote:
> David Christensen wrote:
>> I have tried running machines without swap, but found that they crashed.
>> Now I always include a 1 GB swap partition when installing.
> 
> why not using swap (if disk space is available) disk space is cheap.

I built systems on USB flash drives without swap to reduce wear on the 
USB flash drive and to see if they worked.


David

[toc] | [prev] | [next] | [standalone]

#210179 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Hi David,

On 6/19/19 3:38 AM, David Christensen wrote:
>
> The best way to answer your question regarding performance of a size N 
> SD card vs. a size 2*N SD card is to buy two cards and benchmark them 
> using your workload.  Please publish your findings.

Please find my four (4) findings below or at 
http://paste.debian.net/1088723

The only benchmark I know how to use is flashbench. But unfortunately I 
don't know how to interpret the resulting data.

I would be immensely grateful for advise on which of the 4 cards to use.

The testing was simple. I have downloaded and put the same copy of the 
redpill RC3 image from http://box.redpill.dk/nonfree/ onto each SD card, 
then I have followed the instructions. Each card now has an "Extended 
system" created by the command box-add-gui on the same machine.

Then I have installed aptitude, run update and upgrade and autoclean, 
and then installed and run flashbench with parameters: flashbench -a 
/dev/mmcblk0 --blocksize=1024

The four cards are:

MicroSD SanDisk Extreme PRO  64GB  [3]  XC II
MicroSD SanDisk Extreme PLUS  64GB  [3]  XC I  V30  A2
MicroSD SanDisk Extreme PLUS  32GB  [3]  HC I  V30  A1
MicroSD SanDisk Ultra  32GB  [1]  HC I  (10)  A1

I can send a picture of the cards off list if this is unclear.

So the question is, which card should I use for Teres-I ?

If there are further benchmarks or tests that could help determine which 
SD card is the best, I'd be happy to run them.

Best regards.

//Erik

MicroSD SanDisk Extreme PRO  64GB  [3]  XC II
debian@box:~$ sudo flashbench -a /dev/mmcblk0 --blocksize=1024
align 17179869184	pre 515µs	on 809µs	post 452µs	diff 325µs
align 8589934592	pre 515µs	on 736µs	post 427µs	diff 265µs
align 4294967296	pre 537µs	on 823µs	post 460µs	diff 325µs
align 2147483648	pre 545µs	on 893µs	post 471µs	diff 385µs
align 1073741824	pre 517µs	on 749µs	post 434µs	diff 274µs
align 536870912	pre 526µs	on 763µs	post 445µs	diff 277µs
align 268435456	pre 527µs	on 769µs	post 448µs	diff 282µs
align 134217728	pre 540µs	on 820µs	post 446µs	diff 327µs
align 67108864	pre 514µs	on 754µs	post 449µs	diff 273µs
align 33554432	pre 506µs	on 722µs	post 417µs	diff 261µs
align 16777216	pre 539µs	on 660µs	post 460µs	diff 160µs
align 8388608	pre 539µs	on 670µs	post 458µs	diff 171µs
align 4194304	pre 541µs	on 669µs	post 466µs	diff 165µs
align 2097152	pre 547µs	on 649µs	post 463µs	diff 144µs
align 1048576	pre 544µs	on 639µs	post 458µs	diff 138µs
align 524288	pre 545µs	on 658µs	post 460µs	diff 155µs
align 262144	pre 545µs	on 655µs	post 460µs	diff 152µs
align 131072	pre 540µs	on 620µs	post 455µs	diff 122µs
align 65536	pre 541µs	on 624µs	post 458µs	diff 125µs
align 32768	pre 538µs	on 622µs	post 461µs	diff 122µs
align 16384	pre 478µs	on 633µs	post 457µs	diff 165µs
align 8192	pre 501µs	on 516µs	post 480µs	diff 25.7µs
align 4096	pre 509µs	on 528µs	post 465µs	diff 41.2µs
align 2048	pre 514µs	on 538µs	post 508µs	diff 27.6µs


MicroSD SanDisk Extreme PLUS  64GB  [3]  XC I  V30  A2
debian@box:~$ sudo flashbench -a /dev/mmcblk0 --blocksize=1024
align 17179869184	pre 567µs	on 603µs	post 494µs	diff 72.6µs
align 8589934592	pre 557µs	on 583µs	post 442µs	diff 83.9µs
align 4294967296	pre 689µs	on 784µs	post 564µs	diff 157µs
align 2147483648	pre 654µs	on 726µs	post 593µs	diff 103µs
align 1073741824	pre 579µs	on 638µs	post 522µs	diff 87.7µs
align 536870912	pre 570µs	on 652µs	post 529µs	diff 102µs
align 268435456	pre 524µs	on 564µs	post 500µs	diff 52.5µs
align 134217728	pre 654µs	on 730µs	post 616µs	diff 95.3µs
align 67108864	pre 664µs	on 728µs	post 600µs	diff 96.3µs
align 33554432	pre 576µs	on 637µs	post 530µs	diff 84.1µs
align 16777216	pre 628µs	on 694µs	post 568µs	diff 95.9µs
align 8388608	pre 594µs	on 654µs	post 567µs	diff 73.6µs
align 4194304	pre 628µs	on 680µs	post 580µs	diff 76µs
align 2097152	pre 576µs	on 602µs	post 562µs	diff 33.5µs
align 1048576	pre 578µs	on 577µs	post 572µs	diff 2.21µs
align 524288	pre 585µs	on 585µs	post 578µs	diff 3.55µs
align 262144	pre 587µs	on 592µs	post 584µs	diff 6.52µs
align 131072	pre 616µs	on 636µs	post 613µs	diff 21.4µs
align 65536	pre 594µs	on 586µs	post 596µs	diff -8963ns
align 32768	pre 636µs	on 695µs	post 587µs	diff 83.6µs
align 16384	pre 548µs	on 551µs	post 550µs	diff 2.51µs
align 8192	pre 551µs	on 555µs	post 546µs	diff 6.74µs
align 4096	pre 579µs	on 604µs	post 547µs	diff 40.7µs
align 2048	pre 586µs	on 579µs	post 586µs	diff -6480ns

MicroSD SanDisk Extreme PLUS  32GB  [3]  HC I  V30  A1
debian@box:~$ sudo flashbench -a /dev/mmcblk0 --blocksize=1024
align 8589934592	pre 329µs	on 367µs	post 302µs	diff 51.3µs
align 4294967296	pre 360µs	on 407µs	post 304µs	diff 74.6µs
align 2147483648	pre 344µs	on 370µs	post 322µs	diff 36.8µs
align 1073741824	pre 408µs	on 455µs	post 409µs	diff 46.5µs
align 536870912	pre 436µs	on 486µs	post 411µs	diff 62.6µs
align 268435456	pre 428µs	on 449µs	post 402µs	diff 34.2µs
align 134217728	pre 417µs	on 452µs	post 392µs	diff 47.7µs
align 67108864	pre 433µs	on 481µs	post 414µs	diff 57.6µs
align 33554432	pre 307µs	on 345µs	post 318µs	diff 32µs
align 16777216	pre 359µs	on 381µs	post 303µs	diff 50.5µs
align 8388608	pre 360µs	on 398µs	post 316µs	diff 59.8µs
align 4194304	pre 352µs	on 391µs	post 300µs	diff 64.8µs
align 2097152	pre 316µs	on 315µs	post 317µs	diff -1358ns
align 1048576	pre 322µs	on 323µs	post 320µs	diff 1.96µs
align 524288	pre 325µs	on 334µs	post 325µs	diff 9.38µs
align 262144	pre 326µs	on 327µs	post 326µs	diff 443ns
align 131072	pre 328µs	on 343µs	post 325µs	diff 16.1µs
align 65536	pre 307µs	on 306µs	post 306µs	diff -688ns
align 32768	pre 315µs	on 314µs	post 316µs	diff -1308ns
align 16384	pre 328µs	on 331µs	post 326µs	diff 3.87µs
align 8192	pre 306µs	on 304µs	post 308µs	diff -2568ns
align 4096	pre 303µs	on 324µs	post 307µs	diff 19.5µs
align 2048	pre 309µs	on 309µs	post 311µs	diff -1260ns

MicroSD SanDisk Ultra  32GB  [1]  HC I  (10)  A1
debian@box:~$ sudo flashbench -a /dev/mmcblk0 --blocksize=1024
align 8589934592	pre 351µs	on 380µs	post 317µs	diff 46.3µs
align 4294967296	pre 368µs	on 399µs	post 316µs	diff 57.4µs
align 2147483648	pre 358µs	on 383µs	post 347µs	diff 30µs
align 1073741824	pre 409µs	on 454µs	post 403µs	diff 47.9µs
align 536870912	pre 360µs	on 395µs	post 360µs	diff 35.2µs
align 268435456	pre 408µs	on 447µs	post 378µs	diff 53.6µs
align 134217728	pre 366µs	on 391µs	post 358µs	diff 28.5µs
align 67108864	pre 474µs	on 512µs	post 451µs	diff 49.3µs
align 33554432	pre 344µs	on 370µs	post 338µs	diff 28.6µs
align 16777216	pre 383µs	on 410µs	post 342µs	diff 47.3µs
align 8388608	pre 378µs	on 407µs	post 339µs	diff 48.5µs
align 4194304	pre 380µs	on 401µs	post 349µs	diff 36.8µs
align 2097152	pre 367µs	on 368µs	post 356µs	diff 6.37µs
align 1048576	pre 375µs	on 374µs	post 362µs	diff 5.4µs
align 524288	pre 380µs	on 393µs	post 365µs	diff 20.6µs
align 262144	pre 379µs	on 380µs	post 369µs	diff 6.17µs
align 131072	pre 382µs	on 382µs	post 371µs	diff 5.39µs
align 65536	pre 382µs	on 380µs	post 371µs	diff 3.25µs
align 32768	pre 384µs	on 383µs	post 369µs	diff 6.38µs
align 16384	pre 375µs	on 374µs	post 373µs	diff 387ns
align 8192	pre 372µs	on 374µs	post 374µs	diff 456ns
align 4096	pre 379µs	on 391µs	post 375µs	diff 14.3µs
align 2048	pre 382µs	on 383µs	post 379µs	diff 2.12µs

[toc] | [prev] | [next] | [standalone]

#210184 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-21 09:28:38)
> On 6/19/19 3:38 AM, David Christensen wrote:
>> The best way to answer your question regarding performance of a size 
>> N SD card vs. a size 2*N SD card is to buy two cards and benchmark 
>> them using your workload.  Please publish your findings.
>
> Please find my four (4) findings below or at 
> http://paste.debian.net/1088723
>
> The only benchmark I know how to use is flashbench. But unfortunately 
> I don't know how to interpret the resulting data.

flashbench is for benchmarking page/erase-blocks/allocation-group (not 
transfer speed).

My tool to generate images supports custom-aligned since April 28: 
https://salsa.debian.org/tinker-team/box/commit/be07a3a1b0

Above git commit includes links to some notes on the topic:

https://wiki.gentoo.org/wiki/SDCard#Solution_2:_Tuned_ext4
https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/
https://lists.linaro.org/pipermail/flashbench-results/2014-July/000479.html


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210190 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

On 6/21/19 12:17 PM, Jonas Smedegaard wrote:
> Quoting Erik Josefsson (2019-06-21 09:28:38)
>> On 6/19/19 3:38 AM, David Christensen wrote:
>>> The best way to answer your question regarding performance of a size
>>> N SD card vs. a size 2*N SD card is to buy two cards and benchmark
>>> them using your workload.  Please publish your findings.
>> Please find my four (4) findings below or at
>> http://paste.debian.net/1088723
>>
>> The only benchmark I know how to use is flashbench. But unfortunately
>> I don't know how to interpret the resulting data.
> flashbench is for benchmarking page/erase-blocks/allocation-group (not
> transfer speed).
>
> My tool to generate images supports custom-aligned since April 28:
> https://salsa.debian.org/tinker-team/box/commit/be07a3a1b0-I

That's great, but granted all 4 cards are optimized by your scripts, the 
question is if flashbench can tell me which one to pick?

All of them work fine, but I want to spend time with the one that is 
best for "my workload", as suggested by David Christensen earlier in the 
thread.

Maybe flashbench cannot tell me anything about that anyway?

Are there other tools?

//Erik

[toc] | [prev] | [next] | [standalone]

#210263 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

Hi Erik,

On Fri, Jun 21, 2019 at 03:02:46PM +0200, Erik Josefsson wrote:
> Maybe flashbench cannot tell me anything about that anyway?
> 
> Are there other tools?

I'm not familiar with flashbench. I like fio. It's available in
Debian.

I like to do the following tests. Example fio command line follows
for each.

- sequential read speed (MB/sec)

    $ fio --name="seqread" \
          --filename="/mnt/fioscratch" \
          --ioengine=libaio \
          --readwrite=read \
          --direct=1 \
          --numjobs=2 \
          --bs=4k \
          --iodepth=4 \
          --size=1g \
          --runtime=300s \
          --gtod_reduce=1 \
          --group_reporting | tee -a /home/$USER/fio.txt

- sequential write speed (MB/sec)

    $ fio --name="seqwrite" \
          --filename="/mnt/fioscratch" \
          --ioengine=libaio \
          --readwrite=write \
          --direct=1 \
          --numjobs=2 \
          --bs=4k \
          --iodepth=4 \
          --size=1g \
          --runtime=300s \
          --gtod_reduce=1 \
          --group_reporting | tee -a /home/$USER/fio.txt

- random 4KiB reads (IOPS)

    $ fio --name="randread" \
          --filename="/mnt/fioscratch" \
          --ioengine=libaio \
          --readwrite=randread \
          --direct=1 \
          --numjobs=2 \
          --bs=4k \
          --iodepth=4 \
          --size=1g \
          --runtime=300s \
          --gtod_reduce=1 \
          --group_reporting | tee -a /home/$USER/fio.txt

- random 4KiB writes (IOPS)

    $ fio --name="randread" \
          --filename="/mnt/fioscratch" \
          --ioengine=libaio \
          --readwrite=randwrite \
          --direct=1 \
          --numjobs=2 \
          --bs=4k \
          --iodepth=4 \
          --size=1g \
          --runtime=300s \
          --gtod_reduce=1 \
          --group_reporting | tee -a /home/$USER/fio.txt

Explanation:

name: Identifies the block of test output in the results output
      file.

filename: This file will be written out and then read from or
          written to. So your test device needs to be mounted on
          /mnt first. As long as your user has write access there,
          fio does not need to be run as root.

readwrite: Sets the mis of reads and writes and whether they are
           sequential or random.

direct: Use direct IO, bypassing Linux's page cache. If you don't
        use this, you'll only be testing Linux's cache which would
        distort results since you're only testing 1GiB of data which
        could well fit entirely within your RAM. Note that many
        storage devices have their own cache, but this probably
        isn't relevant for your case.

numjobs: Spawn two processes each of which will be doing the same
         thing at once.

bs: Use 4KiB sized IOs. If you can benchark your real application
    you may find it uses different-sized IOs, but if you don't know
    then 4KiB is a reasonable start.

iodepth: Each process will issue 4 IOs at once, rather than issuing
         one and then waiting for it to complete.

size/runtime: The tests will read or write 1GiB of data but there is
              also a time limit of 5 minutes and if that runs out
              first then the test will stop. I don't think you need
              to do many hours of testing here. After 5 minutes I
              should think the card will be showing its reasonable
              performance.

gtod_reduce: Don't do some tests that require the gettimeofday
             system call. Without this, fio can spend a lot of its
             CPU time calling that system call instead of
             benchmarking, and you rarely require the info it gives
             back anyway. Run without this option once to see if you
             really require it.

group_reporting: Aggregate results from all jobs (processes) within
                 the test.

| tee -a …: Output the results both to the screen and append to a
            file in your home directory.

Of those figures, I consider the random ones more important in most
configurations. i.e. if I had to choose between a device that
supported a bit higher sequential read/write but much lower random
read/write, I'd rather have the random read/write, because that
tends to have more impact on interactive usage than sequential.

SD cards tend to have poor random IO speed so I would never use one
for general purpose computing if I could use an HDD or SSD instead.

To give you some idea of what decent SSDs manage:

    http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be-the-best-performer-but-i-dont-know-why/

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#210280 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

Hi Andy, thanks for taking time and for your advise!

On 6/22/19 10:22 PM, Andy Smith wrote:
> Hi Erik,
>
> On Fri, Jun 21, 2019 at 03:02:46PM +0200, Erik Josefsson wrote:
>> Maybe flashbench cannot tell me anything about that anyway?
>>
>> Are there other tools?
> I'm not familiar with flashbench. I like fio. It's available in
> Debian.
>
> I like to do the following tests. Example fio command line follows
> for each.
>
> - sequential read speed (MB/sec)
>
>      $ fio --name="seqread" \
>            --filename="/mnt/fioscratch" \
>            --ioengine=libaio \
>            --readwrite=read \
>            --direct=1 \
>            --numjobs=2 \
>            --bs=4k \
>            --iodepth=4 \
>            --size=1g \
>            --runtime=300s \
>            --gtod_reduce=1 \
>            --group_reporting | tee -a /home/$USER/fio.txt
>
> - sequential write speed (MB/sec)
>
>      $ fio --name="seqwrite" \
>            --filename="/mnt/fioscratch" \
>            --ioengine=libaio \
>            --readwrite=write \
>            --direct=1 \
>            --numjobs=2 \
>            --bs=4k \
>            --iodepth=4 \
>            --size=1g \
>            --runtime=300s \
>            --gtod_reduce=1 \
>            --group_reporting | tee -a /home/$USER/fio.txt
>
> - random 4KiB reads (IOPS)
>
>      $ fio --name="randread" \
>            --filename="/mnt/fioscratch" \
>            --ioengine=libaio \
>            --readwrite=randread \
>            --direct=1 \
>            --numjobs=2 \
>            --bs=4k \
>            --iodepth=4 \
>            --size=1g \
>            --runtime=300s \
>            --gtod_reduce=1 \
>            --group_reporting | tee -a /home/$USER/fio.txt
>
> - random 4KiB writes (IOPS)
>
>      $ fio --name="randread" \
>            --filename="/mnt/fioscratch" \
>            --ioengine=libaio \
>            --readwrite=randwrite \
>            --direct=1 \
>            --numjobs=2 \
>            --bs=4k \
>            --iodepth=4 \
>            --size=1g \
>            --runtime=300s \
>            --gtod_reduce=1 \
>            --group_reporting | tee -a /home/$USER/fio.txt
>
> Explanation:
>
> name: Identifies the block of test output in the results output
>        file.
>
> filename: This file will be written out and then read from or
>            written to. So your test device needs to be mounted on
>            /mnt first.


Teres-I has one MicroSD slot, one HDMI and two USB ports.

Is it meaningful to test the SD cards with an USB-adapter? (the MicroSD 
slot would be occupied by the SD card the machine is running from/on)


>   As long as your user has write access there,
>            fio does not need to be run as root.
>
> readwrite: Sets the mis of reads and writes and whether they are
>             sequential or random.
>
> direct: Use direct IO, bypassing Linux's page cache. If you don't
>          use this, you'll only be testing Linux's cache which would
>          distort results since you're only testing 1GiB of data which
>          could well fit entirely within your RAM. Note that many
>          storage devices have their own cache, but this probably
>          isn't relevant for your case.
>
> numjobs: Spawn two processes each of which will be doing the same
>           thing at once.
>
> bs: Use 4KiB sized IOs. If you can benchark your real application
>      you may find it uses different-sized IOs, but if you don't know
>      then 4KiB is a reasonable start.
>
> iodepth: Each process will issue 4 IOs at once, rather than issuing
>           one and then waiting for it to complete.
>
> size/runtime: The tests will read or write 1GiB of data but there is
>                also a time limit of 5 minutes and if that runs out
>                first then the test will stop. I don't think you need
>                to do many hours of testing here. After 5 minutes I
>                should think the card will be showing its reasonable
>                performance.
>
> gtod_reduce: Don't do some tests that require the gettimeofday
>               system call. Without this, fio can spend a lot of its
>               CPU time calling that system call instead of
>               benchmarking, and you rarely require the info it gives
>               back anyway. Run without this option once to see if you
>               really require it.
>
> group_reporting: Aggregate results from all jobs (processes) within
>                   the test.
>
> | tee -a …: Output the results both to the screen and append to a
>              file in your home directory.
>
> Of those figures, I consider the random ones more important in most
> configurations. i.e. if I had to choose between a device that
> supported a bit higher sequential read/write but much lower random
> read/write, I'd rather have the random read/write, because that
> tends to have more impact on interactive usage than sequential.

Yes, going back and forth between Thunderbird and Firefox while copying 
text snippets from one app to the other sometimes ends in a mouse 
pointer freeze.

That's basically what I do most of the time...


>
> SD cards tend to have poor random IO speed so I would never use one
> for general purpose computing if I could use an HDD or SSD instead.


If random IO speed most likely is the real bottle neck, do you know of 
any particular brand/label/kind/category of MicroSD card that is 
significantly better than others in that regard?

Not sure if chasing some microseconds of better performance will make a 
difference, but if it is anything like parking with a heavy truck with 
heavy trailer in a small parking lot with other cars, then I guess a 
microsecond extra is just as important as an extra centimeter :-)


>
> To give you some idea of what decent SSDs manage:
>
>      http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be-the-best-performer-but-i-dont-know-why/
>

I don't think I can make Teres-I boot from an external SSD.


> Cheers,
> Andy

Thanks Andy!

//Erik

[toc] | [prev] | [next] | [standalone]

#210282 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-23 07:42:24)
> Hi Andy, thanks for taking time and for your advise!
> 
> On 6/22/19 10:22 PM, Andy Smith wrote:
> > Hi Erik,
> >
> > On Fri, Jun 21, 2019 at 03:02:46PM +0200, Erik Josefsson wrote:
> >> Maybe flashbench cannot tell me anything about that anyway?
> >>
> >> Are there other tools?
> > I'm not familiar with flashbench. I like fio. It's available in
> > Debian.
> >
> > I like to do the following tests. Example fio command line follows
> > for each.

[ details snipped]

> Teres-I has one MicroSD slot, one HDMI and two USB ports.
> 
> Is it meaningful to test the SD cards with an USB-adapter? (the MicroSD 
> slot would be occupied by the SD card the machine is running from/on)

Testing SD cards on a different controller may help understand 
_potential_ features of cards, but not _actual_ reachable potentials.

If you prefer an analogy: Reading in a magazine that some Formel-1 
driver can cut a corner while driving 60km/h in same model car as yours 
does not mean that you can expect to cut that same corner at that speed: 
Depends not only on the vehicle (disk device) but also on the driver!


> > Of those figures, I consider the random ones more important in most 
> > configurations. i.e. if I had to choose between a device that 
> > supported a bit higher sequential read/write but much lower random 
> > read/write, I'd rather have the random read/write, because that 
> > tends to have more impact on interactive usage than sequential.
> 
> Yes, going back and forth between Thunderbird and Firefox while 
> copying text snippets from one app to the other sometimes ends in a 
> mouse pointer freeze.
> 
> That's basically what I do most of the time...

Biggest speed gain (on a limited computer like Teres-I) is likely had 
with changing to less ressource hungry tools.

Instead of Firefox try GNOME Web (apt install epiphany-browser).  It 
uses the rendering engine "Webkit" so is likely to handle most websites. 
For an radically lighter browser rendering fewer real-world websites 
properly and with an arguably less friendly user interface, try Surf.

A lighter alternative with ok UI and somewhat decent rendering engine is 
Netsurf, but unfortunately that one won't make it into Debian Buster.

Instead of Thunderbird try Balsa or Claws Mail.


> > SD cards tend to have poor random IO speed so I would never use one
> > for general purpose computing if I could use an HDD or SSD instead.
> 
> 
> If random IO speed most likely is the real bottle neck, do you know of 
> any particular brand/label/kind/category of MicroSD card that is 
> significantly better than others in that regard?

https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md

(this is perhaps 5th time I share that link with you; 2nd on this list)


> Not sure if chasing some microseconds of better performance will make 
> a difference, but if it is anything like parking with a heavy truck 
> with heavy trailer in a small parking lot with other cars, then I 
> guess a microsecond extra is just as important as an extra centimeter 
> :-)
> 
> 
> >
> > To give you some idea of what decent SSDs manage:
> >
> >      http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be-the-best-performer-but-i-dont-know-why/
> >
> 
> I don't think I can make Teres-I boot from an external SSD.

Through the USB2 interface you can.  Won't reach the full potentials of 
SSD (see Formel-1 analogy above) but may still beat SD-cards.

You cannot _boot_ via USB2 interface but you can store your data there 
which helps some scenarios (e.g. possibly helps Firefox hanging, as that 
might be due to its working on cache data below your $HOME.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210298 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

On 6/23/19 8:40 AM, Jonas Smedegaard wrote:

>> Is it meaningful to test the SD cards with an USB-adapter? (the MicroSD
>> slot would be occupied by the SD card the machine is running from/on)
> Testing SD cards on a different controller may help understand
> _potential_  features of cards, but not_actual_  reachable potentials.
>
> If you prefer an analogy: Reading in a magazine that some Formel-1
> driver can cut a corner while driving 60km/h in same model car as yours
> does not mean that you can expect to cut that same corner at that speed:
> Depends not only on the vehicle (disk device) but also on the driver!


Sure. I have tried to drive the 4 cards along exactly the same path 
(i.e. flashbench) to reduce my influence on the performance. 
Unfortunately I cannot tell which one is the best from the resulting data.

If the fio benchmark can tell me which card is the best, I will try it 
at some point.

>
>
>>> Of those figures, I consider the random ones more important in most
>>> configurations. i.e. if I had to choose between a device that
>>> supported a bit higher sequential read/write but much lower random
>>> read/write, I'd rather have the random read/write, because that
>>> tends to have more impact on interactive usage than sequential.
>> Yes, going back and forth between Thunderbird and Firefox while
>> copying text snippets from one app to the other sometimes ends in a
>> mouse pointer freeze.
>>
>> That's basically what I do most of the time...
> Biggest speed gain (on a limited computer like Teres-I) is likely had
> with changing to less ressource hungry tools.
>
> Instead of Firefox try GNOME Web (apt install epiphany-browser).  It
> uses the rendering engine "Webkit" so is likely to handle most websites.
> For an radically lighter browser rendering fewer real-world websites
> properly and with an arguably less friendly user interface, try Surf.


This is very helpful. I have installed epiphany now. Thanks!

>
> A lighter alternative with ok UI and somewhat decent rendering engine is
> Netsurf, but unfortunately that one won't make it into Debian Buster.
>
> Instead of Thunderbird try Balsa or Claws Mail.


OK. Thanks!


>
>
>>> SD cards tend to have poor random IO speed so I would never use one
>>> for general purpose computing if I could use an HDD or SSD instead.
>> If random IO speed most likely is the real bottle neck, do you know of
>> any particular brand/label/kind/category of MicroSD card that is
>> significantly better than others in that regard?
> https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md
>
> (this is perhaps 5th time I share that link with you; 2nd on this list)
>

The article by Thomas Kaiser ends with an open discussion that you can 
probably just as well buy A1 cards made before 2017. The last card I 
bought is neither A1 or A2 but marked with a XC II logo. That particular 
markup is not mentioned in Kaiser's article.

So the article cannot tell me which of my 4 cards is likely to be the 
best for my usecase:

MicroSD SanDisk Extreme PRO  64GB  [3]  XC II
MicroSD SanDisk Extreme PLUS  64GB  [3]  XC I  V30  A2
MicroSD SanDisk Extreme PLUS  32GB  [3]  HC I  V30  A1
MicroSD SanDisk Ultra  32GB  [1]  HC I  (10)  A1


>> Not sure if chasing some microseconds of better performance will make
>> a difference, but if it is anything like parking with a heavy truck
>> with heavy trailer in a small parking lot with other cars, then I
>> guess a microsecond extra is just as important as an extra centimeter
>> :-)
>>
>>
>>> To give you some idea of what decent SSDs manage:
>>>
>>>       http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be-the-best-performer-but-i-dont-know-why/
>>>
>> I don't think I can make Teres-I boot from an external SSD.
> Through the USB2 interface you can.  Won't reach the full potentials of
> SSD (see Formel-1 analogy above) but may still beat SD-cards.
>
> You cannot_boot_  via USB2 interface but you can store your data there
> which helps some scenarios (e.g. possibly helps Firefox hanging, as that
> might be due to its working on cache data below your $HOME.


Ahh.. there's another hint! For some applications, disk partition matters?

I hope there is no downside to having two browsers installed, as long as 
you don't use them at the same time!

Best regards.

//Erik

[toc] | [prev] | [next] | [standalone]

#210302 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

[Multipart message — attachments visible in raw view] — view raw

Quoting Erik Josefsson (2019-06-23 15:42:05)
> On 6/23/19 8:40 AM, Jonas Smedegaard wrote:
> >> If random IO speed most likely is the real bottle neck, do you know 
> >> of any particular brand/label/kind/category of MicroSD card that is 
> >> significantly better than others in that regard?
> > https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md
> >
> > (this is perhaps 5th time I share that link with you; 2nd on this 
> > list)
> 
> The article by Thomas Kaiser ends with an open discussion that you can 
> probably just as well buy A1 cards made before 2017.

You call a section labeled "TODO" an open discussion?  Oh well.


> The last card I bought is neither A1 or A2 but marked with a XC II 
> logo. That particular markup is not mentioned in Kaiser's article.

Maybe because the text is about A1/A2 classification, only briefly 
linking to the historic thread covering lesser relevant cards.


> So the article cannot tell me which of my 4 cards is likely to be the 
> best for my usecase:
> 
> MicroSD SanDisk Extreme PRO  64GB  [3]  XC II
> MicroSD SanDisk Extreme PLUS  64GB  [3]  XC I  V30  A2
> MicroSD SanDisk Extreme PLUS  32GB  [3]  HC I  V30  A1
> MicroSD SanDisk Ultra  32GB  [1]  HC I  (10)  A1

The section "'Application Performance Class' to the rescue" didn't help 
tell you about the relevancy of A1/A2 classification?

And subsection "Real world 2018 A1 and A2 performance comparison" didn't 
help tell you about real-world relevancy of A1 versus A2 classification?

Oh well.


> Ahh.. there's another hint! For some applications, disk partition 
> matters?

Explained here (yes, shared a few posts ago as well):

https://wiki.gentoo.org/wiki/SDCard#Solution_2:_Tuned_ext4
https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/
https://lists.linaro.org/pipermail/flashbench-results/2014-July/000479.html


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#210215 — Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)

On 6/21/19 12:28 AM, Erik Josefsson wrote:
> Hi David,
> 
> On 6/19/19 3:38 AM, David Christensen wrote:
>>
>> The best way to answer your question regarding performance of a size N 
>> SD card vs. a size 2*N SD card is to buy two cards and benchmark them 
>> using your workload.  Please publish your findings.
> 
> Please find my four (4) findings below or at 
> http://paste.debian.net/1088723
> 
> The only benchmark I know how to use is flashbench. But unfortunately I 
> don't know how to interpret the resulting data.
> 
> I would be immensely grateful for advise on which of the 4 cards to use.
> 
> The testing was simple. I have downloaded and put the same copy of the 
> redpill RC3 image from http://box.redpill.dk/nonfree/ onto each SD card, 
> then I have followed the instructions. Each card now has an "Extended 
> system" created by the command box-add-gui on the same machine.
> 
> Then I have installed aptitude, run update and upgrade and autoclean, 
> and then installed and run flashbench with parameters: flashbench -a 
> /dev/mmcblk0 --blocksize=1024
> 
> The four cards are:
> 
> MicroSD SanDisk Extreme PRO  64GB  [3]  XC II
> MicroSD SanDisk Extreme PLUS  64GB  [3]  XC I  V30  A2
> MicroSD SanDisk Extreme PLUS  32GB  [3]  HC I  V30  A1
> MicroSD SanDisk Ultra  32GB  [1]  HC I  (10)  A1
> 
> I can send a picture of the cards off list if this is unclear.
> 
> So the question is, which card should I use for Teres-I ?
> 
> If there are further benchmarks or tests that could help determine which 
> SD card is the best, I'd be happy to run them.
> 
> Best regards.
> 
> //Erik
<snip>

I'm not familiar with flashbench.  Every tool has a learning curve; it's 
up to you to decide how much effort you want to put into it.


When I wrote "benchmark them using your workload", I was thinking 
"install Debian, install your apps, run your apps, quantify what you 
can".  If you're doing command-line stuff, the 'time' built-in for Bash 
can be very useful.  But, it's also good to get a subjective feel for 
the system on the various media -- does it lag?  Does it stutter/ 
freeze?  Does it crash?


I found that Debian and FreeBSD on SanDisk Ultra Fit 16 GB USB 3.0 flash 
drives was "good enough" for headless servers, but stuttered/ froze for 
interactive graphical desktop use (during disk I/O; especially writes). 
I have since migrated to used 16 GB SSD's.  (Does your target hardware 
have a SATA port?)


David

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web