EIBD auf Arm 100% CPU Last

[NSchnitzler]

Guten Abend,
ich habe auf meinem ODROID U3 EIBD nach folgender Anleitung installiert:
Hausbau, Familie Gruber aus Oggau: Spaßprojekt Hausvisualisierung
gestartet wird der Daemon mit

--daemon --Server --Tunnelling --Discovery --listen-tcp --pid-file=/var/run/eibd.pid --eibaddr=1.1.15 usb:1:4:1:0:0

er hängt eine Gira USB Schnittstelle dran, groupswrite funktioniert auch einwandfrei, nur die CPU Load ist konstant 100% von eibd, auf dem System läuft sonst noch nicht, Das Betriebssystem ist Ubuntu 14.04 LTS (GNU/Linux 3.8.13.16 armv7l).
Weiß jemand Rat, wie man die CPU Last senken kann?

Gruss und Danke

Norbert

[thoms3n]

schau doch mal mit strace was genau im eibd die last verursacht
strace -c -p <pid>


etwas laufen lassen, dann mit strg+c abbrechen, dann müsste eine "Tabelle" mit Verteilung der CPU auf einzelne syscalls kommen.

/ Thomas

[NSchnitzler]

Hi Thomas,

hab ich gemacht:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 34.16    0.005116           0    393712           rt_sigprocmask
 31.33    0.004692           0    393714           rt_sigaction
 11.98    0.001794           0    131250           clock_gettime
  8.25    0.001236           0     65619           select
  8.15    0.001221           0     65619     65619 read
  6.12    0.000917           0     65619           rt_sigpending
  0.00    0.000000           0         6           ioctl
  0.00    0.000000           0        10           gettimeofday
  0.00    0.000000           0         3           poll
------ ----------- ----------- --------- --------- ----------------
100.00    0.014976               1115552     65619 total

Nur was mir sagen soll, weiß ich noch nicht

bei groupread... kommt nur ein send request, aber keine Antwort

[thoms3n]

Hi,

hast du während dem strace irgendwas gemacht also ein groupswrite oder so aufgerufen? Das Verhältnis der einzelnen syscalls scheint zu passen, ist bei meinem eibd zumindest auch so.

Die Frage ist ja was macht der eibd im Leerlauf, dass er auf 100% kommt. Was passiert den wenn du ein strace -p <pid> auf den eibd machst und sonst nichts ausführst?

Hast du den eibd mal "von hand" mit --trace=<level> gestartet um zu schauen ob er direkt was raus schreibt?

/Thomas

[NSchnitzler]

Hi,

ich habe in der Zeit wo Strace lief, nix gemacht, strafe -p liefert:

