Archive

Posts Tagged ‘asus ul20a’

Lured into Linux Real Time

April 13th, 2013 subogero Comments off

The support period of the Lucid Lynx on the Asus UL20A is about to end in May, so I was looking for a new OS. I gave a try to Debian Testing, or Linux Mint Debian Edition, to be precise. But not Pangolin. Sorry.

It was my smoothest Linux install ever. All hardware worked out of the box. Volume and brightness buttons? Check. Wifi? Check. Two-finger scrolling? Check. I also applied the usual MATE fixes for mutt and the power-button. Debian comes with a 486-kernel by default, so it handles only one processor core. One can upgrade manually to a multi-core 686-kernel with apt-get.

aptitude search linux-image

And what do I find?

linux-image-rt-686-pae

A PREEMPT_RT patched kernel, kindly compiled by Debian. Time to plunge into real-time again!

I put together a Linux syscall tutorial project a year ago (see github) which contained a small program performing a periodic real-time task and printing statistics like average/min/max dt and its standard deviation. It’s called rt and uses the setitimer() system call to generate periodic SIGALRM signals. Time to measure latencies of a 1ms periodic task on a RT kernel!

To my utter disappointment, performance was fine, until the tapeta daemon changed my wallpaper, that is. At which point a 300% latency appeared. That’s right, period time 4ms instead of 1ms. Same as earlier, without an RT kernel. What’s wrong?

I was not using real-time scheduling, that’s what. It turned out Linux processes run at static priority zero by default, where the actual scheduling priorities are dynamic, depending on interactivity, nice level, sleep/runtime, etc. This is called the SCHED_OTHER policy. In other words, one is at the mercy of the Completely Fair Scheduler.

On the other hand, a process’ static priority can be increased, and the scheduling policy can be changed to SCHED_FIFO with the sched_setscheduler() system call. In this case the only one whose mercy we are at, is another SCHED_FIFO or SCHED_RR (Round Robin) scheduled process with equal or higher static priority, lurking in the background somewhere. Important to note, though, a process needs to run as root to be able to change its own or another process’ scheduling. There is also a command line utility called chrt, to change the scheduling policy of processes.

By the way. I’m not using threads. Threads are evil. People who use them mostly condemn themselves to a thousand hells of corrupted data, deadlocks and, at the end of the day, slower performance, thanks to cache misses and dirty cache lines. And the uClibc library in many embedded systems does not support POSIX threads. Thank goodness. I’m particularly angry with threads, as every damn RT-Linux tutorial you look at, spends 75% with setting up the bloody things. And you even have to worry about which thread your signals will be delivered to. What about learning fork() and pipe() instead? KEEP IT SIMPLE STUPID!

But enough of my rants and dodgy theories, let’s see the practice. First let’s see, how the skeleton of a periodic task looks like.

#include <unistd.h>
#include <signal.h>
#include <sys/time.h>

/* Periodic SIGALRM handler routine: everything happens here */
void periodic(int signal)
{
    ... /* do your periodic stuff */
    if (continue_running)
        signal(SIGALRM, periodic);
    else
        exit(0);
}

int main(int argc, char *argv[])
{
    ... /* initialize your stuff */
    struct itimerval period = {
        { 0, 1000, }, /* 1st signal in [s], [us] */
        { 0, 1000, }, /* period time   [s], [us] */
    };
    signal(SIGALRM, periodic);       /* install periodic() to handle SIGALRM */
    setitimer(ITIMER_REAL, &period, NULL); /* start periodic SIGALRM signals */
    /* Main idle loop: everything done by the signal handler */
    while (1)
        pause();
    return 0;
}

Next, how to set up real-time scheduling. Add this code to main(), before the setup of the periodic stuff. Remember to run your program as root for the below code to take effect.

#include <sched.h>
...
int main(int argc, char *argv[])
{
    ...
    struct sched_param schedp;
    schedp.sched_priority = 1;
    sched_setscheduler(0, SCHED_FIFO, &schedp);
    ...
}

