Showing posts with label pi. Show all posts
Showing posts with label pi. Show all posts

16 Jun 2024

Compiling latest gcc to test more architectures

Off late, I've had two separate needs to compile GCC by hand and although my first foray into compiling gcc from git took patience, stumbling over the basics was interesting to say the least.

The first time I realised that an old GCC version could matter, was this feedback [1] that one of my buildfarm members was running an old (for its arch) gcc version, something that I almost never paid much attention to. The other being that that led me to newer architectures (more on that below) and how this could repeat itself if / when I end up playing with more architectures.

So finally, I can say I have a framework that frequently checks / recompiles gcc and ensures all my local tests are using the latest and the greatest gcc :) . (I am happy with how this has taken shape on my home server, and once I am able to port it to my other machines, don't see why this shouldn't land on github).

Now admittedly, compiling gcc on a nightly basis was already an overkill, but then what the heck - I went and did this hourly basis just because well-why-not. My personal ask was to:

  1. Incrementally learn how compiling gcc unfolds
  2. Have some fun scripting while at it
  3. ... but most importantly, see whether I could utilize this experience in other experiments where the idea is to forewarn database developers about upcoming changes.

A little more on point 3 above, I oversee a few machines on the postgres buildfarm and they differ in some aspects:

  1. Different archictures:
    1. aarch64: Gravitons
    2. x86-64: A vanilla off-the-shelf dell workstation
    3. armv7l - Raspberry Pi4
  2. Different GCCs:
    1. 8.3.0 (default in pi4)
    2. 7.3.1 (default on most ALs)
    3. 13.2 (default on Ubuntu)
    4. 14.0.1 (naive attempt at compiling whatever cleared make check)
    5. gcc (experimental nightly)
  3. (Internally I also run some different fuzzing workloads but that's besides the point)
  4. (Future plans - add some form of randomizer to test odd combinations of compilation flags, but more on that in an upcoming post)


Now if all goes to plan, I should also add to the mix, 2 new architectures. They wouldn't be the snappiest processors in the market (at least not in the pricing-level I am after), but hey it should be fun to play with!

  1. loongarch64 - (cough) Recent (but sure as butterflies, a promising) entrant - the MIPS64 Loongson has been around for some time now, but my interest has grown off late owing to sporadic reports that its becoming somewhat competitive, which should be interesting to review.
  2. riscv64 - Another interesting arch that should be fun to try out. Again, am not holding my breath that it'd top any charts, but could still end up being interesting nonetheless.

On the GCC front, getting the setup ready and stable, clears the path to now focus upgrading my buildfarm animals one-by-one and basically start focussing beyond this hurdle.

gcseb02 20240615_1700 - git checkout successful.
gcseb02 20240615_1700 - git pull successful.
gcseb02 20240615_1700 - No change in gcc version. Quitting.

gcsa36f 20240615_1800 - git checkout successful.
gcsa36f 20240615_1800 - git pull successful.
gcsa36f 20240615_1800 - gcc has changed - [471fb092601] vs [57af69d56e7]. Recompiling.
gcsa36f 20240615_1800 - make successful
gcsa36f 20240615_1800 - make install successful.
gcsa36f 20240615_1800 - gcc version string has changed from [15.0.0 20240615 (experimental) - 471fb092601] to [15.0.0 20240615 (experimental) - 57af69d56e7]

gcsf66a 20240615_1900 - git checkout successful.
gcsf66a 20240615_1900 - Unable to git pull. Are we connected? Quitting.
gcsf66a 20240615_1900 - git switched back to 57af69d56e7.

gcs629f 20240615_2000 - git checkout successful.
gcs629f 20240615_2000 - git pull successful.
gcs629f 20240615_2000 - gcc has changed - [57af69d56e7] vs [6762d5738b0]. Recompiling.
gcs629f 20240615_2000 - make successful
gcs629f 20240615_2000 - make install successful.
gcs629f 20240615_2000 - gcc version string has changed from [15.0.0 20240615 (experimental) - 57af69d56e7] to [15.0.0 20240615 (experimental) - 6762d5738b0]

.
.

gcsc115 20240616_0400 - git checkout successful.
gcsc115 20240616_0400 - git pull successful.
gcsc115 20240616_0400 - No change in gcc version. Quitting.

Reference

2. Compilation script source - https://github.com/robins/gcc_compile

13 Apr 2016

Postgres Performance - New Connections

Last in the the PostgreSQL Performance series:

Please read more about Test Particulars / Chart Naming methodology from the previous post in the series.

Takeaway:
  • New Connection performance has been constant (and at times have mildly deteriorated)
    • i.e. Pgbench with -C
  • I tried to use all possible combinations to find whether a corner case got better over the releases, but almost every test gave the same result.
  • Possibly Tom and others don't consider this a practical use-case and therefore a non-priority.
  • Unrelated, in the future, I'd club / write about such tests in a better fashion, rather than posting them as separate posts. I guess I got carried away by the results! Apologies about that.













Postgres Performance - Default Pgbench configurations

Continuing the PostgreSQL Performance series:

Please read more about Test Particulars / Chart Naming methodology from the previous post in the series.

Takeaway:
  • Unrelated to the Read-Only performance mentioned earlier, which grew slowly over each Major release, these numbers have grown considerably specifically in 9.5
  • 9.5 Branch is at times 35-70% faster than 9.4 Branch
  • To reiterate, this test had no Pgbench flags enabled (no Prepared / no Read-Only / etc.) besides 4 Connections & 4 Threads.





Postgres Performance - Read Only

Continuing the PostgreSQL Performance series:

Please read more about Test Particulars / Chart Naming methodology from the previous post in the series.

Takeaway:
  • Read-Only Performance numbers have consistently grown from (at least) 9.1 onwards
  • 9.5 Branch is 35%-50% faster than 9.1 Branch





Postgres performance - File + ReadOnly

Just wanted to see how Postgres performed when comparing its performance over the different Major releases. I had a spare Pi2 lying around and found it useful for such a performance test.

More inferences to follow, in future posts.
As always, any feedback is more than welcome.

TLDR:
  • Despite a regression in 9.3 onwards, the combination of File + Read-Only has improved drastically in the 9.6dev branch
  • 9.6dev branch is 
    • 2x faster than 9.1 on some tests
    • 50% faster than 9.5.2 (currently, the latest stable release!) on some tests
  • Yay!!
Hardware:
  • Raspberry Pi Model 2B
  • 1GB RAM
  • 900 MHz Quad-Core-ARM Cortex-A7 (ARMv7 Processor rev 5 (v7l))
  • 32GB Class 10 SD Card
Software: Source used for this test

Note:
  1. All configurations were run 10 times each
  2. All configurations were run for 100 secs each
  3. The Phrases in the name of each chart tells what Pgbench was run with:
    1. ConnX: with -cX (For e.g. Conn64: with -c64)
    2. Thread4: with -j4
    3. Prepared: with -M Prepared 
    4. File: External SQL file with one SQL command "SELECT 1;"
    5. Readonly: with -S
    6. 100secs: with -T 100








17 Dec 2015

MusicBox + Pi1B + Ancient 4.1 Speakers => Chromecast for Audio

Since Chromecast-for-Audio hasn't yet been launched in India, eBay sellers are using near monopoly extra for such a device here. Frustrated with being blackmailed like this, I resorted to conjuring up a combo that finally gave some shape to my 2 year old Pi and a ten year old 4.1 music system a life, and gave a good groove to my (otherwise boring) drawing room :) !
to charge a painful 150%

Parts:
  • Any Raspberry Pi
    • Except PiZero
      • Too low powered, would not work
    • To clarify, either of the following combos would work
      • The old PiA+ / PiB+
        • with SD Card
          • 2GB or more
      • The newer Pi2
        • with MicroSD Card
          • 2GB or more
  • MusicBox
  • Win32DiskImager
  • Client Operating Sytem
    • (Desktop) Windows
      • Bonjour
        • Optional
          • Makes the URL easier
        • I had Apple iTunes that install Bonjour support by default
    • (Smartphone) Android
      • Doesn't support Bonjour out of the box
      • Alternative,
        • Get the Pi to come with constant IP address
        • Bookmark the URL instead
  • Volume Control
    • The Web Interface allows changing volume
    • From the command line you could try this
      • amixer cset numid=1 -- 80%
Happy Listening :) !

