Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

ecm zu schnell, aber doch langsam - freezer

freddchen

Freak
Registriert
18. Januar 2010
Beiträge
221
Reaktionspunkte
234
Punkte
103
Hallo leute, ich habe ein merkwürdiges Phänomen beachtet.

Konstellation ist hier folgendermaßen:
Oscam Server(r10618) --> Client (OScam / Cccam - spielt keine rolle)

Wenn nun der Server ein ecm von dem Client beantwortet und das cw direkt aus dem Cache kommt, steigt die ecm Zeit beim Client auf etwa das doppelte an.

Zur veranschaulichung hier mal die logs vom Client und Server zur gleichen Zeit:
(Achja, ich habe nen delay von 25ms eingestellt. Hatte auch schon 10ms und 0ms -> gleiches Phänomen)

Server log
Code:
2015/07/08 20:36:08  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:51C98CEBA751148753A98F500AEE644E): cache3 (107 ms) CE2 (cw count 2)
2015/07/08 20:36:15  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:2BDF97F31FD204705EBCF9DE70D77F12): cache3 (113 ms) CE2 (cw count 3)
2015/07/08 20:36:22  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:4D044964AAB07866D85F909271CA7390): cache3 (107 ms) CE2 (cw count 3)
2015/07/08 20:36:29  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:20A7C24F0DC4C6E94C3EBF28C2C90188): cache3 (109 ms) CE2 (cw count 2)
2015/07/08 20:36:36  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:159E1F8CB9C3D947D02FC2F701AD9AE2): cache3 (111 ms) CE2 (cw count 3)
[COLOR="#FF0000"]2015/07/08 20:36:43  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:73336B0CD71E3F096A3CE4AEF7C717B6): cache3(25 ms) CE2(cw count 5)[/COLOR]
2015/07/08 20:36:50  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:0117C8157882C02D1D20055C4856910D): cache3 (114 ms) CE2 (cw count 3)
2015/07/08 20:36:57  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:69559683700A59DF2B514F6606FAC791): cache3 (107 ms) CE2 (cw count 3)
2015/07/08 20:37:04  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:729774DD74AB056689346D9BE2F41725): cache3 (112 ms) CE2 (cw count 2)
2015/07/08 20:37:11  1781BD0 c      (ecm) client (098C&000000/0B5E/007B/98:A56094CC94324A6C56E7AE6605FE8E13): cache3 (117 ms) CE2 (cw count 3)

Client Log:
Code:
2015/07/08 20:36:08   54D160 c dvbapiau (098C&000000/0B5E/007B/98:51C98CEBA751148753A98F500AEE644E): found (178 ms) by server
2015/07/08 20:36:15   54D160 c dvbapiau (098C&000000/0B5E/007B/98:2BDF97F31FD204705EBCF9DE70D77F12): found (178 ms) by server
2015/07/08 20:36:22   54D160 c dvbapiau (098C&000000/0B5E/007B/98:4D044964AAB07866D85F909271CA7390): found (179 ms) by server
2015/07/08 20:36:29   54D160 c dvbapiau (098C&000000/0B5E/007B/98:20A7C24F0DC4C6E94C3EBF28C2C90188): found (174 ms) by server
2015/07/08 20:36:36   54D160 c dvbapiau (098C&000000/0B5E/007B/98:159E1F8CB9C3D947D02FC2F701AD9AE2): found (176 ms) by server
[COLOR="#FF0000"]2015/07/08 20:36:43   54D160 c dvbapiau (098C&000000/0B5E/007B/98:73336B0CD71E3F096A3CE4AEF7C717B6): found (343 ms) by server[/COLOR]
2015/07/08 20:36:50   54D160 c dvbapiau (098C&000000/0B5E/007B/98:0117C8157882C02D1D20055C4856910D): found (176 ms) by server
2015/07/08 20:36:57   54D160 c dvbapiau (098C&000000/0B5E/007B/98:69559683700A59DF2B514F6606FAC791): found (177 ms) by server
2015/07/08 20:37:04   54D160 c dvbapiau (098C&000000/0B5E/007B/98:729774DD74AB056689346D9BE2F41725): found (177 ms) by server
2015/07/08 20:37:11   54D160 c dvbapiau (098C&000000/0B5E/007B/98:A56094CC94324A6C56E7AE6605FE8E13): found (177 ms) by server

Habe die Zeilen Rot hervorgehoben....
Man sieht, dass die Zeiten beim Client durchweg normal sind, bis das ECM direkt aus dem Cache vom Server kommt.
Das hier war jezt nur eine Stelle im Log, es tritt aber regelmäßig bei direkten Antworten aus dem Cache auf. Ping etc kann ich ausschließen.

Das Problem ist, dass es bei Clients mit weniger stabilen Leitungen oder WLAN schnell auch mal über die Freeze Grenze geht.
Das ist doch paradox, die schnellsten cw kommen als letztes an :-)

Wie gesagt, es kommt nicht drauf an welche Softcam beim Client läuft. Hab da Oscam, CCcam 2.3.0, CCcam 2.1.1 etc durch.
Geshared wird über das CCcam Protokoll sowie das extended CCcam Protokoll von Oscam

