.titleBar { margin-bottom: 5px!important; }

[FRAGE] Rechnerauslastung CAPI

Dieses Thema im Forum "Asterisk ISDN mit CAPI (chan_capi, chan_capi_cm)" wurde erstellt von stefanwillmerot, 28 Nov. 2006.

  1. stefanwillmerot

    stefanwillmerot Neuer User

    Registriert seit:
    6 Okt. 2006
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Amsterdam
    Hallo Forum,

    mich würde mal interessieren was Ihr so für CPU-Last habt wenn mehrere CAPI-Telefonate laufen. Auf meiner Maschine sind 3 AVM B1 für die Amtsanbindung zuständig. Die Kiste ist ein zugegebenermassen betagter 333-Mhz-P2, die Karten sind ISA. Trotzdem reden wir hier ja nun nicht gerade über unglaubliche Datenraten. Ein aktiver ISDN-Kanal bringt aber bereits 20% Auslastung (5% User, 15% System). Bei vier Gesprächen ist die Kiste dicht und verliert schon Pakete, das fünfte bewirkt dass die Leute wieder auflegen weil man "so" nicht mehr telefonieren kann.

    Interne Telefonate (SIP) sowie Internet-Telefonate machen der Maschine hingegen garnix aus.

    Ich kann das irgendwie nicht glauben, dass chan_capi und CAPI soviel Rechenleistung brauchen... und das bei den "tollen aktiven AVM Karten"...

    Aufrüsten heisst natürlich: neuen PC kaufen, 4-fach-ISDN kaufen, alles neu installieren... muss das sein?

    Code:
     cat /proc/interrupts
               CPU0
      0:  397857298          XT-PIC  timer
      1:         11          XT-PIC  keyboard
      2:          0          XT-PIC  cascade
      3:    3988136          XT-PIC  b1isa-300
      5:    2390449          XT-PIC  b1isa-150
      7:    1442212          XT-PIC  b1isa-250
      8:          2          XT-PIC  rtc
     10:    9201187          XT-PIC  eth0
     12: 3145814083          XT-PIC  zaphfc
     14:     376945          XT-PIC  ide0
     15:          2          XT-PIC  ide1
    
     
  2. Numsi

    Numsi Mitglied

    Registriert seit:
    24 Jan. 2005
    Beiträge:
    215
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Fehlermeldungen vom asterisk?
    Faxt du darueber auch?
    Firmware der b1 Karten aktuell? (ftp.in-berlin.de)
     
  3. stefanwillmerot

    stefanwillmerot Neuer User

    Registriert seit:
    6 Okt. 2006
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Amsterdam
    #3 stefanwillmerot, 28 Nov. 2006
    Zuletzt bearbeitet: 28 Nov. 2006
    Oh ja und wie! :)
    Aber sie kommen erst wenn die Systemauslastung maximal ist, vorher läuft alles wie geschmiert.
    Code:
    Nov 27 14:44:04 ERROR[17518] chan_capi.c: Could not write to pipe for T2#02
    Nov 27 14:44:04 ERROR[17518] chan_capi.c: Could not write to pipe for T2#02
    Nov 27 14:44:05 ERROR[17518] chan_capi.c: Could not write to pipe for T2#02
    Nov 27 14:44:05 ERROR[17518] chan_capi.c: Could not write to pipe for T2#02
    Nov 27 14:49:47 ERROR[18168] chan_capi.c: CAPI error sending DATA_B3_REQ ID=002 #0x5b45 LEN=0030
      Controller/PLCI/NCCI            = 0x20201
      Data32                          = 0x81ad9bc
      DataLength                      = 0xa0
      DataHandle                      = 0x5d3
      Flags                           = 0x0
      Data64                          = 0x0
     (NCCI=0x20201) (error=0x1103 The message could not be accepted because of a queue full condition !! The error code does not imply that CAPI cannot receive messages directed to another controller, PLCI or NCCI)
    Nov 27 14:49:47 ERROR[17999] chan_capi.c: CAPI error sending DATA_B3_REQ ID=002 #0x5b4c LEN=0030
      Controller/PLCI/NCCI            = 0x10101
      Data32                          = 0x81b4e44
      DataLength                      = 0xa0
      DataHandle                      = 0xe5e8
      Flags                           = 0x0
      Data64                          = 0x0
     (NCCI=0x10101) (error=0x1103 The message could not be accepted because of a queue full condition !! The error code does not imply that CAPI cannot receive messages directed to another controller, PLCI or NCCI)
    Nov 27 14:49:47 ERROR[18168] chan_capi.c: CAPI error sending DATA_B3_REQ ID=002 #0x5b51 LEN=0030
      Controller/PLCI/NCCI            = 0x20201
      Data32                          = 0x81add3c
      DataLength                      = 0xa0
      DataHandle                      = 0x5d7
      Flags                           = 0x0
      Data64                          = 0x0
     (NCCI=0x20201) (error=0x1103 The message could not be accepted because of a queue full condition !! The error code does not imply that CAP
    ...
    Nov 27 16:51:07 WARNING[18853] frame.c: Smoother was working on 8 format frames, now trying to feed 64?
    Nov 27 16:51:07 ERROR[18853] chan_capi.c: T1#02: failed to fill smoother
    Nov 27 16:51:07 WARNING[18853] frame.c: Smoother was working on 8 format frames, now trying to feed 64?
    Nov 27 16:51:07 ERROR[18853] chan_capi.c: T1#02: failed to fill smoother
    Nov 27 16:51:07 WARNING[18853] frame.c: Smoother was working on 8 format frames, now trying to feed 64?
    Nov 27 16:51:07 ERROR[18853] chan_capi.c: T1#02: failed to fill smoother
    
    [/QUOTE]
    Ja, es werden Faxe per CapiCommand(receivefax) empfangen, das klappt gut.
    Leider nein, mit aktuelleren Firmwarefiles hängt sich das Inserting der Treiber schlicht auf. Ich konnte nicht herausfinden, welche Firmware für die B1 Version 2.0 die aktuellste ist.
    So schaut das Laden der Treiber aktuell aus:
    Code:
    Nov 23 22:10:40 asterisk kernel: CAPI-driver Rev 1.1.4.1 : unloaded
    Nov 23 22:10:43 asterisk kernel: CAPI-driver Rev 1.1.4.1: loaded
    Nov 23 22:10:43 asterisk kernel: capifs: Rev 1.1.4.1
    Nov 23 22:10:43 asterisk kernel: capi20: started up with major 68
    Nov 23 22:10:43 asterisk kernel: kcapi: capi20 attached
    Nov 23 22:10:43 asterisk kernel: capi20: Rev 1.1.4.2: started up with major 68 (middleware+capifs)
    Nov 23 22:10:43 asterisk kernel: CSLIP: code copyright 1989 Regents of the University of California
    Nov 23 22:10:43 asterisk kernel: ISDN subsystem Rev: 1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1 loaded
    Nov 23 22:10:43 asterisk kernel: Network dial timeout is set to 10 sec
    Nov 23 22:10:43 asterisk kernel: kcapi: capidrv attached
    Nov 23 22:10:43 asterisk kernel: kcapi: appl 1 up
    Nov 23 22:10:43 asterisk kernel: capidrv: Rev 1.1.4.1: loaded
    Nov 23 22:10:44 asterisk kernel: b1: revision 1.1.4.1
    Nov 23 22:10:44 asterisk kernel: b1isa: revision 1.1.4.1
    Nov 23 22:10:44 asterisk kernel: kcapi: driver b1isa attached
    Nov 23 22:10:44 asterisk kernel: kcapi: Controller 1: b1isa-150 attached
    Nov 23 22:10:44 asterisk kernel: b1isa: AVM B1 ISA at i/o 0x150, irq 5, revision 255
    Nov 23 22:10:45 asterisk kernel: kcapi: Controller 2: b1isa-250 attached
    Nov 23 22:10:45 asterisk kernel: b1isa: AVM B1 ISA at i/o 0x250, irq 7, revision 255
    Nov 23 22:10:46 asterisk kernel: kcapi: Controller 3: b1isa-300 attached
    Nov 23 22:10:46 asterisk kernel: b1isa: AVM B1 ISA at i/o 0x300, irq 3, revision 255
    Nov 23 22:10:48 asterisk kernel: b1isa-150: card 1 "B1" ready.
    Nov 23 22:10:48 asterisk kernel: b1isa-150: card 1 Protocol: DSS1
    Nov 23 22:10:48 asterisk kernel: b1isa-150: card 1 Linetype: point to point
    Nov 23 22:10:48 asterisk kernel: b1isa-150: B1-card (3.09-10) now active
    Nov 23 22:10:48 asterisk kernel: kcapi: card 1 "b1isa-150" ready.
    Nov 23 22:10:48 asterisk kernel: kcapi: notify up contr 1
    Nov 23 22:10:48 asterisk kernel: capidrv: controller 1 up
    Nov 23 22:10:48 asterisk kernel: capidrv-1: now up (2 B channels)
    Nov 23 22:10:48 asterisk kernel: capidrv-1: D2 trace enabled
    Nov 23 22:10:48 asterisk kernel: capi: controller 1 up
    Nov 23 22:10:50 asterisk kernel: b1isa-250: card 2 "B1" ready.
    Nov 23 22:10:50 asterisk kernel: b1isa-250: card 2 Protocol: DSS1
    Nov 23 22:10:50 asterisk kernel: b1isa-250: card 2 Linetype: point to point
    Nov 23 22:10:50 asterisk kernel: b1isa-250: B1-card (3.09-10) now active
    Nov 23 22:10:50 asterisk kernel: kcapi: card 2 "b1isa-250" ready.
    Nov 23 22:10:50 asterisk kernel: kcapi: notify up contr 2
    Nov 23 22:10:50 asterisk kernel: capidrv: controller 2 up
    Nov 23 22:10:50 asterisk kernel: capidrv-2: now up (2 B channels)
    Nov 23 22:10:50 asterisk kernel: capidrv-2: D2 trace enabled
    Nov 23 22:10:50 asterisk kernel: capi: controller 2 up
    Nov 23 22:10:52 asterisk kernel: b1isa-300: card 3 "B1" ready.
    Nov 23 22:10:52 asterisk kernel: b1isa-300: card 3 Protocol: DSS1
    Nov 23 22:10:52 asterisk kernel: b1isa-300: card 3 Linetype: point to multipoint
    Nov 23 22:10:52 asterisk kernel: b1isa-300: B1-card (3.09-10) now active
    Nov 23 22:10:52 asterisk kernel: kcapi: card 3 "b1isa-300" ready.
    Nov 23 22:10:52 asterisk kernel: kcapi: notify up contr 3
    Nov 23 22:10:52 asterisk kernel: capidrv: controller 3 up
    Nov 23 22:10:52 asterisk kernel: capidrv-3: now up (2 B channels)
    Nov 23 22:10:52 asterisk kernel: capidrv-3: D2 trace enabled
    Nov 23 22:10:52 asterisk kernel: capi: controller 3 up
    
    So sieht die Auslastung bei 3 Gesprächen aus (6 aktive Channels)

    Code:
    top - 16:41:17 up 4 days, 19:04,  1 user,  load average: 0.40, 0.46, 0.21
    Tasks:  72 total,   3 running,  69 sleeping,   0 stopped,   0 zombie
    Cpu(s):   9.7% user,  74.0% system,   0.0% nice,  16.3% idle
    Mem:    126352k total,   120396k used,     5956k free,    39064k buffers
    Swap:  1036152k total,     3184k used,  1032968k free,    49096k cached
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    22425 root      20   0  9476 9472 4880 R 26.4  7.5   0:02.31 asterisk
    17518 root      17   0  9476 9472 4880 R 21.1  7.5  14:14.30 asterisk
    22394 root      16   0  9476 9472 4880 S 12.9  7.5   0:35.83 asterisk
    22380 root      16   0  9476 9472 4880 S  9.4  7.5   0:45.91 asterisk
    22435 root      17   0   940  940  744 R  3.1  0.7   0:00.43 top
        1 root      15   0    88   72   52 S  0.3  0.1   0:06.38 init
        3 root      15   0     0    0    0 S  0.3  0.0   7:01.65 kapmd
      316 root      16   0  1668 1668  892 S  0.3  1.3   0:15.42 isdnlog
    17517 root      15   0  9476 9472 4880 S  0.3  7.5   2:29.33 asterisk
        2 root      15   0     0    0    0 S  0.0  0.0   0:00.02 keventd
        4 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd_CPU0
        5 root      15   0     0    0    0 S  0.0  0.0   0:01.87 kswapd
        6 root      25   0     0    0    0 S  0.0  0.0   0:00.00 bdflush
    
    merci!
    Stefan
     
  4. Numsi

    Numsi Mitglied

    Registriert seit:
    24 Jan. 2005
    Beiträge:
    215
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Aua:
    CAPI error sending DATA_B3_REQ
    Das ist uebel...
    <zitat>
    5) Änderungen der Packetgröße in dem Quellcode von chan_capi:
    Bei passiven isdn/capi Karten wird die Anzahl der Buffer worin die Daten abgelegt werden mittels Software gelöst!
    Bei aktiven Karten ist das durch den verbauten Hardwarespeicher begrenzt! Bei der AVMb1 existieren z.B. 8 Buffer.
    Basierend darauf ist es bei aktiven Karten wichtig nicht zu kleine Packete zu senden das sonst die Buffer ueberlaufen und es zum Fehler kommt.
    Die Fehlermeldung lautet: "error DATA_B3_REQ (error=1103, datalen=160) auf der Asterisk-Konsole.
    Wobei: 0x1103 == capi send queue full und die 160 die übertragene Packetgröße ist.
    Passive Karten scheinen da flexibler zu sein was die Anzahl der Buffer betrifft.
    Nachdem die Buffergroesse im chan_capi_pvt.h größer 200 gesetzt wird, nahm zwar die Latenzzeit zu aber die Audioqualitaet auch.
    Unter Zuhilfenahme der Echoparameter in der capi.conf kann man nun, was das telefonieren betrifft, super Ergebnisse erzielen.
    Diverse Telefonate zum Testen ergaben: die Gesprächspartner haben nicht gemerkt, das dort ein PC mit einer ISDN Karte dazwischen hing.
    </zitat>
    Ob damit faxen noch geht, keine Ahnung aber alles andere sollte besser werden.

    Firmware:
    b1isa-150: B1-card (3.09-10) now active
    Die ist schon was aelter...
    Damit kannst du bei AVM nicht mal nachfragen bzgl. Support
     
  5. Numsi

    Numsi Mitglied

    Registriert seit:
    24 Jan. 2005
    Beiträge:
    215
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #5 Numsi, 28 Nov. 2006
    Zuletzt bearbeitet: 28 Nov. 2006
    Nachtrag zur Firmware:
    Ich nutze bei meinem alten Testgeraffel immer die aktuellste.
    Es gibt keine spezielle fuer V1,2,3,4 isa/pci oder sonstnochwas.
    Selbst meine b1pcmcia rennt mit der 3-11-03

    Zu deiner Packetlaenge (30) ist zu sagen: bannig klein!
    Du hast keinen Einfluss darauf aber du solltest damit mal ein bischen rumspielen und beobachten ob es besser wird bei groesseren Packeten.
    Achte auf deine Faxe, das habe ich nicht probiert wo da die Schmerzgrenze liegt.
    Original war die Packetgroesse mal bei 160 vom Junghanns eingebaut worden.
    Selbiger hat allerdings NIE mit aktiven Karten probiert!

    Ein paar links noch dazu:
    http://www.ip-phone-forum.de/showthread.php?t=116085
    http://www.ip-phone-forum.de/showthread.php?t=103010
    http://www.ip-phone-forum.de/showthread.php?t=113754
    Und die Quelle meines Zitats:
    http://hebric.dyndns.org/pub/voip/pics-isdn-cards/isdn-kartentest.pdf
    Der Test ist alt (und ich werde keinen mehr anfangen) aber er basiert auf Infos von Calle Paeth von AVM bzgl. der Buffer in passiven/aktiven AVM Karten und der Fehlermeldungen daraus.
     
  6. stefanwillmerot

    stefanwillmerot Neuer User

    Registriert seit:
    6 Okt. 2006
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Amsterdam
    #6 stefanwillmerot, 28 Nov. 2006
    Zuletzt bearbeitet: 28 Nov. 2006
    Die Idee mit der Paketlänge ist interessant. Bislang war 160 in chan_capi.h eingestellt, bei 320 sinkt die Prozessorauslastung auf ca 15% pro Gespräch (allerdings mit schon merklicher Latenz). Das ist noch keine perfekte Lösung, zeigt aber, dass es in der Tat etwas mit der Last in CAPI oder chan_capi zu tun hat. Warum bei den Fehlermeldungen die Pakete nur 30 Bytes klein waren, ist mir nicht klar. Diese Meldungen erscheinen aber nur wenn die Maschine überlastet ist.

    Nachtrag: Nur die ausgehende Paketgrösse scheint betroffen, bei show channel im CLI steht:
    Frames in: 19126
    Frames out: 38250
    Elapsed Time: 0h12m27s
    Daher hat sich die Last eben auch nur um 25% vermindert und nicht um 50%.
     
  7. Numsi

    Numsi Mitglied

    Registriert seit:
    24 Jan. 2005
    Beiträge:
    215
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Evtl. ist der chan-capi clever genug die Packetgroesse zu reduzieren, nach dem Motto: mehr ist nicht frei, also machen wir kleinere...
    Das sind Dinge, die koennte Armin vielleicht beantworten.
    Aber es zeigt sich deutlich, das die aktiven AVMs nicht so einfach sind.
    Bist du sicher das die 3 ISAs in dem System einen sauberen IRQ bekommen?
    Meistens sind da doch schon geteilte Slots mit irgendeinem PCI/Sound/USB usw. dabei was man !so! von aussen nicht sehen kann.
    Sind eigentlich alle 3 Karten mit dem Problem behaftet?
    Kannst mal eine austauschen und als PCI probieren (aktiv oder passiv)?
     
  8. detejo

    detejo Mitglied

    Registriert seit:
    17 Juli 2006
    Beiträge:
    502
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #8 detejo, 3 März 2007
    Zuletzt bearbeitet: 4 März 2007
    also um hier mal einen neuen Aspekt reinzubringen:
    die bisherigen Threads und Workarounds, die sich damit beschäftigen, gingen immer davon aus, dass das Problem in der mangelnden Größe der Hardware-Puffer der B1 gebründet liegt.
    Ich habe hier aber eine AVM A1 Fritz!Card PCI und bei langen Gesprächen - also so etwas ab 30min aufwärts hagelt auch diese Fehlermeldungen:

    Code:
     Controller/PLCI/NCCI            = 0x10101
      Data32                          = 0x81608ec
      DataLength                      = 0x140
      DataHandle                      = 0x86bf
      Flags                           = 0x0
      Data64                          = 0x0
     (NCCI=0x10101) (error=0x1103 The message could not be accepted because of a queue full condition !! The error code does not imply that CAPI cannot receive messages directed to another controller, PLCI or NCCI)
    ERROR[8550]:chan_capi.c:439 _capi_put_cmsg: CAPI error sending DATA_B3_REQ ID=003 #0x870a LEN=0030
    
    die Sprache wird dann total zerhackt - und zwar nur in Senderichtung.
    Das ist besonders blöd, weil ich es selbst akustisch gar nicht mitbekomme.

    Das Erhöhen der Blockgröße in chan_capi.h
    Code:
    #define CAPI_MAX_B3_BLOCK_SIZE          320
    hat nichts gebracht.

    Anhand des Quellcodes von chan_capi 1.0.0 und des Fritz-Codes ist es so: die Meldung kommt vom AVM-Treiber und wird nur durchgereicht. Das deckt sich mit meiner Erfahrung, dass es bei chan_capi_cm 0.6.5, 0.7.0 und 0.7.1 genau das gleiche war.

    Was ich nicht verstehe:

    Wieso "LEN = 0030" - was für eine Länge ist das und kann man nicht da ansetzen?
    Wenn es auch bei meiner Fritz!Card PCI auftritt, dann kann der zu kleine Hardware-Buffer der B1 nicht die Ursache sein, denn diesen hat die Fritz!Card nicht?
    Generelles Treiber-Problem - sollte ich mich an AVM wenden?
     
  9. spongebob

    spongebob Aktives Mitglied

    Registriert seit:
    22 Sep. 2004
    Beiträge:
    1,287
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Die CAPI Meldung zeigt, dass die Quelle mehr Daten erzeugt, als die Source abdrainen kann. In diesem Fall würde ich * als Quelle und die ISDN Karte in Senderichtung als Source betrachten.

    Die Anzahl und Grösse der DB3 Queues ist (wenn ich mich recht erinnere) aber beim CAPI_REGISTER einstellbar. Allerdings erhöhen grosse Puffer und Messagegrössen auch die Latenz.

    Ich würde nach dem letzten Beitrag auch dazu tendieren, den HW-Buffer der B1 nicht für die Ursache zu halten, sondern eine möglicherweise problematische Ansteuerung der ISDN Karten.
     
  10. Numsi

    Numsi Mitglied

    Registriert seit:
    24 Jan. 2005
    Beiträge:
    215
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also das mit der Puffergroesse habe ich mir nicht aus den Rippen geschnitzt.
    Diesbezueglich hatte ich mich an AVM, speziell an Calle Paeth gewand (avmb1-Mailinglistenbetreiber und _der_ Mann der den b1-Krempel in den Kernel brachte)
    Selbiger hatte mir das mit den Puffergroessen erklaert und mir dann noch nebenbei den Testaufbau erlaeutert.
    Bei AVM hat man ein Proggi gebaut was just die Karte(n) mit den Samples bombadiert um herauszufinden ob das alles zusammen, stabil funktioniert.
    Was ich allerdings noch zu bedenken geben moechte ist "die Last der Interupts".
    Ich hatte da mal was zusammengeschrieben; es ging um Chipsaetze usw.
    Ok, es hilft nicht wirklich das Problem ad hoc zu loesen aber evtl. erweitert es die Sichtweise auf selbiges.