11 Jun 2015

Using Pi as an home-based Media Server

This is among a series of articles on my experience with the Pi.

This article is about using a Pi as a primitive low-end File-Server for your home network:

Expectations:

  • Torrent-Server
    • Download Torrents
    • Store on a File-Share
  • Windows Share
    • Serve the File-Share as a Windows Share Drive
    • Allow Read / Write to this Windows Share Drive
  • Use File-Share as Media-Server
    • Using any Smartphone / Laptop
      • Play Movies using VLC
      • View all Photos / Home-Videos


Effectively:
  1. Always on
    1. Always accepting new Torrent requests
    2. Instantly start downloading 
  2. In Real-time
    1. Allow user's to view torrent download status
  3. Use any UPnP Phone App to play Video content over WiFi on a SmartPhone
  4. Use VLC (Network Streaming) to play any Video over WiFi on Laptop / Desktop
  5. Use Windows Share Drive and view all Photos / Home-Videos as needed

How-To:
  • On Server
    • Install Torrent-Daemon
    • Configure Torrent-Daemon to listen on RPC requests
      • Here's the howto for that
    • Configure Samba
      • Set the Download folder to be shared
  • On Windows
    • Install Transmission-GUI-Remote
    • Configure GUI to use the RPC based Torrent-Daemon server
    • Make this application the default for .torrent & magnet files
  • On Linux
    • Install Transmission-Remote
      • sudo apt-get install transmission-remote
    • Configure that to use Daemon (instead of downloading directly with transmission-cli)