Hier mal ausschnitte aus den ServerConfigs:

Oscam.conf
Code:
[global]
nice = -1
maxlogsize = 50
logfile    = /var/log/O.log
disablelog = 0
dropdups = 1
clientmaxidle = 0
clienttimeout = 5000
failbancount = 9
failbantime = 30
block_same_ip = 0
block_same_name = 1 
lb_mode = 1
lb_save = 1600
lb_retrylimits = 098C:400,1830:1200,1702:1500,1843:1200
lb_nbest_readers = 1
lb_nfb_readers = 1
lb_reopen_seconds = 30
lb_min_ecmcount = 5
lb_max_ecmcount = 600
lb_retrylimit = 2800
lb_stat_cleanup = 336
lb_max_readers = 2


[cache]
[COLOR="#FF0000"]delay = 25[/COLOR]
max_time = 8 
max_hit_time = 15
cacheexenablestats = 0
csp_allow_request = 0
cacheex_cw_check = 0:0:2,1830:0:2,098C:0:2
cwcycle_allowbadfromffb = 1
cwcycle_check_enable  =  1
cwcycle_usecwcfromce  = 1
cwcycle_check_caid = 1702,1833,1830,1843,1860,0D05,0D95,0648,09C7,1722,1834,1801,1861
cwcycle_maxlist = 2000
cwcycle_onbad = 1
wait_time  = 1702:900:1500,098C:100:170,09C4:100:170,1830:300:450,1843:350,0D05:200,0D95:150,1722:1200,1834:1200,1801:400,$00FB:0:0,$0105:0:0,$010F:0:0,$0119:0:0,$0123:0:0,$012D:0:0,$0137:0:0,$0141:0:0,$014B:0:0,$0078:0:0,$00FE:0:0,$014E:0:0

[cccam]
Port = 12345
Reshare = 10
ignorereshare = 0
Version = 2.3.0
stealth  =  0
reshare_mode = 0
keepconnected = 1
updateinterval = 60

Oscam.User
Code:
[account]
user = client 
pwd = 123
group = 1,10
uniq = 3
cccreshare = 0

Oscam.Server
Code:
paar Cacheex Mode 2 und meine lokale v14 Karte.


Vielleicht kann sich ja jemand einen Reim darauf machen.
 
AW: ecm zu schnell, aber doch langsam - freezer

Hi,
ich vermute, dass es schon bei der Anfrage zum Server ein Problem gab.
Es sieht so aus, als ob dieses ECM etwas lang bis zum Server brauchte, evtl. durch einen schlechten Ping.
Wahrscheinlich hatte deshalb der Server auch sofort für dieses ECM alles da, dieses mal sogar schon von fünf Quellen.

Gruß
janni1
 
AW: ecm zu schnell, aber doch langsam - freezer

Habs mal in der Hinsicht überprüft und nen ping 2x pro Sekunde rausgeschickt.
Da sind tatsächlich lücken zu den besagten zeiten. Scheint also daran zu liegen, dass die ecm zu spät ankommen.

Da wär ich so schnell nich drauf gekommen. Danke
 
AW: ecm zu schnell, aber doch langsam - freezer

Wie ist der Client denn angebunden?

LAN...? Internet...?

Ich denke das Problem liegt eher daran.
 
AW: ecm zu schnell, aber doch langsam - freezer

der cleint bin ich selbst. Daher hat es mich auch so gewundert. Habe eigentlich einen stabilen Ping.

Lan kabel im receiver -> DSL Hybrid(DSL 3000, LTE 10000) -> Server

Wird wohl am Hybrid der Telekom liegen.
Habe jetz eine Regel im Router eingestellt, dass dieser Port nur noch über DSL Leitung geschickt wird. Seit dem sind keine Probleme mehr aufgetreten.
Anscheinend hat der immer zwischendurch die lte Leitung benutzt.
 
AW: ecm zu schnell, aber doch langsam - freezer

Es liegt mitunter an deiner [cache] Einstellung (wait_time = ) ...
[global] auch etwas dürftig ...
Code:
# oscam.conf generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r10775

[global]
logfile                       = /var/log/ipc/OScam.log
logduplicatelines             = 1
usrfileflag                   = 1
clienttimeout                 = 9500
fallbacktimeout               = 5850
fallbacktimeout_percaid       = 0500:5800,090F:5900,093E:5900,09C7:850,09C4:485,09:450,0B00:4000,0BAA:5495,18:3600
clientmaxidle                 = 0
netprio                       = 1
unlockparental                = 1
nice                          = -1
maxlogsize                    = 2048
waitforcards                  = 0
waitforcards_extra_delay      = 0
preferlocalcards              = 1
dropdups                      = 1
usrfile                       = /var/log/ipc/oscamuser.log
emmlogdir                     = /var/log/ipc/
lb_mode                       = 1
lb_save                       = 2500
lb_min_ecmcount               = 2
lb_reopen_invalid             = 0
lb_force_reopen_always        = 1
lb_retrylimit                 = 2800
lb_auto_betatunnel            = 0
lb_auto_betatunnel_prefer_beta= 0
lb_savepath                   = /var/etc/stat
lb_retrylimits                = 0100:5500,0500:5500,090F:3800,093E:3200,0963:415,09CD:415,098C:415,09C4:415,09C7:695,0B00:4695,0B01:4300,0B02:2100,0BAA:4795,17:5500,183D:900
ecmfmt                        = c@p/i/s/l
failbantime                   = 960
failbancount                  = 300