clock_gettime(CLOCK_MONOTONIC, {871, 776648839}) = 0
rt_sigpending([])                       = 0
read(3, 0x5223c, 128)                   = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGHUP, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_DFL, [], 0x4000000 /* SA_??? */}, 8) = 0
rt_sigaction(SIGINT, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_IGN, [INT], SA_RESTART|0x4000000}, 8) = 0
rt_sigaction(SIGTERM, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_IGN, [TERM], SA_RESTART|0x4000000}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0
select(9, [0 3 7 8], [6], [], {0, 0})   = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0
rt_sigaction(SIGHUP, {SIG_DFL, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [INT], SA_RESTART|0x4000000}, NULL, 8) = 0
rt_sigaction(SIGTERM, {SIG_IGN, [TERM], SA_RESTART|0x4000000}, NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {871, 778941325}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP RTMIN RT_1], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
gettimeofday({1398349962, 111280}, NULL) = 0
gettimeofday({1398349962, 111557}, NULL) = 0
gettimeofday({1398349962, 111651}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {871, 779889486}) = 0
rt_sigpending([])                       = 0
read(3, 0x5223c, 128)                   = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGHUP, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_DFL, [], 0x4000000 /* SA_??? */}, 8) = 0
rt_sigaction(SIGINT, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_IGN, [INT], SA_RESTART|0x4000000}, 8) = 0
rt_sigaction(SIGTERM, {0xb6f8f02d, ~[RTMIN RT_1], 0x4000000 /* SA_??? */}, {SIG_IGN, [TERM], SA_RESTART|0x4000000}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0
select(9, [0 3 7 8], [6], [], {29, 988218}^X^CProcess 3564 detached

mit --trace=debug und -t1023 habe ich kein Logfile hinbekommen, da bräuchte ich noch etwas Unterstützung.

Gruss und danke
Norbert

[thoms3n]

Ich denke da ist möglicherweise dein Problem, der eibd versucht ständig von einer Adresse zu lesen die es nicht gibt:
read(3, 0x5223c, 128) = -1 EAGAIN (Resource temporarily unavailable)

Ich würde mal schauen ob die USB Schnittstelle sauber erkannt wurde, hast du die Patches installiert wie in der Doku angegeben?
Ich habe leider gerade keine USB Schnittelle zum testen, sorry

eibd kannst du mit --trace=1023 starten, ist nur die Frage ob dich die Meldungen weiter bringen...
Vielleicht hat ja noch jemand anders hier im Forum eine Idee was der eibd da so treibt ;-)

/ Thomas

[webhamster]

Hi,
ich hatte das gleiche Problem und habe nach langem zögern und eibd restarts per cronjob nun doch mal zum Debugger gegriffen.

Das Problem liegt im schedule, genauer gesagt in der Datei pth_sched.c Zeile 593 von pthsem-2.0.8.

Beim Pollen ohne Pause scheint der Raspberry CPU zu brauchen, ein PC nicht (oder weniger). Mein Fix war ein Einfügen der Wartezeit

if (dopoll) {
/* do a polling with immediate timeout,
i.e. check the fd sets only without blocking */
pth_zero_time(&delay);
delay.tv_sec = 0; <-- diese beiden Zeilen einfügen
delay.tv_usec = 999;
pdelay = &delay;
}

danach neu bauen, eibd restarten und die Last sinkt zumindest auf < 20%. Kein Fix aber besser als nichts.

Nachtrag: ich habe nach der (sehr guten) Anleitung von http://www.web-dreamer.de/blog/2013/...atch-fhem.html gebaut

VG
Thomas

[chrisman]

Hi,
auch ich habe das gleiche Problem, allerdings nicht auf einem RPi sondern auf einem Odroid U3, auch ARM.
Die strace Outputs sehen bei mir genauso aus. Mit --trace=1023 kommt im Leerlauf keine Ausgabe, trotz 100% Last.

Das hört sich nach einem guten workaround an. Ich werde es gleich ausprobieren.

Gibt es eigentlich Alternativen zum guten alten eibd?

Gruß
Chrisman

[chrisman]

Sehr gut!
Mit dieser Änderung hat er jetzt konstant nur noch 5% CPU Last bei mir. Wie groß ist die Verzögerung? 999 ms oder 999µs. Letzteres wäre ja nicht spürbar und liesse sich noch erhöhen.

Vielen Dank für diesen Tipp, auch wenn es sich immernoch nicht ideal anfühlt...

[chrisman]

also, der delay.tv_usec Wert steht für Mikrosekunden, den habe ich bei mir auf 9999 erhöht also ca. 10ms.
Die CPU-Last ist dadurch bei mir von 5% auf unter 1% gesunken. Verzögerungen bemerke ich nicht.

Von daher kann ich diesen workaround jedem empfehlen, der das gleiche Problem hat:

pth_sched.c Zeile 593 (pthsem-2.0.8)

if (dopoll) {
/* do a polling with immediate timeout,
i.e. check the fd sets only without blocking */
pth_zero_time(&delay);
delay.tv_sec = 0; <-- diese beiden Zeilen einfügen
delay.tv_usec = 9999;
pdelay = &delay;
}


VG
Chrisman

[staehler]

Super Tipp, hat bei mir auch geklappt (Raspi 3). Der eibd hat zuerst die komplette CPU gefressen, jetzt begnügt er sich mit 1-2%. eibd scheint normal zu reagieren.
Danke!!

[staehler]

Hmmm, leider zu früh gefreut. Leseversuche scheitern, die ETS zeigt bei jedem Leseversuch "Ungültiger Frame". Ich versuche jetzt mein Glück mal mit dem knxd nach folgender Anleitung.