yavdr ansible

Zitat

Hast du mal den Durchsatz beim Kopieren von Daten über NFS gemessen? Gibt es Hinweise auf gedroppte Pakete oder ähnliche Netzwerkprobleme?

Zur ersten Frage, nein, ich wüßte gar nicht wie ich den messen kann, außer mit der Stoppuhr. Zur zweiten Frage, zumindest im syslog ist nichts zu entdecken.

Nachtrag: Ich habe jetzt mal einen Test mit dd gemacht, das Serverlaufwerk im Client gemountet und mit dd ein 1GB Testfile schreiben lassen, das Ergebnis

WLAN:
dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
1+0 Datensätze ein
1+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 432,094 s, 2,5 MB/s

Ethernet:
dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
1+0 Datensätze ein
1+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 16,9814 s, 63,2 MB/s

2,5MB/s beim Wlan kommt mir allerdings ein wenig sehr langsam vor.

Zitat

Wie hast Du das Aufnahmeverzeichnis eingebunden?

Mittels des avahi-linkers und einer entsprechenden wfe-static.cfg

Das war übrigens Blödsinn, daß ich das Aufnahmeverzeichnis per avahi eingebunden habe, das NAS ist per avahi eingebunden.

Das Aufnahmeverzeichnis wird per fstab eingebunden.

Nun habe ich das Aufnahmeverzeichnis mal mit einer systemd Unit, wie oben beschrieben eingebunden, das Problem bleibt.

Was ich halt nicht verstehe, daß das Abspielen vom NAS ohne Probleme funktioniert, das Abspielen vom vdr Server aber nicht.

Um das Problem noch etwas zu spezifizieren, es nicht ein Ruckeln, sondern das Video bleibt immer wieder kurz stehen, läuft dann eine Sekunde, bleibt eine Sekunde stehen usw.

Ich hatte vorher yavdr 0.6 auf dem Asrock ION da funktionierte das einwandfrei.

Das NAS ist aber nicht per WLAN, sondern über Ethernetkabel eingebunden?

2.5MB/s ist für WLAN schon schwaaaaach. Vielleicht zuviele Nachbarn, die denselben Kanal belegen?

Das Wlan war nur ein Versuch*, sowohl der Asrockclient, der vdrserver, als auch das NAS sind per Gigabit Ethernet verbunden.

*Die Atheros Wlankarte im Asrock scheint unter Linux nicht so der Burner zu sein.

Ok, aber vielleicht hapert es (auch) mit der Gigabit-Verbindung zum vdrserver? Was sagen hier (über Kabel-LAN) die Transferraten?

Gibt es "Beschwerden" bei "netstat --s", also ... retransmitted, ... bad segments, etc.?

Zitat

Ok, aber vielleicht hapert es (auch) mit der Gigabit-Verbindung zum vdrserver?

Ist das anzunehmen, wenn der server und client am selben Switch hängen, das NAS aber an einem anderen Switch?

So sieht das bei netstat -s aus, während eine Aufnahme abgespielt wird:

Ip:
    Forwarding: 2
    93854 total packets received
    0 forwarded
    0 incoming packets discarded
    92354 incoming packets delivered
    36564 requests sent out
Icmp:
    0 ICMP messages received
    0 input ICMP message failed
    ICMP-Eingabehistogramm:
    0 ICMP messages sent
    0 ICMP messages failed
    ICMP-Ausgabehistogramm:
Tcp:
    24 active connection openings
    19 passive connection openings
    2 failed connection attempts
    0 connection resets received
    5 connections established
    91776 segments received
    37244 segments sent out
    1 segments retransmitted
    0 bad segments received
    5 resets sent
Udp:
    622 packets received
    0 packets to unknown port received
    0 packet receive errors
    239 packets sent
    0 receive buffer errors
    0 send buffer errors
    IgnoredMulti: 24
UdpLite:
TcpExt:
    10 TCP sockets finished time wait in fast timer
    16 delayed acks sent
    Quick ack mode was activated 1 times
    84239 packet headers predicted
    147 acknowledgments not containing data payload received
    21235 predicted acknowledgments
    TCPSackRecovery: 1
    1 fast retransmits
    TCPDSACKOldSent: 1
    TCPSackShiftFallback: 1
    IPReversePathFilter: 336
    TCPRcvCoalesce: 54657
    TCPOFOQueue: 1022
    TCPAutoCorking: 23
    TCPWantZeroWindowAdv: 1
    TCPOrigDataSent: 23080
    TCPKeepAlive: 1
IpExt:
    InTruncatedPkts: 883
    InMcastPkts: 426
    OutMcastPkts: 121
    InBcastPkts: 76
    OutBcastPkts: 46
    InOctets: 226130403
    OutOctets: 6963440
    InMcastOctets: 130736
    OutMcastOctets: 31725
    InBcastOctets: 8303
    OutBcastOctets: 4887
    InNoECTPkts: 174811
    InECT0Pkts: 29

Ich kann da nichts ungewöhnliches entdecken.

Ich auch nicht, aber wie ist die Transferrate analog dem Posting mit der 2.5MByte-WLAN-Transferrate ermittelt?

Welche Fehlermeldungen waren da noch im Log?

Zitat

Ich auch nicht, aber wie ist die Transferrate analog dem Posting mit der 2.5MByte-WLAN-Transferrate ermittelt?

