Fax Versand und Fax Empfang auf FritzBox oder PC-Linux

RalfFriedl schrieb:
Anscheined gibt es einige interesante Unterschiede, zum Beispiel "Special PC-relative instructions for efficient loading of addresses and constants".
Auch die anderen drei Punkte von
MIPS16e code compression
* Reduces memory requirements by as much as 40 percent
* 16-bit encodings of 32-bit instructions to improve code density
* Special PC-relative instructions for efficient loading of addresses and constants
* SAVE & RESTORE macro instructions for setting up and tearing down stack frames within subroutines​
klingen interessant für den Einsatz auf der Box, wo der Speicher ohnehin immer knapp ist. Siehe auch http://www.mips.com/products/architectures/MIPS_16e.php.
Ich frage mich: Ist das die Funktionalität, die sich hinter der "-mips16"-Option von gcc verbirgt?
 
gfuer schrieb:
Ist das die Funktionalität, die sich hinter der "-mips16"-Option von gcc verbirgt?
Ausprobieren!
Tatsächlich scheint es so zu sein. Leider kommt bei Verwendung dieser Option ein Interner Fehler im Assembler.
Wenn man einige Zeilen im generierten Assembler-File entfernt, übersetzt es der Assembler, und objdump zeigt etwas, das anscheinend wirklich 16-Bit Code ist.
Ich vermute aber, daß die Zeilen, die ich gelöscht habe, trotzdem von Bedeutung waren.

Hast Du irgendwo nähere Informationen zu mips16? Auf der Seite bei Deinem Link gibt es anscheinend weitere Informationen, aber nur mit Paßwort.

Die Frage ist, ob man mips16 Code mit mips32 kombinieren kann und inwieweit Programme dadurch langsamer werden.

Ich habe inzwischen eine Firmware mit -march=4kc erstellt, bisher nichts auffälliges.
 
Zuletzt bearbeitet:
Ich hatte bisher auch gezögert. Jetzt jabe ich mich einfach auf der Web-Seite registriert. Ging problemlos, und nun kann ich auch auf die Dokumente zugreifen...

Im Kapitel 11.7 im Handbuch
http://www.mips.com/content/Documen...IPSSDEGNUToolkit/MD00310-2B-SDE-SUM-01.67.pdf
habe ich jetzt etwas mehr zu mips16 gefunden.

Sehe gerade hier
http://www.mips.com/content/Documen...IPSSDEGNUToolkit/MD00310-2B-SDE-SUM-01.67.pdf
dass MIPS16e eine optionale Komponente eines 4KEc-Cores ist (könnte also sein, dass der AR7 die gar nicht unterstützt).
 
Zuletzt bearbeitet:
Ich hab das mal getestet. Hab einen 440hz Ton für 2 min verschickt. Dabei fällt auf, das zwischendurch kleine Fehler empfangen werden. Diese sind sehr kurz (5-15ms) und machen sich beim telefonieren kaum bemerkbar. Es sind Klicks und manchmal dumpft der Ton nur etwas ab. Dennoch werden alle Pakete in der richtigen Größe empfangen. Bei den Tests hatte ich das Gefühl, das Stille richtig übertragen wird (0xAA), könnte mich da aber täuschen.

Keine Ahnung in wie weit das ECM das korrigieren kann.

Getestet hab ich über Remote-CAPI und auf der Box direkt, mit gleichem Ergebnis.
 
Die Pakete sind auch bei mir alle in der richtigen Größe. Kannst Du bei Deiner Datei feststellen, ob es dabei eine Phasenverschiebung gibt? Bei einem Sinus-Ton ist das vermutlich nicht so einfach.

Das ECM kann die Probleme leider nicht korrigieren, sonst wären sie vermutlich erst gar nicht aufgefallen.
Durch die Phasenverschiebung kommt anscheinend die Decodierung aus dem Tritt. Manchmal fängt sie sich danach wieder, manchmal auch nicht. Wenn nicht, macht der Sender munter weiter, während der Empfänger nichts mehr mitbekommt. Nach einigen Sekunden hat der Empfänger einen Timeout und beendet die Verbindung.

