Am 20.08.2011 07:37, schrieb David Haller:
> Hallo,
>
> Am Mon, 15 Aug 2011, Rico Koerner schrieb:
>> Am 15.08.2011 08:39, schrieb David Haller:
>>> Am Sun, 14 Aug 2011, Rico Koerner schrieb:
>>> dmesg ist also schon der richtige Ansatz.
>>
>> Das hab ich ja nicht verworfen.
>>
>>>> Dort steht die Zeit ja schon am Anfang der Zeile. Somit wird immer die
>>>> korrekte Zeit ausgegeben.
>>
>> Nein, eben nicht. Die Abweichung wurde ja nun schon mehrfach
>> festgestellt. Nur deshalb hab ich den Weg verfolgt.
>
> Wie gesagt, ich denke das ist ein Sonderfall. Leider hat Frank keine
> "Rohdaten" (uptime, timestamp in dmesg/syslog) mit denen dann
> weitergerechnet wird geliefert.
Ein Sonderfall ist es eben nicht, Abweichungen treten auf allen
Maschinen auf. Die Höhe der Abweichung (pro Zeiteinheit) ist auf jeder
Maschine anders und multipliziert sich entsprechend mit der Uptime.
Auffällig wirds nur, wenn das Datum in der Zukunft liegt oder wenn man
genau hinschaut.
> Wobei man hier ergänzen sollte: 'cut -c' oder andere zeichenabhängiger
> Kram sind immer "fragil". Musterbasierte wie cut -fN -dX, die awk-
> oder sed-Variante sind robuster.
An der Stelle läßt sich auch cut -f1,2,3 -d' ' einsetzen, wenn dir das
besser gefällt. Das fiel mir aber in dem Moment grad nicht ein.
Das ist dann wohl eher Geschmackssache, ob man cut, sed oder awk
einsetzt. Lieber wäre mir an der Stelle eine Bash-Substitution gewesen.
Das wäre die effizientere Art, da dann der zusätzliche Prozeß wegfallen
würde.
Nicht kritischer als die Musterbasierte und fallabhängig zu betrachten,
Syslog schreibt nun mal das Datum in einer konstanten Länge da rein.
Sollte sich dieses ändern, ändert sich mit genauso hoher
Wahrscheinlichkeit auch das Muster.
>>> Mantra: Prozesse starten, Disk- und Console-I/O ist lahm!
>> Dann spar dir doch auch den seq-Aufruf, das kann die bash auch allein. ;-)
>>
>> -- for i in `seq 1 1000`;
>> ++ for i in {1..1000};
>
> Ach, alte Gewohnheit, hab 10 Jahre mit bash-2.x programmiert ... Und
>
> 1. es ist genau 1 Aufruf pro Durchlauf (und nicht _in_ der Schleife)
Das trifft übrigens auch auf das ürsprüngliche Konstrukt zu. Ich wollte
schon am Anfang mal einwerfen, daß die ganze Millisekundenschinderei
hier vollkommen nebensächlich ist, da das real nur ein einzelner Aufruf
sein wird. Wenn du damit anfängst, sei auch bei dir konsequent.
Also sei fair bei dem Vergleich und rechne das genauso hoch für dein seq.
Um mit gleichen Maßstäben zu messen:
~$ time { for i in {1..1000}; do for x in `seq 1 1000`; do :; done; done
> /dev/null; }
real 0m10.996s
user 0m9.581s
sys 0m1.892s
~$ time { for i in {1..1000}; do for x in {1..1000}; do :; done; done >
/dev/null; }
real 0m6.853s
user 0m6.844s
sys 0m0.000s
> Noch ein Mantra/ne Faustregel: wer in einer Pipe mehr als genau ein
> 'cut', 'sed', 'awk' oder 'perl' (python) verwendet, der macht was
> falsch. Mit dem jew. nächstgenannten Tool kann man eigentlich immer
> das geforderte effektiver erledigen.
Naja, für einen schnellen Hack ist es manchmal besser ein paar
Millisekunden CPU-Zeit zu verbraten, als einen Tag über die optimale
Lösung zu grübeln.
Auch ein Mantra: So gut wie nötig, nicht so gut wie möglich.
> $ seq 10 | headntail -2 | xargs
> 1 2 9 10
Wozu braucht man das?
> War auf jedenfall eine sehr lehrreiche awk-Programmierübung für
> mich[3] und ist sogar teils sinnvoll kommentiert ;)
Aha, also ähnlich dem hiesigen Problem, einfach nur aus Spaß am
Programmieren.
> -dnh, der die Tage endlich mal das ISO von seiner ersten Linux-CD
> gezogen hat: Debian-1.3.1_chip_ed.iso vom Dec. 1997 aka "bo" :)
> Auch deswegen lunger ich hier auf der ML rum, obwohl ich aktuell
> kein Debian im Einsatz habe ...
Auch etwa zu der Zeit gestartet, aber zuerst Slackware probiert, schnell
wieder weggeworfen. Danach Suse einige Jahre genutzt und erst mit Debian
so richtig glücklich geworden.
> [0] und mein Hauptrechner davor war seit 2000 ein 500 MHz Athlon, der
> langsamste den's je gab ;) Allerdings hab ich seit ~4 Jahren nen
> Zweitrechner mit nem Athlon 64 X2 3800+EE (2x2.0 GHz), der
> inzwischen nur noch Fileserver macht (und dessen NT zu sterben
> scheint *grumpf*).
Zeit für einen Umstieg. Wenn du die Stromkosten berücksichtigst ist neue
Hardware billiger.
> [3] bei Interesse (->per PM kundtun bitte) mail ich das gern per PM
> oder lad's ggfs. auf meine Webseite.
Wo bleibt der Opensourcegedanke? Legs doch gleich auf die Webseite und
gib der Community etwas zurück. Vielleicht interessieren sich mehr Leute
dafür, als du denkst.
Gruß
Rico
Attachment:
smime.p7s
Description: S/MIME Kryptografische Unterschrift