Posts by rjkm

    Debian unstable mit Standard Debian kernel 4.19.0-1 + mein dddvb git (letzteres hat keine Änderungen, die bzgl. des Problems relevant wären).


    Da aber wirklich der PCIe-Link "wackelt", glaube ich nicht, daß es am Kernel liegt, eher an Einstellungen an den PCIe-PHYs. Und die werden im Kernel soweit ich weiß normalerweise nicht angefaßt, nur im BIOS.

    Da ich die Probleme, als sie noch auftraten, bei weiterer Belastung der CPU hatte (ich habe immer zum Test ein Kernel gleichzeitig gebaut), kann natürlich noch ein Unterschied ziwschen dem J3355M und dem J3455M bestehen, da letzterer 2 Kerne mehr hat.

    Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.

    Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).

    Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?

    Ich habe nur die vom J3355M (identisches Board nur mit 2-Core statt 4-Core Apollo-Lake).

    Man kann aber anscheinend die alten runterladen, wenn man den Download-Link per Hand anpasst.

    Soweit ich mich erinnere, mußte man auch erst 1.50 als "Bridge-BIOS" nehmen.

    Ohne Netzwerklast leuchten die ersten beiden LEDs (von der Hinterkante mit dem TAB2-Stecker her gezählt) permanent, die anderen 3 sind aus.


    Mit Netzwerklast blinkt die 5. LED. Sobald der Fehler auftritt leuchtet auch diese permanent, und ich meine, dass die dritte dann ganz schwach leuchtet.


    Den Downgrade auf BIOS 1.80 hat das Board angenommen, am Verhalten hat sich aber dadurch nichts geändert.

    Die LEDs zeigen, daß der PCIe-Link instabil wird.

    Das gleiche hatte ich mit BIOS <1.60 auch. Mit dem 1.60 konnte ich es nicht mehr provozieren.

    Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.

    Leider kann man wohl auf das 1.60 nicht zurück.


    Am I2C hat sich ewig nichts geändert. Da gibt es ja auch kein Problem.

    Das Problem ist immer entweder, daß der IRQ verloren geht, oder, daß der PCIe-Link ganz abbricht.

    Und dadurch gibt es halt dann Overflows im DMA und Timeouts im I2C.


    Bevor ich das 1.9er BIOS probiere, werde ich auch erst mal sehen, ob man zurück auf das 1.6er kann ...

    Seit wann hast Du welches BIOS drauf?


    Ich habe die Erfahrung gemacht, das es vor 1.6 große Probleme mit z.B. der Cine gab. Mit der 1.6er ist es bei mir aber ganz stabil, auch mit extra Streßtest-Firmware. Neuere BIOSe habe ich nicht probiert.

    Die PCIe-Link-Probleme mit DigitalDevices-Karten scheinen mit dem neuem BIOS auch nicht mehr aufzutreten.

    Vorher konnte ich diese Probleme mit spezieller Firmware, die den Link komplett auslastet, direkt provozieren.

    Mit dem neuem BIOS scheint es bisher keine Probleme zu geben.

    USB-Adapter und Stick kommen zusammen auf unter 20 Euro. Eine SSD dürfte da wohl etwas höher liegen. Und die PCIe-Slots sind alle schon belegt (entweder direkt durch eingesteckte Empfangskarten oder indirekt durch dort montierte, über Kabel mit der DD-Bridge verbundene Karten.


    Ich probiers einfach mal :-).


    Klaus


    Was für ein J3455M-Board ist das genau?

    Ich frage, da es aus eigener Erfahrung und Berichten hier im Board mit DDBridge und Apollo-Lake Probleme geben kann.


    Gruß,

    Ralph

    minisatip geht mit der Hardware nicht. Man kommt z.B. nicht direkt von der CPU aus an den Transportstream.

    Das Netzwerkinterface der CPU ist 100MBit und die schafft davon nur so 50Mbit.

    Das Streaming macht der FPGA, direkt vom TS-Ausgang der Demods (ggf. über ein CAM) in ein GBit-Port des Switches.

    Daher kommt man nicht direkt an den TS. Dafür ist eben die Latenz sehr klein und man kann ohne Probleme alle Transportstreams

    komplett streamen.


    Bzgl. Hardware und Bootvorgang hatte ich hier auch schon vor ein paar Jahren einiges geschrieben:

    https://github.com/DigitalDevi…ob/master/docs/octopusnet


    Eine serielle Console gibt es auch auf der Platine. Bei Interesse kann ich dazu noch was schreiben.

    Verschiedene input streams kann man über das Property DTV_STREAM_ID auswählen. Das wird soweit ich sehen kann im VDR schon länger unterstützt.
    Die Demod der Karte muß es aber auch unterstützen (z.B. der stv0910, eingeschränkt auch der stv0900).


    Unabhängig kann man in DVB-S2 für das Physical Layer Scrambling über einen Parameter verschiedene Gold Codes auswählen.
    Das hat nichts mit Scrambling für DRM zu tun. Man kann damit aber z.B. die Signale benachbarter Kanäle besser trennen, wenn man geeignet
    orthogonale Gold Codes verwendet. Siehe EN302307 Kapitel 5.5.4.


    Normalerweise wird immer Gold Code 0 benutzt. Viele der Sender, die MIS benutzen, verwenden aber gleichzeitig auch andere Gold Codes.
    Der manchmal angegebene Root Code kann leicht in den Gold Code umgerechnet werden.
    Er ist einer der Zwischenwerte in dem oben angegebenen Kapitel 5.5.4.


    Die oberen 24 Bits von DTV_STREAM_ID werden in manchen Treibern für die PLS und die Selektion von Root oder Gold mißbraucht.
    ddbridge unterstützt das auch, aber zusätzlich auch DTV_PLS nur für den Gold code. Der Root Code ist ja wie gesagt redundant.


    Gruß,
    Ralph

    Das subvendor ffff subdevice ffff deutet auf einen Fehler im Flash hin. Da stehen die Sub-IDs drin.
    Das sollte nicht vorkommen.Welche Karte hast Du genau?


    Man könnte versuchen, das mit ddtest (in dddvb/apps) zu fixen.
    z.B.:


    ddtest flashprog -SubVendorID dd010031


    für eine CT V7 bzw. dd010022 für eine S2 V7.


    Vorsicht! Dabei wird auf das Flash geschrieben, von dem auch der FPGA bootet.


    Wenn mehrere ddbridge Karten im Rechner sind, mit "-d X" die richtige auswählen. Besser aber nur mit einer ddbridge Karte im Rechner durchführen.


    Alternativ im Treiber vor der Zeile mit


    /* in case sub-ids got deleted in flash */


    einen Eintrag mit ffff bzw. PCI_ANY_ID einfügen:


    DDB_ID(DDVID, 0x0006, PCI_ANY_ID, PCI_ANY_ID, ddb_ctv7),


    Wenn das nicht hilft, auf jeden Fall zum Support.


    Gruß,
    Ralph

    iperf sagt auf der OctopusNet bzgl. Streaming nichts aus, da der SoC nichts streamt. Der SAM9G45 kann soweit ich weiß nur ca. 50-60Mbit/s.


    Der FPGA streamt direkt mit vollen 1Gbit/s von den Demods in den eingebauten Switch. Mit so wenig Latency wie der FPGA schafft das auch keine reine Software-basierte Lösung (egal ob SoC oder PC). Die OctopusNet ist da bestimmt kein Flaschenhals. Selbst 12 komplette Transport-Streams (wenn man ein paar doppelt streamt) sind kein Problem.

    Nein, in die ProLiant Micro Server lassen sich nur LowProfil Karten einbauen, im Gen8 gar nur eine Karte. Der Slot ist eigentlich für SmartArray Contoller vorgesehen. Wäre aber eine Marktlücke für eine DD MaxS4, 4 Tuner, 2 Anschlüsse ...


    Also 1 Eingang/Tuner geht vielleicht. Bei 2 braucht man nochmal LNBH plus Kleinkram. Demods könnte man immer noch 8 haben. Macht aber wirklich nur für Unicable Sinn.


    Mehrere Eingänge bei Unicable machen aber auch Sinn, wenn man keinen Multiswitch hat, sondern z.B. zwei Unicable LNBs (z.B. der 24fach von GT-SAT) und diese über 2 Stränge verteilt.

    Eine komplette (nicht willkürlich zusammengegrepte) Ausgabe der Kernel-Messages ab Laden des ddbridge Treibers würde mal weiterhelfen.


    Ist das jetzt auch immer noch in einem virtuellen System?

    Die Bemerkung bzgl. DiSEqC verstehe ich nicht.

    Wenn man Unicast anfordert, sollte der SAT>IP-Server auch nur Unicast senden.


    Bei der OctopusNet sende ich auch bei Multicast aber auch nur auf den Ports, wo ein Client ist.
    (Sie macht aber kein allgemeines IGMP Snooping.)

    pci_alloc_consistent() benutzt anscheinend das neuere dma_alloc_coherent() mit GFP_ATOMIC. Da ich das nicht atomic brauche, werde ich es auf dma_alloc_coherent() mit GFP_KERNELumstellen, damit die kleinen atomic pools bei ARM-Kernels kein Problem mehr machen.


    Bzgl. Geschwindigkeit bei coherent vs. syncing hängt das auch davon ab, ob man direkt in anderen Speicher kopiert, oder vorher noch etwas anderes damit macht.
    Wahrscheinlich hängt es auch vom ARM-Typ und dem verwendeten Cache ab.