Schwankende ECM Zeiten

[billybilly123]

Hallo Liebes Forum,

habe lokal einen rpi der eine g02 an einen server in moldawien schickt.
auf dem server in moldawien sind die lokale g02 angebunden und 2 weitere sat lines. desweiteren wird dort ce2 gemacht. mit bisher 3 usern und 3 readern.

die ecm vom lokalen proxie also der g02 liegt bei 120-500ms. Das gleiche bei den Cacheex2 Readern.
desweiteren bekomme ich bei einem user derzeit folgende not found

Spoiler

09C7@000000/0019/C35C/5E:49***319EB7F7470558D01D*******): not found (471 ms) by ****** - RTL HD (wait_time over)
016/09/06 14:37:09 3215C0A6 p (cwccheck) cyclecheck [Bad CW Cycle] for: *** 09C7@000000/0037/C375/5E:9EE62AF4EFF92B48859AC8D0C33AB599 from: cs378xRemote -> drop cw (ECM Answer)

Ping tests zu den jeweiligen Clients liegen alle ~60ms. Die Karte die Lokal über cs378x eingebunden wird und abgefragt wird liegt bei 70ms~.

Anbei mal configs, vielleicht könnt ihr mir da weiterhelfen und evtl. sagen woran es liegen könnte das die ecms so stark schwanken. Die load des Servers liegt bei 0.05 avg. cpu bei 5%.

Server confs.
oscam.conf

Spoiler

# oscam.conf generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r11272
# Read more:

Sie müssen registriert sein, um Links zu sehen.

[global]
logfile = /var/log/oscam.log
clienttimeout = 4000
fallbacktimeout = 1000
clientmaxidle = 600
bindwait = 20
unlockparental = 1
nice = -1
waitforcards_extra_delay = 0
preferlocalcards = 1
readerrestartseconds = 10
block_same_ip = 0
lb_save = 1000
lb_nfb_readers = 2
lb_max_ecmcount = 10000
lb_force_reopen_always = 1
lb_auto_betatunnel_mode = 3
lb_auto_timeout_t = 400
failbantime = 1440
failbancount = 50
suppresscmd08 = 1

[anticasc]
enabled = 1

[cache]
max_time = 10
max_hit_time = 9
wait_time = 0500@050F00:200,098C:250,098E:550,09C4:450,1830:900,1843:400,1722:400,05:400,1803:400,1838:400,1835:400,18:400,0D:600,06:1900,0B:900,09C7:400,09:400,01:800,17:400
csp_allow_request = 0
cacheex_cw_check = 0:0:1
cwcycle_check_enable = 1
cwcycle_check_caid = 09C4,0100,0500,0648,09C7,0B00,0B01,0B02,0D05,0D95,0D96,1702,1722,1803,1810,1830,1833,1834,1835,1838,183D,1843,098E
cwcycle_maxlist = 1500
cwcycle_keeptime = 30
cwcycle_allowbadfromffb = 1
cwcycle_usecwcfromce = 1

[cs378x]
port = ******
suppresscmd08 = 1

[cccam]
port = *******
version = 2.3.0
reshare = 2

[webif]
httpport = ***
httpuser = *****
httppwd = *********
httptpl = /var/emu/oscam/picons
httppiconpath = /var/emu/oscam/picons
httphelplang = de
httplocale = de_DE.utf8
httprefresh = 10
httppollrefresh = 1
httphideidleclients = 0
httpshowpicons = 1
httpshowmeminfo = 1
httpshowuserinfo = 1
httpshowreaderinfo = 1
httpshowecminfo = 1
httpshowloadinfo = 1
httpallowed = 0.0.0.0-255.255.255.0
hideclient_to = 15
httposcamlabel = **********

oscam.user
Gruppe 1 G02
Gruppe 2 SAT Karten mit Reshare
Gruppe 10 Cacheex

Spoiler

[account]
user = ******
pwd = ********
description = ******
uniq = 1
group = 1,10
cccstealth = 0

[account]
user = *********
pwd = *********
group = 1,2,10
cacheex = 2
cacheex_maxhop = 3
no_wait_time = 1
cacheex_block_fakecws = 1
cccstealth = 0

oscam.server

Spoiler

# oscam.server generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r11272
# Read more:

Sie müssen registriert sein, um Links zu sehen.

[reader]
label = cs378xRemote
description = lokal
protocol = cs378x
device = *********
user = *******
password = *******
keepalive = 1
cacheex_maxhop = 3
cacheex_ecm_filter = 09C7
cacheex_allow_request = 1
cacheex_block_fakecws = 1
caid = 09C7
group = 1
blockemm-unknown = 1
blockemm-u = 1
blockemm-s = 1
blockemm-g = 1
lb_weight = 111
audisabled = 1