And now let’s see what happens when a process becomes real-time. I’m measuring latencies of a 1ms task on Raspberry Pi, actually without a PREEMPT_RT kernel. I start rt as a normal process, then change its scheduling to SCHED_FIFO with chrt. See the code of rt on github.

szg@og314 ~/syscalls $ ./rt 1000
Real time child process PID 3368
------------------------------------------------------------------------
     n  Mean [us]       [us] SD  [%]      [us] Min [%]      [us] Max [%]
------------------------------------------------------------------------
   982   1017.502    246.148  24.615        67  93.300      4449 344.900
   985   1015.249    247.086  24.709        71  92.900      4865 386.500
   975   1025.625    300.905  30.091        63  93.700      4669 366.900
   989   1011.116    162.667  16.267       181  81.900      2682 168.200
   986   1014.260    155.867  15.587       259  74.100      2506 150.600
   989   1011.115    163.982  16.398        51  94.900      2674 167.400
   983   1017.492    189.123  18.912        59  94.100      2803 180.300
   983   1017.102    199.678  19.968        74  92.600      3985 298.500
   985   1015.169    214.607  21.461        62  93.800      3938 293.800
   978   1022.632    267.480  26.748        83  91.700      4355 335.500
   988   1012.008    165.071  16.507        84  91.600      2707 170.700
   991   1009.079    222.581  22.258        72  92.800      6762 576.200
  1000   1000.001     18.526   1.853       769  23.100      1218  21.800
  1000   1000.040     16.464   1.646       834  16.600      1163  16.300
  1000    999.958     12.861   1.286       924   7.600      1086   8.600
  1000   1000.002     17.503   1.750       809  19.100      1223  22.300
  1000   1000.014     20.984   2.098       793  20.700      1212  21.200
  1000   1000.035     24.159   2.416       827  17.300      1175  17.500
  1000    999.998     26.596   2.660       795  20.500      1246  24.600
  1000    999.962     18.433   1.843       844  15.600      1152  15.200
  1000    999.989     34.235   3.424       716  28.400      1314  31.400
  1000   1000.003     18.630   1.863       849  15.100      1214  21.400
  1000   1000.001     22.666   2.267       717  28.300      1268  26.800
  1000    999.996     20.419   2.042       799  20.100      1196  19.600
  1000   1000.051     15.729   1.573       831  16.900      1159  15.900
  1000    999.951     13.385   1.339       920   8.000      1109  10.900
  1000   1000.000     18.562   1.856       830  17.000      1210  21.000
  1000   1000.002     28.782   2.878       812  18.800      1222  22.200
  1000   1000.039     19.713   1.971       763  23.700      1239  23.900
  1000    999.964     25.291   2.529       907   9.300      1118  11.800
     1   1035.000     35.000   3.500      1035  -3.500      1035   3.500
------------------------------------------------------------------------
     n  Mean [us]       [us] SD  [%]      [us] Min [%]      [us] Max [%]
------------------------------------------------------------------------
 29815   1006.212    136.875  13.687        51  94.900      6762 576.200

A line of statistics is printed after every second with the following columns: n (number of events), Mean dt, SD (standard deviation), and Min/Max dt. Whilst the program was running, after the 12th line of data above, I changed rt’s scheduling with the command below.

root@og314 ~ # chrt -f -p 1 3368  # -f : SCHED_FIFO, 1 : static priority 1

The effect was truly dramatic. With normal scheduling I was missing about 2% of the events, with an average latency of 20% (0.2ms), in the worst case up to 600% (6ms). After changing to real-time scheduling, not a single event went lost, average latency dropped to 2% (0.02ms!), and the worst case delay dropped to 31% (0.31ms).

All this is causing 7-8 % processor load on a Raspberry Pi running two ssh sessions and omxplayer playing an internet radio. Single core, no PREEMPT_RT kernel. You probably need the latter in a production system which must not miss a beat for weeks.

