knasan

Linux and more

Archiv für den Monat “Januar, 2013”

hard-masked USE-Flags

Ich bin schön des öfteren darauf gestoßen dass die USE-Fags 3dnow, 3dnowext, sse, sse2 und sogar vdpau hard-masked sind.
Warum das so ist, wusste ich bisher nicht. Heute bin ich zufällig auf eine Seite gestoßen warum 3dnow, 3dnowext, sse und sse2 maskiert sind.

Ursprünglich wurden die USE-Flags eingeführt, um die Unterstützung für ältere Prozessoren wie der Pentium I, der nichts mit diesen Flags anfangen kann, zu emulieren.
Derzeit unterstützen alle AMD64s die gleiche Kombination von erweiterten Befehlssätze, so gibt es keinen Grund zur Verwendung der genannten USE-Flags.
Deshalb sind diese USE-Flags hart maskiert in allen AMD64-Profilen.

Es bedeutet jedoch nicht das diese nicht verwendet werden können, man kann diese USE-Flags hart einschalten. Die Frage lautet nun, benötigt man diese?
Was sind die Vor bzw. Nachteile, darauf wird leider nicht eingegangen, es ist nur beschrieben warum diese Maskiert sind. Aber immer hin, nun kenne ich den Grund.

Assembler Optimisation

Modern x86 processors support special instruction sets like mmx, sse, SSE2 and 3DNow!. AMD64 also provides support for them, but in most cases, x86 assembler code is incompatible with AMD64 assembler. There are lots of packages that provide support through USE flags for these instruction sets. Originally, the USE flags were introduced to keep support for older processors such as the Pentium I that can’t handle such code. Currently, all AMD64s support the same combination of extended instruction sets, so there is no reason to make use of the mentioned USE flags. That’s why these USE flags are hard-masked in all AMD64-profiles. This doesn’t mean we don’t support the extensions themselves, instead, we hard-enable them.

The following USE flags are masked on AMD64:

mmx
mmx2
sse
sse2
3dnow
3dnowext

Quelle: http://devmanual.gentoo.org/archs/amd64/index.html

Es gibt zur Zeit vieles was ich an den USE-Flags nicht verstehe und hoffe das ich darüber mehr Informationen sammeln kann. Leider sind die Aussagen wie „X – Support for X11“ wenig aussage kräftig und es zum Beispiel um opengl geht. „opengl, gles1 und geles2“ Laut google gibt es schon gles3. Heißt es nun wenn man gles2 setzt kein gles3 bekommt? Ein USE-Flag für gles3 gibt es gar nicht – ist es der Standard? All solche dinge kosten oft etwas Zeit und diese Aufgabe werde ich mich demnächst kümmern und hier veröffentlichen.

http://www.khronos.org/opengles/

Da diese USE-Flags etwas mit Tuning zu tun haben, möchte ich nun wirklich etwas Zeigen was getuned ist.
In mein System sind zwei SSD, eine für mein HOME und die andere mein System. Zum Kompilieren verwende ich „ccache“ und meine MAKEOPTS ist auf „-j8“ gestellt.
Getestet habe ich libreoffice, was normal ca 60 Minuten dauert (etwas mehr oder weniger). Mit aktivem ccache und MAKEOPTS -j8, wenn libreoffice schon im cache liegt, dauert es nur noch 14 Minuten.
Aber was Passiert wenn man den Scheduler ändert? Auf diese Idee bin ich gekommen, da ich gelesen habe dass man für SSDs den Scheduler auf „noop“ setzen sollte. Hier die Resultate mit time gemessen.

cfg
real 14m11.091s
user 20m37.011s
sys 7m59.036s

noop
real 12m36.266s
user 19m59.285s
sys 7m33.866s

deadline
real 12m40.719s
user 20m2.532s
sys 7m36.524s

Es gibt derzeit diese drei Scheduler, cfg, noop und deadline. Der Scheduler kann während des betrieb gewechselt werden, dieser überlebt jedoch keinen Neustart des Systems.
Da der Scheduler in /sys/block/FESTPLATTE/queue/schedule gesetzt werden muss, kann dieser nicht in sysctl.conf gesetzt werden, sysctl ist nur dafür ausgelegt das /proc zu ändern.
Möchte man den Scheduler seiner Wahl beim hochfahren aktivieren gibt es drei Möglichkeiten.

