[Muratti] hrtimer Problem?

[Peter Plessas]

* Martin Schitter <ms at mur.at> [2012-05-14 14:40]:
> Am 2012-05-14 12:52, schrieb Peter Plessas:
> >meine Screen-Session auf weide wird total langsam, so also ob die Netwerk Verbindung zu wäre.
> >Aber paralleles Einloggen ohne Screen Session geht in normaler Geschwindigkeit.
> 
> das halte ich für kein besonders großes problem, da ja screen
> ohnehin einen ziemlicher müll ist, ohne den man ganz gut leben
> kann... ;)

Warum ist es Müll?
Was sind denn brauchbarere Alternative zu screen?

> >dmesg liefert:
> >[112808.994497] hrtimer: interrupt took 72399169 ns
> >[831294.907857] mutt[26873]: segfault at 50 ip 000000000044799b sp 00007fffc294a530 error 4 in mutt-org[400000+d2000]
> >wobei keiner meiner vier mutts eine PID 26873 hatte, sofern das die PID überhaupt ist.
> 
> um welche zeitpunkte geht's hier überhaupt?
> 
> ms at weide:~$ python
> Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17)
> [GCC 4.6.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time
> >>> start = time.time() - float(open('/proc/uptime').read().split()[0])
> >>> time.ctime(start)
> 'Sun Apr 29 21:07:17 2012'
> >>> time.ctime(start+112808.994497)
> 'Tue May  1 04:27:26 2012'
> >>> time.ctime(start+831294.907857)
> 'Wed May  9 12:02:12 2012'
> 
> die hrtimer-warnung stammt also vom 1.mai, und auch der betroffene
> mutt-absturz liegt fast eine woche zurück...
> 
> eine einmalige interrupt-verzögerungerungn von 72ms innerhalb einer
> virtuellen instanz dürfte im übrigen auch nicht unbedingt zu jenen
> problemen gehören, die uns große kopfzerbrechen bereiten sollten...
Gut! Danke für den Hinweis auf die tatsächliche Zeit (und das Beispiel
in python).

> >Die Verbindung/das Verhalten ist auch langsam, wenn ich die betroffene Screen-Session beende.
> >Parallel dazu kann ich weiterhin in einem anderen ssh-login Fenster auf weide super weitertippen.
> >
> >Vielleicht ist es ein ssh Problem?
> 
> ja -- das ist schon möglich...
> das kann aber sehr gut auch auf deiner seite seine ursachen haben!;)
> 
> >Sshguard?
> 
> eher nicht. sshguard funktioniert sehr einfach: schaut nur laufend
> die logeinträge durch und setzt bei bedarf regeln in den iptables...
> 
> >Oder vielleicht
> >https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/503138
> >oder
> >http://www.mail-archive.com/kvm@vger.kernel.org/msg22925.html
> 
> das betrifft uralte bug reports, die nur mehr sehr wenig mit den
> hier laufenden kernel bzw. kvm-versionen gemeinsam haben dürften...
> 
> wobei ich demnächst endlich wieder entsprechende updates am wald
> durchführen möchte, um einiges an verbesserungen und neuen features
> einfließen zu lassen (bsp. verschachtelte virtualisierung und
> openvswich-support), nur gibt's leider noch immer kein fertiges
> 3.3er packerl in debian testing od. unstable, während auf
> upstream-seite bereits in wenigen tagen wieder der fertige 3.4er
> kernel herauskommen dürfte...:(

Kannst Du zusammenfassend sagen, was Deiner Meinung nach das Problem
(zum wiederholten Male) verursacht, oder was Du oder ich tun kann?

freut sich 
mit herzlichem Dank für die fabelhafte Behandlung dieses Problemes,

Peter

> 
> martin
> _______________________________________________
> Muratti mailing list
> Muratti at mur.at
> http://lists.mur.at/mailman/listinfo/muratti