[FRAGE] Rechnerauslastung CAPI

[stefanwillmerot]

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?

 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

 

[Numsi]

Fehlermeldungen vom asterisk?
Faxt du darueber auch?
Firmware der b1 Karten aktuell? (ftp.in-berlin.de)

 

[stefanwillmerot]

Fehlermeldungen vom asterisk?

Oh ja und wie!
Aber sie kommen erst wenn die Systemauslastung maximal ist, vorher läuft alles wie geschmiert.

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]

Faxt du darueber auch?

Ja, es werden Faxe per CapiCommand(receivefax) empfangen, das klappt gut.

Firmware der b1 Karten aktuell? (ftp.in-berlin.de)

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:

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)

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

 

[Numsi]

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

 

[Numsi]

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.

 

[stefanwillmerot]

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%.

 

[Numsi]

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)?

 

[detejo]

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:

 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

#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?

 

[spongebob]

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.

 

[Numsi]

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.

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.