So Linux is definitely able to run an ECU. That’s where my new ARIA25 board will excel. After someone designs an ECU for me…

Jaunty vs Lucid Reboot Time

August 23rd, 2010 subogero Comments off

I’ve measured the reboot time after the Lucid install on the ASUS UL20A. That’s what I call progress.

                         Jaunty  Lucid
--------------------------------------
from power-on until login  19 s   20 s
from login until ready     15 s    5 s
power off                  12 s    5 s
--------------------------------------
overall reboot time        46 s   35 s

Ubuntu 10.04 Lucid on ASUS UL20A

August 20th, 2010 subogero 4 comments

Well, Jaunty was not able to use the full (you know what I mean) resolution of my new TV, so I thought it was time to upgrade. I started Lucid Lynx from a live USB, attached the TV and, to my utter amazement, I was immediately presented with 2 073 600 deep purple pixels.

Upgrade time! Or even more than that. Time to reorganize my partitions. All I left was the original 200 GB home partition, now mounted as “/public”, mainly for my strictly legal (in Hungary) music and movies. If you live in the US of A, do not do this! The monopolists will confiscate your possessions, kill your family and jail you for 2000 years.

Anyway, 65 GB of unused Windows 7 (which I had no other choice than to pay for) was permanently removed, replaced by a new “/home” partition. The remaining 50 GB became “/” (root for starters).

Installation went like a breeze, as usual with Ubuntu. WLAN connected immediately. The telly as an external full high definition monitor? You betcha. Import stuff from old user profile, apt-get all the important packages (gimp, development stuff, openarena), compile and install the freshest hypest midnight commander, and there you go.

One thing. The bloody LCD brightness buttons. They did not work at all. Nor could I set brightness any other way, including the GUI and my Jaunty hack. Nice. This is the point where most people start thinking about suicide.

Others, however, use Google. Which reveals the solution immediately in the form of an Ubuntu wiki page:

acpi-backlight=vendor

has to be added to the GRUB kernel command line. Since then it works beautifully, even the flickering of my Jaunty hack is a thing of the past.

Jaunty Keyboard Layout Settings 2

March 18th, 2010 subogero Comments off

Finally. I’ve picked up my US keyboard for the ASUS UL20A today. Installation was surprisingly easy, with no warranty-void-if-removed stickers anywhere. Time to play again with keyboard settings. Default layout became US International (with dead keys). I kept Hungarian (qwerty) as well for the occasional őŐűŰ. And now to the most interesting part, the Layout Options.

Ctrl Key Position, Make CapsLock an additional Ctrl.
Hurraaaaah!!!! The bloody CapsLock is eliminated at last!

Key(s) to Change Layout, Both Shift keys together.
A combination of keys far away from each other, never normally used together.

Use keyboard LED to show alternative layout. CapsLock.
Of course. As the bastard is dead, I can use its LED to indicate if the Hungarian layout is active.

This incredible abundance of keyboard settings is amazing. A good reason alone to choose Linux over Windows.

ASUS UL20A Brightness Buttons

December 24th, 2009 subogero 10 comments

As I’ve mentioned before, ubuntu 9.04 Jaunty has been running fine on my ASUS UL20A laptop. Except the screen brightness buttons, Fn-F5 (down) and Fn-F6 (up).

Fn-F5 was setting brightness to the darkest value while Fn-F6 to the second darkest one. I’ve managed to create a crufty workaround, detailed below. It’s all about hacking the configuration of acpid (the ACPI daemon).

Set Brightness Directly

There is a special file called /proc/acpi/video/VGA/LCDD/brightness which lists the available and the actual brightness values. Brightest is shown below.

szg@OG3:/proc/acpi/video/VGA/LCDD$ cat brightness
levels:  10 16 22 28 34 40 46 52 58 64 70 76 82 88
current: 88

Setting brightness is done by writing a number into this file, the example shows darkest possible.