1. Man schreibt sich ein eigenes Init Skript (schlechte idee)
2. Man kompiliert einfach den Kernel so, dass der Standard Scheduler nicht „cfq“ sondern ein anderer ist. Machbar, kostet aber mehr Zeit. Diese IDEE ist aber nur bedingt schlecht, denn manche Scheduler sind für Datenbank-Zugriff besser geeignet und könnte auf einem Server durchaus Sinn machen.
3. Man verwendet ein Bash Script (was kein init Skript ist) der einfach per echo den Scheduler beim hochfahren des Rechners setzt. Hierfür gibt es in Gentoo/Funtoo das Verzeichnis /etc/local.d.

Einfach diesen Code in einer Datei Speichern unter /etc/local.d und ausführbar machen. Schon hat man seinen Scheduler seiner Wahl per Default 🙂

#!/bin/sh
echo noop > /sys/block/sda/queue/scheduler
echo noop > /sys/block/sdb/queue/scheduler

Es kommt auch mal vor, das ein anderer Scheduler benötigt wird. Auch hierfür gibt es eine einfache Lösung.
Dieses Script nach /usr/local/sbin Speichern, ich nannte es switch_scheduler.

#!/bin/sh

if [ -z $1 ]; then
echo "cfq, noop or deadline"
exit
fi

echo $1 > /sys/block/sda/queue/scheduler
echo $1 > /sys/block/sdb/queue/scheduler

Als Root, ist es nun ganz einfach Möglich auf einen anderen Scheduler zu wechseln. Dieses Script ist natürlich total dumm, da nicht geprüft wird ob es den angegeben Scheduler überhaupt existiert.
Es ist durchaus denkbar, einen Schuduler aus dem Kernel zu werfen und somit existiert diese nicht. Auf einer komplexen überprüfung habe ich auch verzichtet, da nun der Scheduler geschrieben werden kann, der auch existiert.

Welche Scheduler das System unterstütz bekommt man mit cat raus.

cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

Der zur Zeit verwendete Scheduler wird hier in eckigen Klammern gelistet.

Wird der Scheduler nicht vom System unterstützt bekommt man eine Fehlermeldung, ansonsten passiert nichts

sudo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: line 8: echo: write error: Invalid argument
/usr/local/sbin/switch_scheduler: line 9: echo: write error: Invalid argument

Oder auf Deutsch

udo switch_scheduler hallo
/usr/local/sbin/switch_scheduler: Zeile 8: echo: Schreibfehler: Das Argument ist ungültig.
/usr/local/sbin/switch_scheduler: Zeile 9: echo: Schreibfehler: Das Argument ist ungültig.

Es kann sich also lohnen, mal zu testen wie sich die Scheduler im Alltag verhalten. Beim Kompilieren hat eindeutig noop bei mir gewonnen.
Diesen habe ich auch mal auf Default gesetzt. Selbst beim Spiel stuntrally merke ich keinen unterschied. Dies kann aber an meiner SSDs zusammen hängen.
Wenn ich denke, hm ist irgendwie langsam, wechsel ich zu cfq, dieser ist in der Regel der Default Scheduler.

Viel Spaß beim Testen.

knasan

Stuntrally, Spaß mit Linux

Die Macher von Stuntrally haben ganze Arbeit geleistet. Bisher das Beste Rally Spiel unter Linux was ich gesehen habe, Spaß ist hier vorprogrammiert. Lange habe ich nach ein Game gesucht das so süchtig machen kann wie Stuntrally.

Wer einen Joystick besitzt und mit diesen spielen möchte, kein Problem. Ich verwende zum Beispiel mein Gampad von einer PS3.

Leider gab es für dieses Spiel kein gentoo Ebuild, also musste ich selbst Hand anlegen und eines schreiben. Manchmal ist das ein unterfangen das sehr viel Zeit und Mühe kostet, aber man ist natürlich auch Stolz auf sein Ebuild.