[reader]
label = ********
description = *******
protocol = cccam_ext
device = **********
user = **********
password = **********
inactivitytimeout = 30
group = 2
cccversion = 2.3.0
cccmaxhops = 3
ccckeepalive = 1
cccreshare = 1

[reader]
label = *******
description = sky hd
protocol = cccam_ext
device = *********
user = ********
password = ******
inactivitytimeout = 30
caid = 098C
group = 2
cccversion = 2.3.0
cccmaxhops = 3
cccmindown = 1
ccckeepalive = 1
cccreshare = 1

[reader]
label = *******
protocol = cs378x
device = *********
user = *******
password = **********
inactivitytimeout = 30
keepalive = 1
cacheex = 2
cacheex_maxhop = 3
cacheex_ecm_filter = 1702,1722,1801,1830,1834,1843,1860,1861,09C4,09C7,098C,0B00,09AF,0648
cacheex_drop_csp = 1
cacheex_block_fakecws = 1
group = 10

[reader]
label = ******
protocol = cs378x
device = ************
user = **********
password = **********
inactivitytimeout = 30
keepalive = 1
cacheex = 2
cacheex_maxhop = 3
cacheex_ecm_filter = 1702,1722,1801,1830,1834,1843,1860,1861,09C4,09C7,098C,0B00,09AF
cacheex_drop_csp = 1
group = 10

[reader]
label = ****ce
protocol = cs378x
device = ************
user = **********
password = *********
inactivitytimeout = 30
keepalive = 1
cacheex = 2
cacheex_maxhop = 3
cacheex_ecm_filter = 1702,1722,1801,1830,1834,1843,1860,1861,09C4,09C7,098C,0B00,09AF
cacheex_drop_csp = 1
group = 10

[reader]
label = *****
protocol = cs378x
device = k**********,50001
user = ******
password = ***********
keepalive = 1
group = 2
ccchop = 3

 

[billybilly123]

kann hier niemand helfen? sorry für den push

 

[pidi]

dein "wait_time" eintrag am server liegt für die 09C7 bei 400, der ist bei dem user im log überschritten.
ich würde mal bei dem client die anbindung prüfen bzgl. DLAN, WLAN, netzwerkauslastung etc und mal nen ping über längere zeit vom client zum server laufen lassen.
nach moldawien ist auch ein weiter weg, wenn da im routing unterwegs pakete verloren gehen, kann es schnell zum timeout kommen.

 

[billybilly123]

hey @pidi,

das mit dem routing und ping habe ich bereits ne weile unter der lupe, da ich evtl. auch dachte das es da packet loss gibt oder oder oder... aber nichts dergleichen. die knoten sind sowas von stabil.
habe die wait time seit gestern bereits auf 150 gedrosselt, da die reguläre antwortzeit vom reader der über cs378x bei 120ms liegt.

bis wohin ist der ecm wert denn ausschlaggebend? bis 300ms freezerfrei schaubar?

 

[pidi]

ab wann freeezer auftreten, ist kartenabhängig (da gibts einige erfahrungsberichte hier im forum, bitte suchfunktion nutzen).
vergleich doch mal serverlog und clientlog, wenn freezer auftreten, dann kristallisiert sich recht schnell raus, wo das problem liegt.

 

[4gx35]

nds wie v14 und 09c7 sind leider nicht so tolerant bei ecm,
versuch es auch mal mit dem cccam protokoll,
dass cs3x besser sein soll, scheint eher theoretisch zu sein,
konnte selbst noch nie unterschiede feststellen, aber solche bedingungen wie bei dir hatte ich noch nie,
würde mich mal wirklich interessieren, ob unterschiedliche protokolle wirklich was bringen,
aber vielleicht hast du das schon versucht

 

[pehedima]

Welches das richtige Protokoll ist, kann eigentlich nur ein entsprechender Test zeigen.
Denn jedes Protokoll hat seine Vor- und Nachteile.

Im Vergleich der drei gängisten Protokolle ist cs357x das schnellste, aller einfachste und somit auch fehleranfälligste. Es basiert auf UDP.
Hier findet keine Prüfung statt, ob Pakete überhaupt ankommen usw. Ist eher nur was für HS.
cs378x ist auf Basis TCP schon komfortabeler. Hier wird schon mal geprüft, ob die Pakete auch ankommen usw.
Das mächtigste Protokoll ist cccam (TCP basierend). Bei dem Protokoll werden noch ein Haufen an weiteren Informationen übermittelt, die u.a. auch am Client zur Steuerung von Serveranfragen verwendet werden können usw.

Welches Protokoll am Ende das richtige, stabilste, beste, ... ist, kann nur ein entsprechender Test zeigen, denn die Übertragungsstrecke spielt dabei ebenfalls eine Rolle.