echo 10 > /proc/acpi/video/VGA/LCDD/brightness

Explore What Events the Brightness Keys Generate

Start the program called “acpi_listen”, which will print power-management related events when they happen.

When hitting Fn-F5 (Brightness down):

video LCDD 00000087 00000000
hotkey ATKD 00000020 000000fc

When hitting Fn-F6 (Brightness up):

video LCDD 00000086 00000000
hotkey ATKD 00000011 00000106

So each hotkey generates two events. Now let’s see how these events are handled. (Hard to see, as by now the screen is very dark. Bugger.)

Configure How acpid Handles Events

The configuration of “acpid” is in the “/etc/acpi/events” directory. Each file here handles one event type, line “event=regexp” defines the event, where the regexp shall match something like above, while line “action=command” the callback.

Fn-F5 (down) video LCDD 00000087 00000000 is handled by file “video_brightnessdown”:

event=video.* 00000087
action=/etc/acpi/video_brightnessdown.sh

Fn-F5 (down) hotkey ATKD 00000020 00000000fc is handled by “asus-brightness-down”:

event=hotkey (ATKD|HOTK) 0000002[0123456789abcdef]
action=/etc/acpi/asus-brn-down.sh

Fn-F6 (up) video LCDD 00000086 00000000 is handled by file “video_brightnessup”:

event=video.* 00000086
action=/etc/acpi/video_brightnessup.sh

Fn-F6 (up) hotkey ATKD 00000011 0000000106 is handled by “asus-brightness-up”:

event=hotkey (ATKD|HOTK) 0000001[0123456789abcdef]
action=/etc/acpi/asus-brn-up.sh

As you can see the callback scripts are in “/etc/acpi”.

Test the acpid Callback Scripts

Running all four callback scipts directly from the command line revealed they don’t work at all. Absolutely no effect on brightness. That’s why I now ignore their contents completely.

The test revealed something else as well: the broken function of both hotkeys comes from outside of this acpid-config mechanism. Probably the kernel. Which I won’t try to fix, I’ll just create a workaround.

The Fix

I linked the fixed callbacks to the second event for each hotkey, “hotkey ATKD 00000020″ (down) and “hotkey ATKD 00000011″ (up). Configured by “asus-brightness-down” and “asus-brightness-up”, respectively. I’ve removed the other two config files (video_brightnessdown/up) completely, which were handling the first event for each hotkey.

The new callback script for brightness down reads the actual value from a new config file (/etc/acpi/brightness), decrements it by 6, and stores it to the config file AND the “/proc/acpi/video/VGA/LCDD/brightness” file as well.

#!/bin/bash
if [ ! -f /etc/acpi/brightness ]; then echo 88 > /etc/acpi/brightness; fi
BRIGHTNESS=`cat /etc/acpi/brightness`
if [ $BRIGHTNESS -gt 10 ]; then let BRIGHTNESS-=6; fi
echo $BRIGHTNESS > /etc/acpi/brightness
echo $BRIGHTNESS > /proc/acpi/video/VGA/LCDD/brightness

The new brighness up script is similar, just increments the value by 6.

#!/bin/bash
if [ ! -f /etc/acpi/brightness ]; then echo 88 > /etc/acpi/brightness; fi
BRIGHTNESS=`cat /etc/acpi/brightness`
if [ $BRIGHTNESS -gt 10 ]; then let BRIGHTNESS+=6; fi
echo $BRIGHTNESS > /etc/acpi/brightness
echo $BRIGHTNESS > /proc/acpi/video/VGA/LCDD/brightness

The final touch: the callback script for AC/battery events (power.sh) also writes the config file to guarantee we always start changing the brightness from the actual value.

