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

HFC Interrupts

Dieses Thema im Forum "Asterisk ISDN mit Bristuff (hfc, zaptel)" wurde erstellt von smartbyte, 2 März 2005.

  1. smartbyte

    smartbyte Neuer User

    Registriert seit:
    21 Dez. 2004
    Beiträge:
    35
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo Leute,

    nach einigen Experimenten mit meinem Linux-Asterisk-Server habe ich gemerkt, dass Asterisk grosse Probleme bekommt, wenn ich den Server ein bisschen belaste (einen Atlhon 64 2800+). Vor allen Dingen sobald man die Interrupt-Zugriffe des Servers mal für andere Dinge, z.B. Festplatten benötigt. Nach ein bisschen Forschungsarbeit war das Problem auch schnell ausfindig zu machen. Der Zaphfc-Treiber benutzt Interrupts der HFC-Karte als Timer um das ISDN-Protokoll zu syncronisieren.
    Das ist anstrengend für das System. Im neusten bristuff hat sich der Programmierer auch darum gekümmert und den rtai-Treiber als Realtime-Timer eingesetzt (anstatt der vielen Interrupt-Aufrufe). Das Problem dabei ist allerdings, dass dieser Treiber einen Kernelpatch benötigt und viel zu gross dafür ist, dass er eigentlich nur als timer dienen soll (und ich ihn einfach nicht kompiliert bekomme:-( ).
    Daraufhin habe ich mich wieder auf die Suche in der allwissenden Müllhalde (auch Internet genannt) gemacht und das ztdummy-Modul gefunden, dass nur dafür da ist genau diese Timing-Tätigkeit zu vollführen, wobei es den ztdummy wieder in zwei Versionen gibt. Einmal für den 2.4er Kernel (USB-Kontroller abhängig) und einmal für den 2.6er Kernel. Das Modul für den 2.6er Kernel soll nun wieder von dem USB-Port unabhängig sein, und direkt mit der RTC im 2.6er Kernel zusammenarbeiten, der dafür angeblich eine ausreichende Genauigkeit besitzt.
    Und nun meine Frage: Kann mir einer erklären, warum der HFC-Treiber nicht auch einfach die RTC vom Server als Timing-Quelle benutzt?
    (Bitte, mein Server macht "nebenbei" noch andere Sachen ausser Asterisk, warum muss man über diese komplizierten Weg ein Timing-Signal generieren, dass meine VoIP-Verbindung so anfällig macht?)

    Hat jemand einen direkten Draht zum Programmierer, oder kann mir kurz erklären, warum das so nicht geht, was ich mir da ausgedacht habe?

    Danke schoneinmal.

    Ciao.
     
  2. rajo

    rajo Admin-Team

    Registriert seit:
    31 März 2004
    Beiträge:
    1,958
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    den direkten Draht bekommst Du auf irc.freenode.net in #asterisk-drinkers :)
     
  3. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Guter Punkt, smartbyte!

    Zugegebenermassen weiss ich die Antwort auch nicht, erinnere mich aber noch aus alten Tagen, dass der RTC-Interrupt mit niedriger Priorität läuft und allen anderen Interrupts hinterher läuft. Das Problem ist, dass ich nicht mehr weiss ob das irgendwann softwareseitig einstellbar geworden ist. Kann gut sein, ich weiss es aber nicht.

    Falls mich also mein Gedächtnis nicht trügt, ist man mit dem RTC-Interrupt auf einem belasteten System wesentlich schlechter dran als mit den anderen Interrupts. Deshalb hatte mir klein-Erna-mäßig immer irgendwie eingeleuchtet, dass man den Umweg über den USB-Controller, ISDN-Karte usw geht um einen anständigen Takt zu bekommen.

    Übrigens, Junghanns.net ist auf der CeBit. Evtl kann man Klaus-Peter Junghanns dort treffen und über solche Dinge mal sprechen...
     
  4. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ich ahne wovon Du sprichst.
    Leider bin ich im Moment auf Achse und habe deshalb keine ISDN-Hardware greifbar, habe aber auch mal "schnell" RTAI zu installieren versucht. Pustekuchen von wegen schnell.

    Letztlich habe ich RTAI in meiner kleinen Testinstallation am Laufen, zumindest gibt der latency Test einen sinnvollen output.

    Aufgesetzt habe ich auf ein frisch installiertes Gentoo (mein Hotel hat freies Internet bei völlig unerwarteter Geschwindigkeit :D :D).

    Ohne Kernel 2.6.8.1 scheint es in der Tat nicht zu gehen. Mit dem Compilieren von RTAI hatte ich dann wie gesagt auch noch meine Probleme. Letztlich habe ich mich an das README.INSTALL von RTAI gehalten. Im letzten Teil (Bootstrap in 7 Schritten - oder ähnlich) steht das nützliche Zeugs.

    erst konfigurieren (oder war das nach dem Patch?)
    dann manuell patchen (wie im README.INSTALL beschrieben)
    dann kernel neu kompilieren
    dann erst funktioniert make (ich brauchte mehrere Versuche weil ich irgendwie beim beschriebenen make -f ... aus dem readme auf Abwege geraten bin)
    wenn das alles funktioniert hat den neuen Kernel booten
    und dann hat es geklappt bis zum latency Test

    Zusammenfassend habe ich mich entweder paddelig angestellt oder die Sache war trotz readme nicht so ganz trivial. Aber wer richtig lesen kann soll ja Vorteile im Leben haben. Nun ja...

    Anyway, im Moment komme ich wohl nicht weiter, weil ich keine ISDN-Hardware greifbar habe. Ich bin erst zur CeBit wieder retour.

    Vielversprechend sieht es allerdings aus. Zumindest habe ich jetzt sozusagen ein realtime-Notebook. Naja, wenigstens bis ich ich die Testpartition wieder brauche...
     
  5. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ach ja, eine Sache habe ich noch vergessen.

    Beim meiner Gentoo-Installation habe ich offenbar beim module-unload nicht richtig aufgepasst. Wenn ich den latency test wie im readme von rtai beschrieben mit ^c abbreche, bekomme ich

    FATAL: Kernel does not have unload support

    Also, aufgepasst bei der Kernel-Konfiguration...
     
  6. fly-a-lot

    fly-a-lot Neuer User

    Registriert seit:
    24 Feb. 2005
    Beiträge:
    63
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hast Du schon Kontakt aufnehmen können?
     
  7. isenberg

    isenberg Neuer User

    Registriert seit:
    8 Okt. 2005
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Besonders ärgerlich ist die Tatsache, dass ztdummy de RTC belegt, so dass
    Code:
    hwclock --debug
    zu
    Code:
    hwclock from util-linux-2.12r
    hwclock: Open of /dev/rtc failed, errno=16: Das Gerät oder die Ressource ist belegt.
    No usable clock interface found.
    Cannot access the Hardware Clock via any known method.
    
    führt.
    Nach
    Code:
    modprobe -r ztdummy
    ist die RTC wieder nutzbar:
    Code:
    hwclock --debug
    hwclock from util-linux-2.12r
    Using /dev/rtc interface to clock.
    Last drift adjustment done at 1185864360 seconds after 1969
    Last calibration done at 1185864360 seconds after 1969
    Hardware clock is on UTC time
    Assuming hardware clock is kept in UTC time.
    Waiting for clock tick...
    /dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
    ...got clock tick
    Time read from Hardware Clock: 2007/08/01 06:29:58
    Hw clock time : 2007/08/01 06:29:58 = 1185949798 seconds since 1969
    Mi 01 Aug 2007 08:29:58 CEST  -0.994482 seconds
    
    Kennt jemand eine Lösung, wie die RTC trotz ztdummy zugreifbar bleibt?