Pros/Cons:
  • Pros
    • Once torrent download has begun, client can disconnect / shutdown client computer
    • Server continues to get torrents, after a restart
    • miniDLNA serving speed pretty decent
      • Watching a movie (over WiFi) on VLC
        • CPU ratio barely 0.01 which is pretty decent
          • Should be able to easily serve a small army :)
            • If no other IO is happening
            • If WiFi isn't the bottleneck 
  • Cons
    • Storage on Pi needs to be managed from time-to-time
      • Currently is highly adhoc based
        • Truly taking RAID concept to heart!!
          • Have 6 Pen Drives (ranging from 4GB to 16GB)
            • 8GBs are INR ~170 ( $3 )
            • All connected via 3 USB Hubs (both USB 2.0 and USB 3.0)
              • One Powered, two non-powered hubs
            • Most on Btrfs
              • Pretty stable, surprising that still get 1+ MBps with Pi's CPU
            • Some VFAT fs since have need of moving stuff off of Pi to a Windows Laptop
            • All mounted under /disk
              • Very temporary arrangement
                • Ideally am looking for a LVM solution (which allows me to remove / add pen-drives on the fly and thus can be called as one) that actually is suited for this purpose.
            • But miniDLNA picks up Photo / Audio / Video pretty well from all different mounted folders
    • Download speed limitations
      • Internet Speed = 2 MBps
      • Daemon Download speed capping = 1Mbps
        • But PI never reaches it :D !
          • Just imagine the poor configuration
            • Pi + Btrfs + USB 2.0 + 3 USB Chain + Unpowered Hub
              • Still consistent at 450kbps! Impressive!
    • Lack of Transmission-Daemon configuration tool means all configuration has to be done via black-screen configuration files
  • Careful configuration
    • Give all access to 'all' users only if you're sure that all users are going to be careful

What's in an empty table?

How much storage does an empty table in Postgres take? This is a post about Postgres tables that store ... well basically ...  Nothing . The...