Ich möchte euch nun ein paar Bilder zeigen, wer gerne mal ein Rennen Fahren möchte und auf gute Grafik nicht verzichten möchte, ist mit Stuntrally bestens bedient.

01232013_233842007

Es gibt eine ganze Menge an Stecken die man Fahren kann. Von Leicht bis Schwer, aufwendig oder einfach, es ist für jeden etwas dabei.

Was mit sehr gut gefällt sind Loopings

Runde mit Loopings

Hier sehr schön zu sehen, die Macher von Stuntrally haben sich sehr viel Mühe gemacht. Es macht nicht nur Spaß dieses Spiel zu Spielen, sondern es ist auch noch schön es anzusehen.

Ähnlich wie bei Need for Speed, boost für alle.

Boost für alle

Rein in den Looping aber mit Speed. Es ist nicht immer einfach die Balance zu halten.

Bodenhaftung nicht immer gegeben.

Bodenhaftung nicht immer gegeben.

Ist man zu schnell unterwegs, kann es passieren das man abhebt.

01232013_232505389

Wie man hier gut sehen kann, ist die Auslastung am Rechner gering, es kommt natürlich auf dem Rechner an.

01232013_232925200

Die Strecken Bauer haben sich vieles einfallen lassen. Fahren in einer Winterlandschaft gibt einen erst den richtigen kick.

01232013_233047187

Driftet man um die Kurven gibt es satte Punkte. Es gibt Verschiedene Techniken dies zu tun. Ob man die Handbremse benutzt oder doch einfach Normal auf die Bremse Tritt kostet etwas Strecken Erfahrung und man muss auch das Auto etwas besser Kennenlernen.

01232013_234455545

Ist man im Single Modus die Runde einmal durchgefahren, bekommt man besuch von Ghost.

01232013_234318455

01232013_234531144

Alle Wagen müssen Wasserdicht sein, oft geht man ungewollt Baden wenn man vom Weg abweicht. Es gibt aber auch Strecken wo man sogar gezwungen wird durchs Wasser zu Fahren. Manchmal können diese auch Tief sein. Hängt man fest, kommt man nur mit Flippen des Wagens wieder raus. Manchmal aber auch nicht!

01232013_234311564

Ich finde, es ist wirklich ein sehr gutes Spiel geworden. Nicht nur spielerisch der Steuerung sondern die Grafik allein macht schon sehr viel her.

Jetzt möchtest du natürlich auch dieses Game haben, was ich gut Verstehen kann, dann habe ich eine sehr gute Nachricht für dich. Einen Ebuild für gentoo gibt es auf meinem github Account.
Wenn du mein Ebuild verwendest und Fehler findest, dann melde dich bei mir, damit ich darüber Informiert bin und es beheben kann.

Da es wirklich nicht einfach war, möchte ich den Kompliziertesten Teil des Ebuilds hier kurz verewigen.

src_unpack() {
  git-2_src_unpack
  EGIT_REPO_URI="git://github.com/stuntrally/tracks.git"
  EGIT_SOURCEDIR="${S}/data/tracks"
  git-2_src_unpack

  mkdir ${MYBUILD_DIR}
  [ -d ${S}/data/tracks/.git ] && rm -r ${S}/data/tracks/.git
}

Das Ebuild für Stantrally ist ein Live Ebuild. Dies bedeutet dass alle benötigten Daten vom Server via „git“ abgeholt werden.
Stuntrally benötigt zwei „git“ zweige. Im ersten Zweig ist das Spiel an sich und im zweiten teil, wie hier zu sehen, die Strecken (tracks).
Um jetzt nicht zwei Ebuilds schreiben zu müssen und auch nicht ständig die ganzen 395 MB zu downloaden zu müssen, suchte ich nach eine Möglichkeit diese in einem Ebuild zu verpacken.

Nach etwa drei Tagen ist mir eine Lösung gelungen.

