Odroid C2

Derek Buegel · 16. September 2016

Bei einer HD+ Karte sind 500ms vollkommen i.O.

MfG

dodo83 · 16. September 2016

Skydiver25 schrieb:
deutlich über 500ms sind alle 6 'Impulse"

6 Anfragen? bei den HDplus Sendern summieren sich die Zeiten ganz schnell wenn die Karte mehrere Anfragen beantworten muss vom gleichem Transponder

Skydiver · 16. September 2016

Ich glaub ,dass ich mich falsch ausgedrückt habe.Ich habe nur die v13 im Einsatz .mit 6 Impulse meine ich die ECM'S im Log

Hat denn sonst noch jemand en Ideechen was ich noch drehen, tüfteln ,schrauben oder ändern kann ?

Derek Buegel · 16. September 2016

Pinge mal den Receiver mit den steigenden Zeiten, vom Odroid aus, an.

Code:

ping IP_des_Receivers

Stoppen mit STRG C

MfG

Skydiver · 16. September 2016

der erste Ping ist oscam:

64 bytes from 192.168.178.37: icmp_seq=1 ttl=64 time=2.52 ms
64 bytes from 192.168.178.37: icmp_seq=2 ttl=64 time=2.41 ms
64 bytes from 192.168.178.37: icmp_seq=3 ttl=64 time=4.02 ms
64 bytes from 192.168.178.37: icmp_seq=4 ttl=64 time=2.22 ms
64 bytes from 192.168.178.37: icmp_seq=5 ttl=64 time=2.18 ms
64 bytes from 192.168.178.37: icmp_seq=6 ttl=64 time=2.18 ms
64 bytes from 192.168.178.37: icmp_seq=7 ttl=64 time=3.25 ms
64 bytes from 192.168.178.37: icmp_seq=8 ttl=64 time=2.10 ms
64 bytes from 192.168.178.37: icmp_seq=9 ttl=64 time=2.19 ms
64 bytes from 192.168.178.37: icmp_seq=10 ttl=64 time=2.14 ms
64 bytes from 192.168.178.37: icmp_seq=11 ttl=64 time=2.31 ms
64 bytes from 192.168.178.37: icmp_seq=12 ttl=64 time=2.40 ms
64 bytes from 192.168.178.37: icmp_seq=13 ttl=64 time=2.41 ms
64 bytes from 192.168.178.37: icmp_seq=14 ttl=64 time=2.15 ms
64 bytes from 192.168.178.37: icmp_seq=15 ttl=64 time=2.07 ms
64 bytes from 192.168.178.37: icmp_seq=16 ttl=64 time=3.71 ms
64 bytes from 192.168.178.37: icmp_seq=17 ttl=64 time=2.16 ms
64 bytes from 192.168.178.37: icmp_seq=18 ttl=64 time=2.57 ms
64 bytes from 192.168.178.37: icmp_seq=19 ttl=64 time=2.61 ms
64 bytes from 192.168.178.37: icmp_seq=20 ttl=64 time=2.13 ms
64 bytes from 192.168.178.37: icmp_seq=21 ttl=64 time=2.11 ms
64 bytes from 192.168.178.37: icmp_seq=22 ttl=64 time=2.33 ms
64 bytes from 192.168.178.37: icmp_seq=23 ttl=64 time=2.10 ms
64 bytes from 192.168.178.37: icmp_seq=24 ttl=64 time=2.11 ms
64 bytes from 192.168.178.37: icmp_seq=25 ttl=64 time=2.30 ms
64 bytes from 192.168.178.37: icmp_seq=26 ttl=64 time=2.25 ms
64 bytes from 192.168.178.37: icmp_seq=27 ttl=64 time=2.94 ms
64 bytes from 192.168.178.37: icmp_seq=28 ttl=64 time=3.02 ms
64 bytes from 192.168.178.37: icmp_seq=29 ttl=64 time=2.15 ms
64 bytes from 192.168.178.37: icmp_seq=30 ttl=64 time=2.94 ms

der 2. ist von cccam

PING 192.168.178.30 (192.168.178.30) 56(84) bytes of data.
64 bytes from 192.168.178.30: icmp_seq=1 ttl=64 time=0.913 ms
64 bytes from 192.168.178.30: icmp_seq=2 ttl=64 time=0.856 ms
64 bytes from 192.168.178.30: icmp_seq=3 ttl=64 time=0.849 ms
64 bytes from 192.168.178.30: icmp_seq=4 ttl=64 time=0.859 ms
64 bytes from 192.168.178.30: icmp_seq=5 ttl=64 time=0.852 ms
64 bytes from 192.168.178.30: icmp_seq=6 ttl=64 time=0.857 ms
64 bytes from 192.168.178.30: icmp_seq=7 ttl=64 time=0.822 ms
64 bytes from 192.168.178.30: icmp_seq=8 ttl=64 time=0.841 ms
64 bytes from 192.168.178.30: icmp_seq=9 ttl=64 time=0.855 ms
64 bytes from 192.168.178.30: icmp_seq=10 ttl=64 time=0.853 ms
64 bytes from 192.168.178.30: icmp_seq=11 ttl=64 time=0.848 ms
64 bytes from 192.168.178.30: icmp_seq=12 ttl=64 time=0.881 ms
64 bytes from 192.168.178.30: icmp_seq=13 ttl=64 time=0.873 ms
64 bytes from 192.168.178.30: icmp_seq=14 ttl=64 time=0.854 ms
64 bytes from 192.168.178.30: icmp_seq=15 ttl=64 time=0.859 ms
64 bytes from 192.168.178.30: icmp_seq=16 ttl=64 time=0.861 ms
64 bytes from 192.168.178.30: icmp_seq=17 ttl=64 time=0.867 ms
64 bytes from 192.168.178.30: icmp_seq=18 ttl=64 time=0.849 ms
64 bytes from 192.168.178.30: icmp_seq=19 ttl=64 time=0.869 ms
64 bytes from 192.168.178.30: icmp_seq=20 ttl=64 time=0.877 ms
64 bytes from 192.168.178.30: icmp_seq=21 ttl=64 time=0.884 ms
64 bytes from 192.168.178.30: icmp_seq=22 ttl=64 time=0.902 ms