...
for x in /proc/acpi/ac_adapter/*; do
  grep -q off-line $x/state

  if [ $? = 0 ] && [ x$1 != xstop ]; then    
    for SCRIPT in /etc/acpi/battery.d/*.sh; do
    . $SCRIPT
    done
    echo 52 > /etc/acpi/brightness
    echo 52 > /proc/acpi/video/VGA/LCDD/brightness
  else
    for SCRIPT in /etc/acpi/ac.d/*.sh; do
    . $SCRIPT
    done
    echo 88 > /etc/acpi/brightness
    echo 88 > /proc/acpi/video/VGA/LCDD/brightness
  fi
done

Now, when hitting the brightness hotkeys, the screen switches to the darkest setting for a moment, but then it works. Perfect. Nearly.

Ubuntu 9.04 Jaunty on Asus UL20A

December 11th, 2009 subogero 7 comments

I’ve just purchased an ASUS UL20A-2X022V notebook. Or netbook. I don’t know. It’s actually the best of both worlds. On one hand, it has a small 12″ display, weighs in at 1.5 kg, has no CD/DVD drive, and runs 5 to 7 hours on battery. On the other hand, its small display’s resolution is 1366×768, it has a Core 2 Duo ULV SU7300 processor, 3 GB RAM, a 320 GB hard disk and a fully functional keyboard with all the special keys on the right side.

A short summary of how the different hardware components work with ubuntu:

Component                    Status  Notes
------------------------------------------
Intel Core2 Duo ULV SU7300   OK
12.1" WXGA LED display       OK      resolution autodetected
Intel GMA 4500MHD graphics   OK
3 GB RAM DDR2 800 MHz        OK
HD 320 GB 5400rpm SATA       OK      install with manual partitioning
battery Li-ion 5600 mAh      OK
power management             OK      battery life 5-6 hours
ethernet Atheros 8131        OK      see below
WLAN Atheros 9285 802.11bgn  OK      see below
Bluetooth                    OK
Sound AC'97 16bit            OK      Audacious mp3, speaker or headphone
Synaptics touchpad           OK      scrolling OK too, see below
webcam                       OK      see below
card reader                  OK
Linux kernel                 2.6.28-17

It came with Windows 7 Home Premium, which is a joke. A huge monster of an OS with the functionality of Google Chrome OS: it has a web browser.

First thing was to install ubuntu 9.04 Jaunty Jackalope. As the laptop has no CD drive I had to create a bootable Ubuntu 9.04 LiveUSB on my other ubuntu-box. The tool to use is usb-creator, which uses the iso image of the ubuntu LiveCD.

I installed ubuntu with manual partitioning. I shrank the Win7 partition from 80GB to 50GB (automounted to /windows), added a 2GB ext3 swap partition, a 50GB ext3 root partition and the rest as a /home partition. The boot menu was added, and even Win7 ran fine after a chkdisk.

The network cards were not detected upon installation. Neither LAN, nor WLAN. So there I was with no connectivity, reading with a sad irony all those posts about fixing this with apt-get xxx-backports and the likes.

I ended up downloading compat-wireless-2.6.30.tar.bz2 on another box to a USB stick, and then unpacking and compiling it on the laptop. I realised too late these kernel modules were for a newer kernel. Nevertheless I did “make install”, I did “make unload” and I did “insmod ath9k.ko”. It did not work due to incompatible kernel versions. I sadly rebooted to Windows, but later gave it another try. Miraculously, all network cards worked like a breeze! Don’t ask me why…

Touchpad: everything works, but it’s hard to feel where is the scrolling area. And the left button is too hard.

Keyboard (Hungarian): OK, but it will be swapped for a US layout, whose Hungarian is worse, but speaks better Code.

Webcam: I installed the UCview package to record videos with it. Skype works too.

I downloaded all the updates, then SynapticPackageManaged Rhytmbox/Evolution out, Audacious/Thunderbird in, I installed basic development stuff, and last but not least git-cloned and compiled the newest Midnight-Commander master with utf8-support.

One more thing: it is very very quiet. Summary? Bloody marvelleous!

Linux On Laptops

Categories: Uncategorized Tags: , ,