[cache]
wait_time                     = 0:5:395,0100@003311:100:195,0100:995,0648:175:375,098C:215,09C4:195,09C7:395,09:50,1702:950,1722:750,1830:520,1843:590,18:995
cacheex_cw_check              = 0:1:1
wait_until_ctimeout           = 1
cwcycle_check_enable          = 1
cwcycle_check_caid            = 0500,0648,0D95,1830,1843
cwcycle_maxlist               = 2000
cwcycle_keeptime              = 1
cwcycle_sensitive             = 0
cwcycle_allowbadfromffb       = 1
cwcycle_usecwcfromce          = 1

[cccam]
port                          = 41557
nodeid                        = 
version                       = 2.3.0
reshare                       = 2
updateinterval                = 30

#
Anscheinend hat der immer zwischendurch die lte Leitung benutzt.
Bei dem geringen Traffic wird noch kein LTE (bei Hybrid) genutzt,
vor allen wenn man noch DSL 3000 sowieso hat ...
 
AW: ecm zu schnell, aber doch langsam - freezer

Okay, den Traffic nur auf die DSL Leitung zu beschränken hat wohl nicht gereicht.

@hwmmc:
An den Confgs wirds nicht liegen. Da die Anfrage ja zu spät reinkommt und dann selbst mit einer Antwortzeit von 0ms nicht mehr rechtzeitig beim Client ankommt. Hab deine Änderungen aber trotzdem mal kurz zum testen übernommen. Hat leider nichts geändert.


Der Fehler tritt auch nur bei 1/10 der Clients auf. Bei allen anderen ist das kein Thema.
Weiter tritt der Fehler nur auf dem "hinweg" auf. Also vom Receiver --> zum Server. Der "Rückweg" ist konstant, dort kommt es nie zu schwankungen.
Demnach wird der Fehler wohl bei der Upload stabilität der Leitung der Clients liegen.(Wenn Receiver direkt per LAN am Router angeschlossen ist)
Ich glaube nicht, dass ich dagegen etwas machen kann, außer schnelleres, stabileres Internet kaufen :-)
 
AW: ecm zu schnell, aber doch langsam - freezer

Wenn du denkst, dann versuch es mal mit recv_timeout = 4000 ... bei cccam.

... schön, dass du eigentlich kein richtiges Problem hast, nur eben mal soeben ein ECM Ausreiser
 
AW: ecm zu schnell, aber doch langsam - freezer

Ich gehe davon aus, dass es an der Internet Leitung liegt,
aber ich lasse mich auch gern eines besseren belehren und bin dankbar für Hilfe.

Habe recv_timeout mal eingefügt und beobachte. Ich habe aber auch schon cs378x und cs357x ohne Erfolg durchprobiert.
 
AW: ecm zu schnell, aber doch langsam - freezer

@freddchen

hast du mittlerweile eine lösung für dein problem? Bei mir tritt seit einiger zeit das gleiche auf.:emoticon-0117-talki

im log ist folgendes zu sehen:

cache instanz :
21:33:34 (ecm) oscam3 (098C@000000/0BBB/0070/98:3B49FED7D08C4C9BADEA1D8EFC8DF370): cache3 (0 ms) by cache - National Geographic HD (cw count 18)
21:33:34 (ecm) oscam3 (098C@000000/0BBB/0070/98:D9783EA706E58201594ADE6D04EF5A8B): cache3 (50 ms) by cache- National Geographic HD

user instanz:
21:33:34 (ecm) wohn (098C@000000/0BBB/0070/98:3B49FED7D08C4C9BADEA1D8EFC8DF370): cache3 (19 ms) by oscam2 (C/1/4/4) - NatGeo HD
21:33:34 (ecm) wohn (098C@000000/0BBB/0070/98:3B49FED7D08C4C9BADEA1D8EFC8DF370): cache3 (30 ms) by oscam2 (C/1/4/4) - NatGeo HD

client insatnz (Box):
21:33:34 (ecm) lokal (098C@000000/0BBB/0070/98:3B49FED7D08C4C9BADEA1D8EFC8DF370): timeout (5000 ms) by root2 -
NatGeo HD
21:33:34 (ecm) lokal (098C@000000/0BBB/0070/98:3B49FED7D08C4C9BADEA1D8EFC8DF370): found (1832 ms) by root2 - NatGeo HD

Gruß
 
Zuletzt bearbeitet:
AW: ecm zu schnell, aber doch langsam - freezer

Das liegt an deine Cache Tauschpartner
Schalt mal jeden einzelnen ab und teste
 
Zurück
Oben