Derek Buegel · 16. September 2016

Der Ping hat nichts mit oscam oder cccam zu tun. Du pingst einfach nur den Receiver an.
2,.... ms sind schon echt viel im lokalen Netzwerk. Verbindet der Receiver über WLAn? Wenn ja, leg mal probehalber ein Netzwerkkabel.
Hier bei mir

Code:

14 packets transmitted, 14 received, 0% packet loss, time 12999ms
rtt min/avg/max/mdev = 0.761/0.850/0.976/0.074 ms

MfG

Skydiver · 16. September 2016

Alles per LAN .

beim 2. reciever sieht es gar nicht schlecht aus.

22 packets transmitted, 22 received, 0% packet loss, time 20997ms
rtt min/avg/max/mdev = 0.822/0.862/0.913/0.041 ms

Derek Buegel · 16. September 2016

Kannst Du die Netzwerkkabel mal tauschen und den Ping wiederholen bzw mal ein anderes Kabel legen?
Was sind das für Receiver? Kannst auch mal WLan testen (obwohl ich sonst immer davon abrate).

MfG

Skydiver · 16. September 2016

Ja das geht.fritzbox steht direkt daneben.gigablue 800 UE plus

Kleinen Moment

64 bytes from 192.168.178.33: icmp_seq=1 ttl=64 time=1.67 ms
64 bytes from 192.168.178.33: icmp_seq=2 ttl=64 time=0.788 ms
64 bytes from 192.168.178.33: icmp_seq=3 ttl=64 time=0.849 ms
64 bytes from 192.168.178.33: icmp_seq=4 ttl=64 time=0.748 ms
64 bytes from 192.168.178.33: icmp_seq=5 ttl=64 time=0.772 ms
64 bytes from 192.168.178.33: icmp_seq=6 ttl=64 time=0.754 ms
64 bytes from 192.168.178.33: icmp_seq=7 ttl=64 time=0.694 ms
64 bytes from 192.168.178.33: icmp_seq=8 ttl=64 time=0.718 ms
64 bytes from 192.168.178.33: icmp_seq=9 ttl=64 time=0.691 ms
64 bytes from 192.168.178.33: icmp_seq=10 ttl=64 time=0.710 ms
64 bytes from 192.168.178.33: icmp_seq=11 ttl=64 time=0.688 ms
64 bytes from 192.168.178.33: icmp_seq=12 ttl=64 time=0.686 ms
64 bytes from 192.168.178.33: icmp_seq=13 ttl=64 time=0.710 ms
64 bytes from 192.168.178.33: icmp_seq=14 ttl=64 time=0.693 ms
^C
--- 192.168.178.33 ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 12997ms
rtt min/avg/max/mdev = 0.686/0.798/1.678/0.249 ms

wenn ich die Fritzbox anpinge(dient als repeater) ,sieht das so aus

22 packets transmitted, 22 received, 0% packet loss, time 21001ms
rtt min/avg/max/mdev = 0.715/0.948/5.435/0.979 ms

oder is das unsinn ?
sieht ja auch ziemlich schlecht aus ...

axel · 16. September 2016

Hi,

mal langsam, das rennt via WLAN (Repeater)??

Das erklärt so einiges...

Gruß

Skydiver · 16. September 2016

Nein alles per LAN

Läuft als IP-Client- Modus

axel · 16. September 2016

OK,

also an den ping-Zeiten liegt es mal nicht...

Gruß

Derek Buegel · 16. September 2016

Obwohl es ein bisschen übertrieben ist (im lokalen Netzwerk), würde ich mal ein traceroute empfehlen. Evtl kommen wir ja dahinter, wo das ping-Signal lang geht.

Code:

traceroute -n IP_des_Receivers

MfG

Skydiver · 16. September 2016

einmal der hier :

traceroute to 192.168.178.37 (192.168.178.37), 30 hops max, 60 byte packets
1 192.168.178.37 (192.168.178.37) 4.901 ms 5.784 ms 5.778 ms

und der hier :

traceroute to 192.168.178.33 (192.168.178.33), 30 hops max, 60 byte packets
1 192.168.178.33 (192.168.178.33) 2.061 ms 2.972 ms 2.931 ms

ist das gut oder schlecht ?

hier der korrekte befehl :

root@odroid-jessie64 ~ > traceroute -n 192.168.178.37
traceroute to 192.168.178.37 (192.168.178.37), 30 hops max, 60 byte packets
1 192.168.178.37 3.657 ms 3.610 ms 3.590 ms

root@odroid-jessie64 ~ > traceroute -n 192.168.178.33
traceroute to 192.168.178.33 (192.168.178.33), 30 hops max, 60 byte packets
1 192.168.178.33 1.185 ms 1.143 ms 1.122 ms

Derek Buegel · 16. September 2016

Es ging darum, um zu sehen über wie viele Ecken es läuft. Es sind ja direkte Verbindungen.
Siehst Du wenn Du mal traceroute auf googe machst (spasseshalber).

Code:

traceroute 8.8.8.8

Ich bin Ratlos1

MfG

Odroid C2

Ähnliche Themen

Datenschutz & Transparenz

Datenschutz & Transparenz