1. Noch bevor src_unpack aufgerufen wird, wurde EGIT_REPO_URI auf das git vom eigentlichen Spiel gesetzt: git://github.com/stuntrally/tracks.git
2. git-2_src_unpack Klont das Repository auf Festplatte und entpackt es.
3. Die Variable EGIT_REPO_URI wird nun auf die Tracks gesetzt und erneut mit git-2_src_unpack heruntergeladen und entpackt.
Die Variable EGIT_SOURCEDIR sollte normal nicht gesetzt werden, aber es ist natürlich problematisch beide Repos in einem Verzeichnis zu Klonen.
Deswegen habe ich diese gesetzt, damit die Quellen immer lokal auf Platte beleiben und bei einer Neuinstallation nicht ständig gelöscht wird und somit jedes mal 395 MB gesaugt werden muss.

Das Ebuild kennt ein USE-Flag, editor.
Setzt man dieses Flag, bekommt man ein Spiele Editor Installiert, was ich mir jedoch noch nicht genau angesehen habe.
Wer dieses Game mag, wird sicherlich früher oder Später eigene Strecken bauen wollen.

Wie oben kurz erwähnt, das Ebuild findet Ihr auf mein Github Account https://github.com/knasan/ebuilds.
Hierfür richtet man sich am besten ein Lokales Overlay ein, hierzu benötigt man Layman. Am besten einfach kurz nach gentoo layman suchen, dann findet man sehr schnell Informationen wir man sich ein Lokales Overlay einrichtet.

Viel Spaß beim Zocken!

Sandy

sysnapshot und nepomukserver (KDE Desktop-Suche)

Hab einiges über die Desktop-Suche in KDE gelesen und wollte mir die angeblichen Vorteile von KDE selbst einmal ansehen. Also KDE installieren und wichtige Tools einrichten und schnell ein Backup erstellen, was ich immer nach grössere Änderungen am System mache …

sudo sysnapshot

Während dessen machte mich noch etwas schlauer wie denn die Desktop-Suche Funktionieren sollte.
Riskierte ein Blick auf mein Terminal, ups was ist das? Meine Backup-Festplatte konnte nicht getrennt werden, aber warum?

lsofs Zeigte mir an, dass Nepomuk die Festplatte in Beschlag genommen hat. Ich frage mich warum?

Einerseits habe ich die Festplatte als „root“ gemountet und ging den User nichts an, und zum anderen habe ich schon oft gelesen das nur dass Home-Verzeichnis des Users Indexiert wird. Dies wollte ich nun genauer wissen und schaltete den indexer aus. Startete nochmal sysnapshot, keine Besserung in Sicht, Nepomuk hatte wieder die Festplatte in Beschlag.
Ich begab mich auf die Suche ob es möglich Nepomuk beizubringen dass er dieses Verzeichnis in ruhe lassen soll. Ich wurde nicht fündig!

Fuck off nepomuk!

Ich hatte keine Lust mehr eine Funktion zu suchen, ich muss mich erst noch Intensiver mit Nepomuk beschäftigen, damit ich eine Lösung finden und Dokumentieren kann.

Ist zwar nicht die beste Lösung aber es funktioniert.

  • Man könnte auf Nepomuk verzichten, dann wäre dieses Problem gar nicht da!
  • Wenn man die Backup-Festplatte einbindet bevor sysnapshot gestartet wird, dann macht sysnapshot kein umount und man bleibt von diesen Problem unberührt.
  • Wer sysnapshot als „root“ laufen lässt hat dieses Problem auch nicht mehr, da ich nun die Zugriffsrechte auf den Mountpoint so geändert habe, dass nur Root darauf zugreifen kann.
  • Dies sind leider nur Workarounds, was mir gar nicht gefällt.

    Abgesehen von dieser Nepomuk Thematik war mein erster Test jedoch Positiv.
    Obwohl ich wusste wo die Datei lag die ich suchte, konnte ich diese schnell mit der Suche finden und ein klick, schon konnte ich an dieser Datei Arbeiten.
    Hätte ich mit einen Dateimanager Navigiert hätte es länger gedauert. Mal sehen ob sich die Suche weiterhin bewährt, theoretisch benötige ich diese nicht, da ich alles Organisiert speichere.
    Was ich auch beibehalten werde. Selbst wenn ich Nepomuk in Zukunft öfters befragen werden.

    Sandy

    Beitragsnavigation

    %d Bloggern gefällt das: