HbbTV: hoher CPU-Verbrauch

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • HbbTV: hoher CPU-Verbrauch

      Obwohl HbbTV gar nicht aufgerufen wurde, verbraucht es im Hintergrund fast 50% der CPU-Zeit, wie man mit "top" sieht.

      Was treibt das da???
      Dateien

      • hbbtv.png

        (122,22 kB, 1.890 mal heruntergeladen, zuletzt: )

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bergschreck ()

    • RE: HbbTV: hoher CPU-Verbrauch

      hmm, ich habe das 4.2 mal auf meine Uno installiert. Mir kommt vor wie wenn die jetzt schneller umschalten täte als vorher mit dem 4.1.
      Gut, kann natürlich auch sein, dass mein 4.1 schon ein wenig "verhunzt" war.
      Ob das FPGA-Update da auch eine Rolle spielt kann ich nicht sagen.
      Radar

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Radar ()

    • RE: HbbTV: hoher CPU-Verbrauch

      Ja, aber das kann doch nicht die Lösung sein; das sollte mal jemand mit einem funktionierenden "strace" oder "ltrace" protokollieren und schauen, was der Prozess da macht. Meiner zieht sich "nur" etwa 6% CPU-Zeit rein, hab ihn aber auch schon mal auf 49% gehabt. Schaut für mich nach einem Bug bzw. noch nicht ausgereiftem Browser-Support aus.

    • So, ich habe mal in meinem lokalen OE2-Build, den ich mal vor einem halben Jahr gemacht habe, nach ltrace und strace gesucht. Funktionieren beide, sind angehängt.

      @bergschreck: kannst Du z.B. mal das "strace" auf Deine Box packen (mit "ltrace muss man ein bisserl aufpassen, das lässt die Prozesse auch gerne mal im Status "T", die muss man dann mit "kill -CONT <pid>" wieder anschubsen) und dann mal schauen, was der 50%-Prozess so treibt?

      Ich habe das bei mir gerade gemacht:

      Quellcode

      1. ./strace -p 3233 -e \!futex,gettimeofday,clock_gettime
      mit -p gibst Du ihm die Prozess-ID mit, mit -e kannst Du uninteressante Systemcalls wegfiltern. Bei mir bleiben dann noch Aufrufe von "read(9, ...)" und "_newselect(9, ...)" über. Und wenn ich dann ein "ls -l /proc/3233/fd/" eingebe, sehe ich, dass das ein Socket ist, der wohl zur Kommunkation benutzt wird: "/tmp/.sock.hbbtv.cmd|".

      Dieser Read-Select-Sturm sieht für mich nach einem Bug aus.

      Ach ja: das "strace" kann man mit Ctrl-C abbrechen, falls Du es nicht weißt :D
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Cimarast ()

    • Original von UV-X
      So siehts auf der Xtrend 9x00 aus:

      Bei denen habe ich aber gelesen, dass die VU (bzg. HBBTV) was kann was die ET nicht kann.
      Nur, diesbezüglich bin ich eine "0" und habe nicht verstanden um was es da genau geht.
      Radar
      Edit: war irendwo die Rede von einem kleinen Bild

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Radar ()

    • Original von Radar
      Edit: war irendwo die Rede von einem kleinen Bild


      Ich denke hier geht es um die CPU-Belastung, oder nicht? Was hat das mit dem kleinen Bild bei den Privaten zu tun? Nichts! ;)

      Habe das nur als Info gepostet, dass man sich ein Bild machen kann, wie hoch die Belastung bei der Xtrend im Vergleich zur VU+ ist.

    • die UNO/ULTIMO haben doch eine Dual-Core CPU wenn ich mich nicht irre, und diese sind beide ausgelastet ?(
      Lg
      Maxime peccantes, quia nihil peccare conantur!

    • @Cimarast: dauert noch etwas bis ich testen kann. Meine Frauen gucken grad Tatort von Platte an. So wie es aussieht tritt der Fehler nur auf wenn es beim booten automatisch gestartet wird. Starte ich es manuell mit

      Quellcode

      1. /usr/local/hbb-browser/launcher start

      dann tritt der Fehler momentan nicht auf.

      Beim starten gibt es 2 Warnings, haben die was zu bedeuten?

      Quellcode

      1. WARN [ Window] Pending application added when pending already existed.
      2. WARN [ Window] startPendingApplication: application does not matching pending application, aborting.

    • Original von spalki
      die UNO/ULTIMO haben doch eine Dual-Core CPU wenn ich mich nicht irre, und diese sind beide ausgelastet ?(

      Nein. 50% heisst dass eine ausgelastet ist.

    • Original von UV-X
      Original von Radar
      Edit: war irendwo die Rede von einem kleinen Bild


      Ich denke hier geht es um die CPU-Belastung, oder nicht? Was hat das mit dem kleinen Bild bei den Privaten zu tun? Nichts! ;)

      Habe das nur als Info gepostet, dass man sich ein Bild machen kann, wie hoch die Belastung bei der Xtrend im Vergleich zur VU+ ist.


      Bin halt von der Logik ausgegangen, dass wenn die VU mehr kann halt auch mehr CPU-Last verursacht :D
      Radar

    • Original von Radar
      Bin halt von der Logik ausgegangen, dass wenn die VU mehr kann halt auch mehr CPU-Last verursacht :D

      Höchstens dann wenn das auch gerade alles aktiv ist. Prozesse die nur untätig im Hintergrund schlummern dürfen keine Last verursachen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bergschreck ()

    • So, Tatort ist vorbei und ich konnte neu booten.

      Bei mir sind es nur selects, keine reads. Die aber massenhaft.

      Quellcode

      1. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      2. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      3. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      4. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      5. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      6. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      7. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      8. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      9. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      10. _newselect(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout)
      11. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      12. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      13. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      14. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      15. _newselect(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout)
      16. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      17. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      18. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      19. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      20. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      21. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      22. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      23. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      24. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      25. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      26. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      27. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      28. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      29. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      30. _newselect(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout)
      31. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      32. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      33. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      34. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      35. _newselect(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout)
      36. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      37. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      38. _newselect(10, [9], NULL, NULL, {0, 3}) = 0 (Timeout)
      39. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      40. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      41. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      42. _newselect(10, [9], NULL, NULL, {0, 4}) = 0 (Timeout)
      43. _newselect(10, [9], NULL, NULL, {0, 2}) = 0 (Timeout)
      44. _newselect(10, [9], NULL, NULL, {0, 1}) = 0 (Timeout)
      45. _newselect(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout)
      46. _newselect(7, [6], [], [6], {0, 0}) = 0 (Timeout)
      47. ^CProcess 818 detached
      48. root@vuultimo:~# ls -l /proc/818/fd
      49. lrwx------ 1 root root 64 Aug 28 16:56 0 -> /dev/fb0
      50. lrwx------ 1 root root 64 Aug 28 16:56 1 -> /dev/console
      51. lrwx------ 1 root root 64 Aug 28 16:56 2 -> /dev/console
      52. lrwx------ 1 root root 64 Aug 28 16:56 3 -> /dev/input/event0
      53. lr-x------ 1 root root 64 Aug 28 16:56 4 -> pipe:[2715]
      54. lrwx------ 1 root root 64 Aug 28 16:56 40 -> /tmp/ffiXTqBtm (deleted)
      55. l-wx------ 1 root root 64 Aug 28 16:56 5 -> pipe:[2715]
      56. lr-x------ 1 root root 64 Aug 28 16:56 6 -> pipe:[2719]
      57. l-wx------ 1 root root 64 Aug 28 16:56 7 -> pipe:[2719]
      58. lr-x------ 1 root root 64 Aug 28 16:56 8 -> /usr/local/hbb-browser/root/skin/standard_skin.zip
      59. lr-x------ 1 root root 64 Aug 28 16:56 9 -> /tmp/.sock.hbbtv.cmd
      Alles anzeigen

    • Du hast gesagt, das passiert nicht, wenn hbbtv nach dem Booten von Hand gestartet wird; kannst Du in dem Fall mal ein "strace" auf den Prozess mit der niedrigsten Prozess-ID laufen lassen? Sieht es dann genauso aus?

    • Ja, hab's grad gemacht. Sieht dann aber genauso aus.
      Es startet zuerst ebenfalls mit hoher CPU-Last, geht aber dann nach 10-20 Sekunden auf ca. 3% zurück.

    • Lass doch bitte mal in den beiden Fällen für 10 Sekunden ein "strace -p <pid> -c" laufen. Meins sieht etwa so aus:

      Brainfuck-Quellcode

      1. % time seconds usecs/call calls errors syscall
      2. ------ ----------- ----------- --------- --------- ----------------
      3. 66.96 0.072129 17 4182 1674 futex
      4. 19.89 0.021428 1 16039 gettimeofday
      5. 5.47 0.005893 2 2611 _newselect
      6. 4.08 0.004399 2 2508 clock_gettime
      7. 3.60 0.003875 2 2508 read
      8. 0.00 0.000000 0 5 time
      9. 0.00 0.000000 0 1 1 restart_syscall
      10. ------ ----------- ----------- --------- --------- ----------------
      11. 100.00 0.107724 27854 1675 total
      Alles anzeigen