Mit ECM werden maximal 256 Blocks zu 256 Bytes gesendet. Danach erwartet der Sender eine Bestätigung bzw. eine Liste der Blocks, die er wiederholen soll. Wenn der Empfänger aber nicht mehr mitbekommt, wann der Sender fertig ist, kann er nicht die passende Antwort senden. Auch der Sender trennt die Verbindung, wenn er nicht innerhalb einer gewissen Zeit hier eine Reaktion bekommt.
 
Das mit der Phasenverschiebung wird schwierig, da das Programm kein so genaues Timing benötigt. Ich hatte nur geprüft, wie das Signal auf der anderen Seite ankommt. Ob irgendwas dabei aus dem Takt gekommen ist, kann ich nicht genau sagen.

EDIT:
Ok, habe eine ASCII Datei übertragen, jede Zeile 80 Zeichen. Auch bei mir sind am Anfang ca. 1200 Byte schrott. Mittendrin kommt dann sowas:

Code:
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUCDEFGHIJKLMÎÏÐÑÒÓ¨/ÄÅÆHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJËÌÍ’“”uvwxyz³ÄÅÆÇÈÉJË
‘’“”•–—˜™YZ_V·*0§[˜`íí§“§¿S¬nèïÇíï*›1ÏìîÑjáâãä%&'() ùüýþÿö÷êë0123 !"#$%&'()JÚÛ¸¾–—¦‹qrsàáâãäåæ'()ºi:ïlmncæçqsª;á¯ðòÁêù›<=>?67¸i:;ìíîïæç*+ !"#¸¹¨›¼½NOFG¦i:;lmnofçêëàáâ㸹z{LMNOÆÇ
7ÊC°±²{NO!£ªɃ*¢y*WJKÐÑÒÓÇ
ÖWê¬*’/°±²345ö÷xyYZߤ¥¦/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>
1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=?*#-_<>

Da scheint irgendwas in der CAPI schief zu laufen.
 
Zuletzt bearbeitet:
Wieder mal eine naive Denkanstoß-Bemerkung von mir als auf diesem Gebiet wirklich Unwissendem: Mit Fax4Box habe ich keine Probleme, capiotcp_server scheint mit diesen Dingen also gut zurecht zu kommen. Evtl. liegt es wirklich an einer unsauberen oder suboptimalen Implementierung. Könnte es sich für Euch lohnen, ein bißchen Protokoll-Analyse auf Port 5031 zu betreiben und evtl. diesen Datenstrom anzuzapfen?
 
@kriegaex: Ich glaube, "capi over tcp" läuft etwas anders, als das, was hier versucht wird zu implementieren. Es schickt die ganzen Pakete einfach über TCP an den Rechner weiter. Sozusagen ein Tunnel. Die eigentliche verarbeitung erfolgt im Rechner. Warum es dabei keine Aussetzer gibt und in dem Fall hier schon, ist für mich auch ein Rätsel. Ich bin aber auch kein Experte in diesen Echtzeitsachen.
@bodega Einige Ideen von mir (bin ebenfalls kein Experte!):
1. Kann es sein, dass die Box einen Interrupt ausführt, während euer Programm läuft? Dadurch kommt das Programm zum stehen und gerät aus dem Tritt.
2. Warum kommt in der Zeichenfolge "uvwxyz" zum zweiten Mal? Ist es nur eine zufällige Bitverschiebung, sodass daraus sich diese Buchstaben ergeben, oder wird dort tatsächlich zum zweiten Mal übertragen? Kannst du mit etwas komlizierterer Zeichenfolge testen? Z.b. "IchtestemeineFritzBox". Dann kann man es ausschließen.
3. Hier wurde von sinus und cosinus Berechnungen und Phasen besprochen. Werden denn dort wirklich sinus und cosinus online ausgerechnet? Bei langsamen Festkomma-Controllern benutzt man dafür typischerweise Look-Up Tables. Wäre es vielleicht hier auch sinnvoll so vorzugehen?

MfG
 
@bodega
Da bin ich ja "beruhigt", daß das auch bei anderen vorkommt. Ich hatte schon befürchtet, daß es bei mir an der Verkabelung liegt oder die Box defekt ist. Leider verkompliziert das die Sache sehr.

@kriegaex
Den Datenstrom anzuzapfen sollte nicht weiter schwierig sein. Dafür müßte allerdings erst Fax4Box installiert sein. Die Frage ist, ob das einen weiter bringt. In dem, was normalerweise für ein Fax übertragen wird, fallen Störungen nicht so leicht auf wie bei einem Testmuster.
Vermutlich könnte man daraus die Reihenfolge der CAPI-Messages ablesen, vielleicht bringt das etwas.
Wenn es bei Dir schon komplett installiert ist, hast Du die Möglichkeit, ein tcpdump auf eine Faxübertragung mitlaufen zu lassen mit voller Paketgröße?
Oder besser noch "strace -s10000 -f" auf den capiotcp_server. Darin wäre nicht nur die Netzwerkübertragung, sondern auch noch die CAPI-Aufrufe.

@hermann72pb
Bei "capi over tcp" übernimmt der PC die Verarbeitung, das ist richtig. Es wird aber die gleiche ISDN-Hardware und vermutlich die gleiche CAPI genutzt, es sei denn, AVM hat für sich etwas besseres. Im Moment sehe ich das Problem nicht mehr bei der CPU-Leistung der Box, sondern bei den Fehlern auf der ISDN-Ebene.
1. Die Box führt massenhaft Interrupts aus, 100 Timer-Interrupts pro Sekunde immer und für Netzwerk und ISDN sicher noch etliche mehr. Aber das ist keine Entschuldigung für die Übertragungsfehler. Bei den Testmustern von bodega und mir wird ja keine CPU-Last durch Signalverarbeitung erzeugt, sondern die Testdaten werden nur von einer Datei auf die Leitung geschickt und umgekehrt. 8000 Bytes pro Sekunde sollten da schon noch machbar sein.
2. Die Ursache bzw. die Lösung dafür scheint mir im Moment die wichtigste Frage zu sein. Das Muster kommt tatsächlich wieder. Du kannst Dir mal mein Muster aus Beitrag #73 ansehen. Ich habe dort aufsteigende Binärzahlen, die sich nicht wiederholen. Bei der zweiten markierten Stelle fängt dort ein Muster an, das 61 Bytes vorher schon mal da war.
3. Die sinus/cosinus Werte kommen aus einer Tabelle, auch bei Fließkomma. Nach meinen Informationen ist auch eine Fließkomma-Einheit bei diesen Operationen nicht mehr übermäßig schnell. Außerdem werden diese eher beim Senden gebraucht.

@all
Wie oben bereits angedeutet, sehe ich die CPU-Auslastung im Moment nicht mehr als das Problem an. Ich habe bei einem Versuch erfolgreich zwei Seiten zu ca. 2MB übertragen in etwas über 40 Minuten. Die CPU-Auslastung ist dabei mit 40%-60% hoch, aber nicht extrem. Es hat auch gereicht, um die empfangene erste Seite als TIFF komprimiert zu speichern und dann mit der zweiten Seite weiter zu machen.
Bei den meisten Versuchen bricht aber die Übermittlung nach einigen Minuten ab, mal früher, mal später. Daher war es wohl ein Glücksfall, daß es auch mal die nötigen 40 Minuten gereicht hat.

Da es mit Fax4Box anscheinend geht, hätte ich dafür im Moment zwei mögliche Erklärungen:
1. Die ISDN-Ansteuerung von AVM ist besser auf die CAPI der Box abgestimmt.
2. Die Signalverarbeitung von AVM kommt mit solchen Störungen besser zurecht.
 
40 Minuten für zwei Seiten?! Soll das praxistauglich sein?

Ich kann gerne mal mit strace oder ltrace etwas für Dich loggen, dafür brauche ich aber ein paar Vorgaben, damit Du auch bekommst, was Du möchtest:
  • Wie soll ich es technisch machen? Ich habe nur einen PC und kein Papierfax, auch keine separate ISDN-Karte. Gleichzeitig senden und empfangen über die Fritz!Box und das noch via Ortsnetz, wäre wohl kein guter Test. Ich kann bestenfalls via Web.de eine Textseite faxen oder mir von Dir etwas faxen lassen.
  • Möchtest Du ein bestimmtes Dokument gefaxt haben? Dann brauche ich das Dokument bzw. die Testroutine mit dem Datenstrom nebst Anleitung, wie es zu übertragen ist.
  • Evtl. wäre dann für das Protokoll später eine E-Mail-Adresse sinnvoll, oder ich lade die Datei hier hoch und lösche sie wieder, sobald Du sie gezogen hast, falls sie recht groß ist.
 
Ich hab mal die Client-Seite von Fritz!Fax getestet mit der capi-debug dll (Fritz!Fax --> GMX-Fax Gateway). Das Protokoll ist im Anhang.

Der erste Versuch konnte nicht gesendet werden. Beim zweiten Versuch wurde das Fax verschickt.

EDIT:
Den Empfang hab ich auch mal mitgeschnitten.
 

Anhänge

  • capi-debug-fritzfax.zip
    21.5 KB · Aufrufe: 11
  • capi-debug-fritzfax-recv.zip
    13.8 KB · Aufrufe: 9
Zuletzt bearbeitet:
@kriegaex
Die 20 Minuten pro Seite sind nicht deswegen, weil die Übertragung so langsam ist, sondern weil die Testseite extra so konstruiert ist, daß sie sehr groß ist. In T.6 Kodierung ist die Seite etwas über 2MB groß. 2MB in 20 Minuten ergibt ca. 13.300 Bit/s an Nutzdaten, also bei 14.400 Bit/s brutto Datenrate ein akzeptabler Wert. Normale Seite gehen entsprechend schneller durch.
Das ist ja der Grund, warum ich im ersten Beitrag sinngemäß geschrieben habe "alles Bestens". Ich hatte es nur mit einfachen Seiten probiert, und da hatte es funktioniert.

@bodega
War die Übertragung über die Box oder einen PC?
Ist aber auf jeden Fall interessant. Die Block-Größe ist 1024 Byte. Ich hätte eher erwartet, daß eine Größe verwendet wird, bei der eine ganze Anzahl von Blocks eine Sekunde ergeben (8000 Bytes).
Ansonsten funktioniert es so wie mein Programm:
Daten kommen an (IND), werden vermutlich verarbeitet und eine Antwort gesendet (REQ). Danach erst werden die eingehenden Daten bestätigt (RESP). Erst nach dem Empfang des zweiten Datenblocks kommt die Bestätigung, daß der erste Datenblock gesendet wurde. Diese kommt also anscheinend erst, wenn der komplette Block gesendet wurde.
Im Prinzip also genau wie bei mir, nur daß hier nicht schon vorab Daten auf die Leitung gelegt werden.
Ich werde das bei mir mal auch herausnehmen und heute Abend testen.
Code:
DATA_B3_IND                ID=005 #0xe8bf LEN=0030     01:47:02:32
  Controller/PLCI/NCCI            = 0x11101
  Data                            = k<eb 2b 2b ab 2a aa 2a>jj
  DataLength                      = 0x400
  DataHandle                      = 0x8
  Flags                           = 0x0

DATA_B3_REQ                ID=005 #0x000c LEN=0022     01:47:02:32
  Controller/PLCI/NCCI            = 0x11101
  Data                            = <aa d8 60 88 b7 e1 21 e7>H<60>
  DataLength                      = 0x400
  DataHandle                      = 0x0
  Flags                           = 0x0

DATA_B3_RESP               ID=005 #0x000d LEN=0014     01:47:02:32
  Controller/PLCI/NCCI            = 0x11101
  DataHandle                      = 0x8

DATA_B3_IND                ID=005 #0xe8c0 LEN=0030     01:47:02:45
  Controller/PLCI/NCCI            = 0x11101
  Data                            = <96 28 88 08 08 e8 28 96>f<1e>
  DataLength                      = 0x400
  DataHandle                      = 0xa
  Flags                           = 0x0

DATA_B3_REQ                ID=005 #0x000e LEN=0022     01:47:02:45
  Controller/PLCI/NCCI            = 0x11101
  Data                            = a<d7 e8 60 a0>2<99>aI<e6>
  DataLength                      = 0x400
  DataHandle                      = 0x1
  Flags                           = 0x0

DATA_B3_RESP               ID=005 #0x000f LEN=0014     01:47:02:45
  Controller/PLCI/NCCI            = 0x11101
  DataHandle                      = 0xa

DATA_B3_CONF               ID=005 #0x000c LEN=0016     01:47:02:46
  Controller/PLCI/NCCI            = 0x11101
  DataHandle                      = 0x0
  Info                            = 0x0

DATA_B3_IND                ID=005 #0xe8c1 LEN=0030     01:47:02:57
  Controller/PLCI/NCCI            = 0x11101
  Data                            = p<f0 c0> <f8>v2Oi<d9>
  DataLength                      = 0x400
  DataHandle                      = 0x1
  Flags                           = 0x0

DATA_B3_REQ                ID=005 #0x0010 LEN=0022     01:47:02:59
  Controller/PLCI/NCCI            = 0x11101
  Data                            = Ia<99>2<a0 60 e8 d7>a<21>
  DataLength                      = 0x400
  DataHandle                      = 0x2
  Flags                           = 0x0

DATA_B3_RESP               ID=005 #0x0011 LEN=0014     01:47:02:59
  Controller/PLCI/NCCI            = 0x11101
  DataHandle                      = 0x1

DATA_B3_CONF               ID=005 #0x000e LEN=0016     01:47:02:59
  Controller/PLCI/NCCI            = 0x11101
  DataHandle                      = 0x1
  Info                            = 0x0
 
Ich hatte das Fax über den PC (Fritz!Fax) per Remote-CAPI gesendet/empfangen. Sozusagen über den capiotcp_server. Der andere Sender/Empfänger war ein Fax-Gateway.

Ich hatte bei meinem Testprogramm CIP value, infomask, etc. auch noch übernommen - der Sicherheit halber. Für mein Empfinden ist es etwas besser geworden, aber nicht großartig.

Das FACILITY_REQ im Log kommt denke ich mal vom CAPI_PROFILE, zumindest macht es irgenwie keinen Sinn (Selector 3, Parameter: 03 (Länge) 00 00 00 (???)). Hast du eine Idee?

Ich hab hier noch eine Library, mit der ich die CAPI-Aufrufe auf der Box in capiotcp_server sniffen kann (eventuell auch Aufnehmen als alaw). Müsste das nur etwas anpassen...
 
FACILITY_REQ sind irgendwelche "sonstigen" Anforderungen, die (vermutlich) nicht für den Verbindungsaufbau und die Datenübermittlung wichtig sind. Umgekehrt sind FACILITY_IND sonstige Mitteilungen der CAPI an das Programm.
Die CAPI Dokumentation spricht hier unter anderem von DTMF Erkennung, V.42bis und Power Management. Speziell 00 00 00 sollte "Supplementary Services", "Get Supported Servces" sein, was auch immer das genau heißt. Die CAPI Dokumentation kennst Du ja vermutlich.

Interessant wäre ein Vergleich der gesendeten Daten mit den Empfangenen Daten. Da eine normale Fax-Übertragung nicht so ein regelmäßiges Muster hat, lassen sich sonst Störungen schlecht feststellen.
Falls die Störungen auch bei der AVM Software auftreten, hat AVM vermutlich einen robusteren Empfangs-Algorithmus, in dem Fall ist vermutlich nicht viel zu machen.
 
Ich habe mir auch ein CAPI-Testprogramm geschrieben. Mit Blockgröße 1024 und einem Block Vorlauf konnte ich mehrmals fehlerfrei 4MB in beide Richtungen übertragen, von der Fritz-Box über den eine B-Kanal raus zur Vermittlungsstelle, und über den zweiten B-Kanal wieder rein in die Box (Die T-Com wird sich über meine Tests freuen). Zwei Instanzen des Testprogramms laufen dabei auf der Box:

Im ersten Telnet-Fenster:
var $ ./capitest1 -b 1024 -k 4096 -m 12345678 -p 1

Im zweiten Telnet-Fenster:
var $ ./capitest1 -b 1024 -k 4096 -m 12345678 -p 1 12345678

(Btw, nach der Ausgabe "end of data" muß man das Programm mit Ctrl-C abbrechen. Ich habe noch keinen Verbindungsabbau eingebaut...)

Mit kleineren Blöcken (z.B. 200) sehe ich jedoch regelmäßig Probleme. Am Häufigsten sehe ich Fehler, wo 78 Samples im Folge mit dem Wert 0xff überschrieben sind, danach geht es wieder mit dem normalen Datenstrom weiter, sogar in der richtigen Phasenlage, aber 78 defekte Samples in Folge stellen m.E. schon eine heftige Störung für ein analoges Modemsignal dar.

Beispiel:

[...]
INFO: connected
INFO: got sync 0x0000117a phase=0x2c
ERROR: lost sync 0x0024e300, expected 0xd4
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff
22 23
24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30

INFO: got sync 0x0024e34e phase=0x2c <-- wie vor der Störung
[...]


Die roten Bytes sind die Defekten, und bei den Grünen passt es dann wieder. Und irgendwie hat die Sache System. Ich sende ja bidirektional, und es tritt in beide Richtungen zeitgleich auf. Und es sind jedes Mal 78 oder 79 Bytes 0xff, und die Störung beginnt immer auf einem Offset im empfangenen Datenstrom, der ein Vielfaches von 0x40 ist. Zufall?

Außer dieser Störung, die ich mit kleineren Blöcken immer wieder gesehen habe, hatte ich auch noch ein oder zwei Mal einen Fall, wo wirklich auch die Phasenlage anschließend außer Tritt war (das verzeiht ein Modem sicher nicht). Und auch Fehler, bei denen nur vereinzelt ein Sample defekt war, habe ich gesehen (so würde ich mir normalerweise Bitfehler auf der ISDN-Leitung vorstellen). Ich habe den Eindruck, dass ich möglicher Weise mit Last auf der Box (z.B. Web-Interface benutzen), während eine Übertragung läuft, teilweise solche Fehler provozieren kann, aber für eine statistisch signifikante Aussage bräuchte es mehr Versuche.
 

Anhänge

  • capitest.tar.gz
    84.8 KB · Aufrufe: 15
Zuletzt bearbeitet:
@gfuer:
gute arbeit! ich finde es eigentlich logisch, dass es an der buffersize liegt ob man fehler bekommt oder nicht. das capi hat doch eine bestimmte anzahl an puffern jeweils buffersize groß. die werden im hintergrund vollgeschrieben und dann der applikation zur verfügung gestellt. und wenn die klein sind, dann ist 1. mehr overhead in der puffer verwaltung (sollte aber nicht ins gewicht fallen??) und 2. natürlich insgesamt der puffer kleiner. wenn dann ein interrupt kommt bzw. mehr last ist, dann gehen natürlich daten verloren. jenachdem wie die capi intern ihren speicher verwaltet könnte ich mir so auch erklären, dass es zu wiederholungen kommt. phasenverschiebungen verstehe ich noch nicht ganz, aber möglich wäre es dadurch auch, dass einfach daten fehlen (eingefügt, also phase in positive richtung verschoben, halte ich für eher unwahrscheinlich).
hast du mal überprüft in welche richtung die phasenverschiebung ist, wenn denn eine auftritt?

nun die frage wie wir das lösen? kann man rausfinden was der remote capi daemon für eine buffersize/blocksize verwendet? bzw. was der telefond oder der voipd (wenn der capi benutzt??) verwendet. also kurz: wie macht es avm?

Edit: beim capi_register gibt man doch sozusagen an, 8x200 byte puffer (wobei 200 hier die blocksize wäre.. naja, und wenn die eben kleiner ist... also 1024 blocksize, dann wär man mit 8 puffern bei ca. 1 sekunde puffer.
für den faxempfang hier das problem: puffer zu groß = verzögerung zu groß -> timeout
puffer zu klein = datenverlust -> sync probleme, übertragungsfehler
 
Zuletzt bearbeitet:
florixyz schrieb:
nun die frage wie wir das lösen? kann man rausfinden was der remote capi daemon für eine buffersize/blocksize verwendet? bzw. was der telefond oder der voipd (wenn der capi benutzt??) verwendet. also kurz: wie macht es avm?

Man könnte es hiermit versuchen. Damit kann man die CAPI-Funktionen auf der Box hooken.
Interessant wäre auch mal die Zeit, die zwischen zwei DATA_B3_INDs liegt. Bei mir schwankt diese immer.
 
@florixyz
Bei meinen Versuchen war wenn überhaupt die Phase nach hinten verschoben, also Daten/Unsinn eingefügt.

Der rcapid verwendet die Blockgößte, die er vom Client vorgegeben bekommt. Der capiotcp_server macht das sicher ähnlich.

Die Blockgröße beim FritzFax ergibt sich aus dem CAPI Protokoll von bodega in Beitrag #91 und liegt bei 1024 Bytes.

Beim capi_register gibt man die Anzahl der Blöcke und die maximale Blockgröße an. Beim transparenten Transfer, den wir hier haben (im Gegensatz zu HDLC), gibt es auf der Leitung keine Blockgröße, die CAPI übermittelt alle Blöcke genau in der angegebenen maximalen Größe.

Eine Blockgröße von 1024 Byte entspricht etwas über einer achtel Sekunde, das ist eine lange Zeit. Das sollte locker dafür reichen, daß man sich jede halbe Sekunde 4 Blöcke abholt. Außerdem erklärt das nicht die Störungen, die kleiner sind als die Blockgröße.

Ich habe schon Blockgrößen bis 4KB ausprobiert und es treten trotzdem Störungen auf. Ob mit der Größe auch noch der Faxempfang geht habe ich daher gar nicht mehr ausprobiert.

ISDN insgesamt ist nicht so schnell, daß dabei hohe Anforderungen an die CPU gestellt werden. Die Hardware wird ja wohl in der Lage sein, eine gewisse Anzahl an Bytes sebst zu erarbeiten und diese dann in Ruhe an die Software zu übergeben. Anderenfalls gäbe es viele Interrupts und hohe CPU-Auslastung schon allein von einer ISDN-Übertragung.

Leider ist nichts näheres bekannt, wie die ISDN-Ansteuerung funktioniert, sonst könnte man untersuchen, welche Daten wo ankommen.
 
florixyz schrieb:
phasenverschiebungen verstehe ich noch nicht ganz, aber möglich wäre es dadurch auch, dass einfach daten fehlen (eingefügt, also phase in positive richtung verschoben, halte ich für eher unwahrscheinlich).
Letztere können z.B. sendeseitig passieren, wenn man die Sendedaten nicht so schnell "nachschiebt", wie sie der Controller versendet - dann muß der Controller oder Treiber irgendwelche Daten zwischen den gesendeten Blöcken in den Datenstrom einfügen, denn ISDN läuft ja synchron. Daher auch der Gedanke, einen oder ein paar Blöcke vorweg zu senden, die dann im CAPI zwischengepuffert werden (sozusagen als Jitter-Buffer), damit der Datenstrom nicht abreißt, auch wenn die Berechnung des nächsten zu sendenden Datenblocks 'mal ein Bisschen länger dauert.
ich finde es eigentlich logisch, dass es an der buffersize liegt ob man fehler bekommt oder nicht. das capi hat doch eine bestimmte anzahl an puffern jeweils buffersize groß. die werden im hintergrund vollgeschrieben und dann der applikation zur verfügung gestellt. und wenn die klein sind, dann ist 1. mehr overhead in der puffer verwaltung (sollte aber nicht ins gewicht fallen??) und 2. natürlich insgesamt der puffer kleiner.
Ja natürlich, aber bei der mageren Datenrate von ISDN sollte das m.E. wirklich nicht ins Gewicht fallen. Vor allem, wenn man ein Programm hat, das nur sendet und empfängt, aber keine großartigen Berechnungen anstellen muß. Was sind schon 40 Blöcke/s (bei 200 Byte Blockgröße) im Vergleich zu den Datenmengen und -raten, die z.B. übers LAN übertragen werden?

EDIT: @RalfFriedl:
Man könnte ja schon fast auf die ketzerische Idee kommen, ob Sende- und Empfangstakt vielleicht nicht zueinander synchron sind? Wäre auch mal interessant, sendeseitig die ausstehenden (nicht quittierten) DATA_B3_REQ zu zählen. Wenn die im Laufe der Übertragung immer weniger werden und irgendwann auf 0 gehen, dann wäre das zumindest ein Indiz dafür.

Lief die Verbindung bei Deinen Tests eigentlich übers PSTN oder nur intern, z.B. zwischen PC und internem ISDN-Controller der Box? Konntest Du eigentlich mit irgend einer Blockgröße eine größere Datenmenge (z.B. 4MB == ca. 9min) mehrfach fehlerfrei übertragen?
 
Zuletzt bearbeitet:
Die Übertragungen mache ich immer mit einem normalen ISDN-Anschluß, also nicht der interne S0 der Box. Mir ist auch nicht bekannt, ob es überhaupt möglich ist, zwischen zwei Geräten am S0 eine Verbindung herzustellen, die lokal ist, also nicht über die Vermittlungsstelle geht. Das wäre natürlich auch ein interessanter Versuch, ISDN-Karte an den internen S0 hängen und sehen, wie da die Übertragung läuft.

Mit der Box habe ich es nicht geschafft, 4MB Fehlerfrei zu übertragen, auch nicht mit 4KB Blockgröße. Und auch da gab es nicht nur Aussetzer, sondern auch Verschiebungen.

Deine Idee ist insofern "ketzerisch", als es sich um den gleichen ganz normalen Telekom-Anschluß handelt, an dem sowohl der Sender als auch der Empfänger angeschlossen sind. Dieser sollte also wenigstens mit sich selbst synchron sein. Außerdem schafft es die ISDN-Karte im PC an dem gleichen Anschluß.

Was mir aufgefallen ist, wenn ich mit kleiner Blockgröße gearbeitet habe, ist die Zahl der Ausstehenden REQs nicht unter 1 gegangen, sondern angestiegen, und zwar zum Teil bis auf 7, und dann kam von der CAPI eine Rückmeldung, daß sie das nächste ausgehende Paket nicht akzeptiert hat. Die CAPI hat in diesem Fall also mehr als genug Daten. Mehr als 8 ausstehende Pakete werden anscheinend nicht akzeptiert, unabhängig von den Parametern bei capi_register. Möglicherweise betreffen diese auch nur den Empfang und vielleicht auch nur bis zu einer bestimmten Obergrenze.

Es könnte also sein, daß schon beim Senden ein Problem auftritt, daß da also die Daten nicht so schnell gesendet werden können, wie sie empfangen werden. Eine denkbare Erklärung wäre, daß Fehler welcher Art auch immer auftreten, so daß sich das Senden der Daten verzögert. Beim Empfänger wären dann für diesen Zeitraum keine sinnvollen Daten vorhanden, und die richtigen Daten kommen später. Auf jeden Fall kann es nicht daran liegen, daß die CAPI keine Daten zum Senden hat. Erstens war sie immer gut versorgt, und zweitens übermittelt sie ansonsten einen 0-Wert, also 0xAA oder 0xAB. Oder die Vermittlungsstelle fügt das ein, das kommt auf jeden Fall an, wenn die andere Seite nichts sendet. Da ich sowohl 0xAA als auch 0xAB schon gesehen habe, vermute ich, daß der Wert nicht von der Vermittlungsstelle kommt, sondern von der CAPI des Senders.

Wenn ich etwas mehr Zeit habe, versuche ich mal systematisch PC an Box, Box an PC, Box an Box und PC an PC.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.