Verstehe jetzt nicht so ganz, was Du damit meinst, ich hatte die Transferrate mittels dd ermittelt.

Zitat

Welche Fehlermeldungen waren da noch im Log?

Soweit ich mich erinnere gab es keine, ich kann das aber nochmal testen.

Ja, mit dd ... ich kenne Deine "Netzwerkinfrastruktur" jetzt nicht, also wie laufen die Verbindungen? Kann parallel LAN und WLAN aktiv sein und das Routing läuft falsch?

Zitat

Kann parallel LAN und WLAN aktiv sein und das Routing läuft falsch?

Ethernet läuft über eine Fritzbox, Wlan über einen Unifi AP aber schon im selben Netz, wüßte nicht warum es da Probleme mit dem Routing geben sollte.

Ich werde aber mal was anderes versuchen, nämlich die umgekehrte Richtung und eine Aufnahme vom Client auf dem Server abspielen, dauert aber ein wenig bis ich das ausprobieren kann.

Wenn zwei Computer über zwei Wege miteinander verbunden sind, kann es durchaus Probleme geben.

Was zeigen denn "ip addr show" und "ip route list"?

Zitat

Wenn zwei Computer über zwei Wege miteinander verbunden sind

Aber sie sind ja nicht über zwei Wege verbunden, sie hängen beide am selben Switch, der direkt an der Fritzbox hängt.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether e0:cb:4e:5e:2e:88 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.85/24 brd 192.168.1.255 scope global enp0s10
       valid_lft forever preferred_lft forever
    inet6 2003:e1:170c:3d00:e2cb:4eff:fe5e:2e88/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6787sec preferred_lft 911sec
    inet6 fe80::e2cb:4eff:fe5e:2e88/64 scope link
       valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:25:d3:89:57:d1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.86/24 brd 192.168.1.255 scope global wlp2s0
       valid_lft forever preferred_lft forever
    inet6 2003:e1:170c:3d00:225:d3ff:fe89:57d1/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6787sec preferred_lft 911sec
    inet6 fe80::225:d3ff:fe89:57d1/64 scope link
       valid_lft forever preferred_lft forever

default via 192.168.1.1 dev enp0s10 proto static
default via 192.168.1.1 dev wlp2s0 proto static
192.168.1.0/24 dev enp0s10 proto kernel scope link src 192.168.1.85
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.86

Um das Ganze mal etwas klarer zu machen, der Server heißt bei mir "vdr", der Client "beamerknecht"

Ich habe jetzt gerade mal andersrum probiert, auf "beamerknecht" das streamdev-server Plugin installiert und eine Aufnahme abgespielt, funktioniert einwandfrei.

Was mir dabei aufgefallen ist, daß bei "vdr" im Aufnahmeverzeichnis automatisch ein Verzeichnis "Recordings on beamerknecht(nfs)" erscheint, sobald "beamerknecht" hochgefahren ist, wer oder was sorgt denn dafür und warum erscheint es umgekehrt auf dem Client nicht?

Ich denke es ist kein Netzwerkproblem.

Ich würde WLAN deaktiveren. Wozu ist das gut?

Der Rechner hat zwei IPs im gleichen Netzwerk. Ich kann mir vorstellen, dass die Pakete mal über das eine Interface und mal über das andere rausgehen. Und wenn das WLAN genutzt wird, ist es langsam.

Viele Programme sind nicht darauf ausgelegt, über eine bestimmte IP raus zu gehen. Dann kann es passieren, dass du durch die "zu kleine Tür" musst.

Mit den zwei Wegen meine ich Kabel und WLAN. Und der ist über diese zwei Wege verbunden.

Zitat von massi

default via 192.168.1.1 dev enp0s10 proto static
default via 192.168.1.1 dev wlp2s0 proto static

Ja, leider, 2 Interfaces im gleichen Netzwerk. Das kann und wird Probleme machen

Wenn das WLAN notwendig ist, zweckmäßigerweise ein anderes Subnetz dafür konfigurieren und nur für Geräte, die nicht gleichzeitig über LAN verbunden sind.

Zitat von massi

Was mir dabei aufgefallen ist, daß bei "vdr" im Aufnahmeverzeichnis automatisch ein Verzeichnis "Recordings on beamerknecht(nfs)" erscheint, sobald "beamerknecht" hochgefahren ist, wer oder was sorgt denn dafür und warum erscheint es umgekehrt auf dem Client nicht?

Der Link wird vom avahi-linker angelegt.

Wenn das Aufnahmeverzeichnis vom NAS gemountet wird, kann es auf dem Rechner nicht wieder so ohne weiteres per NFS exportiert werden und wenn der avahi-linker am Server eine angekündigte Freigabe nicht betreten kann, bindet er sie nicht ein.

Mich wundert, dass es ÜBERHAUPT funktioniert, wenn zwei Netzwerkgeräte (im VDR) die selbe IP-Adresse haben!
Das dürfte doch eigentlich gar nicht gehen, oder?

Gib dem VDR mal im WLAN eine andere IP-Adresse (im gleichen Subnet) und probier nochmal.

Wenn das nichts bringt, dann WLAN in ein eigenes Subnet, wie wmautner schreibt.
Da müssen dann halt auch Routen zwischen den Subnets eingerichtet bzw. erlaubt sein (Firewall).

davie2000 die Interfaces haben unterschiedliche IPs, was da gleich ist, ist das Gateway.

"route -n" müsste die Metriken zeigen.