Stabiele opname-image/emu voor 7020?

[Gast]

Ben er zeker van dat het ook niet het netwerk is. Meer netwerkdrivers van de box zelf en emu.

 

Heb nu net gbox emu geinstalleerd. Eens kijken of dat beter gaat met opnames.

 

Ben nu op het werk.. maar heb de hele dag opnames geplannt, dus ik kan vanavond kijken of het beter gaat nu

 

 

grtz

pheno

[Gast]

Met alle mogelijke emus en images heb ik nog nooit een enkele hapering gehad tijdens opnames met mijn 7020, en ik heb al ruim een terabyte aan opnamen gemaakt. Maar, dat allemaal naar een ingebouwde HDD.

Dus ik denk dat je het probleem niet hoeft te zoeken in verschillende emus en images.

 

En aan je netwerk ligt het zeker ook niet, dat is meer dan gemiddeld voor elkaar zo te horen.

Ik neem aan dat het ook niet aan je linuxserver ligt, en dat je daar zaken als dma aan hebt gezet (hdparm)

 

Wel heb ik hier vaker gehoord dat mensen blijkbaar problemen hebben met het netwerk, icm een 7020. Ik weet niet in hoeverre dit altijd beginnersfouten zijn, of dat er werkelijk wat probleempjes zijn.

 

7020 gebruikt de ne2000 compatible networkdriver, die volgens mij al in jaren niet meer wezenlijk veranderd is. En ik neem aan dat de netwerk interface hardware ook voor alle DM typen hetzelfde is.

 

Wel kan ik mij voorstellen dat de 7020 een wat slechtere worst case latency heeft, als gevolg van de wat CPU intensievere NAND flash, waar de 7000 volgens mij nog NOR flash had (toch?)

 

Mijn opnamen haal ik meestal met ftp naar mijn PC over, en haal dan niet veel meer dan 2.5MB/s. (met scp kan je er beter al helemaal niet aan beginnen, dan moet de CPU te hard werken)

 

En wat nog overblijft is de network mount. Ik heb wat dat betreft meer vertrouwen in NFS dan CIFS, maar het blijft een vervelende manier om veel data over te pompen.

Beter zou zijn een stream rechtstreeks naar de server te sturen, met een grote tussenbuffer in ram. Ik weet zeker dat we dan de freezes volledig kunnen uitbannen, omdat er met interne HDD opnamen ter vergelijking nooit wat mis gaat.

 

Maar daarvoor zouden we enigma een beetje moeten ombouwen, zodat hij bijvoorbeeld naar een shared memory device wil schrijven, ipv naar een zelf aangemaakte file in het filesystem.

En dan een daemon maken die de data uit shmem vist, en over het netwerk streamt.

En dan aan serverkant gewoon naar een file catten.

 

Maar waarschijnlijk het simpelst om een 100% betrouwbare oplossing te krijgen voor in je garage, is een HDD inbouwen, en die dan op je linuxserver met een cron scriptje dagelijks leegpompen.

[Gast]

Klinkt geweldig goed dit <img src="/forums/images/graemlins/wink.gif" alt="" />

 

Nu nog een goede programmeur ;-)

 

PS: aan de server ligt het idd niet, de 7000's hebben geen problemen richting dezelfde server en met dezelfde nfs/netwerk instellingen

 

grtz

[Gast]

ps, je kan een hogere wsize proberen in je nfs mount opties.

Default = 1024, maar bijv 8192 kan hogere throughput geven (8KB ram tussenbuffer in de kernel) Of probeer nog een stukje hoger, 8K is nog niks natuurlijk.

 

mount -t nfs -o nolock,wsize=8192 server:export /nfs

[Gast]

Ik had het inmiddels al naar 8K gebracht

 

Maar het probleem is de EMU.... Dat blijf ik roepen, niemand schijnt mij te horen.

 

Gbox / Camx : proces sterft na verloop van tijd (dagen)

Mgcam: Bevriest binnen 't uur

newcamd: Bevriest na een dag

 

Wat kan ik nu gewoon gebruiken voor IMAGE en EMU om een dreambox , standalone (zonder tv), gewoon als stabiele opname box in de garage te laten draaien.

 

Die 7020 is mooie rommel, op mijn 7000 (waarvan voeding nu stuk is) , draaide het MAANDEN achtereen (uptime 90+ dagen) rete-stabiel

 

Smartcard is gewoon in interne reader met cardserver528

 

En ik wil dus niets horen over netwerkinstellingen (tonidustski) of weet ik wat, want de EMU EMU EMU EMU EMU is het probleem.

 

[Gast]

Citaat:

Maar het probleem is de EMU.... Dat blijf ik roepen, niemand schijnt mij te horen.

als de emu processen echt crashen / hangen, ligt het inderdaad aan je emu's. Maar dat had ik nog niet begrepen, ik dacht dat je stotterende opname's had.

Ik heb nog maar net een maand een 7020, dus dreambox ervaring heb ik nauwelijks. Maar ik heb nu wel een uptime van ruim 2 wk, waarin newcamd 6.1 non-stop heeft gedraaid zonder problemen.
Maar ik gebruik mijn 7020 anders dan jij, er wordt flink gezapt, en de tv staat in de regel aan terwijl er opgenomen wordt.
Misschien dat daardoor bugs in de emu daemons getriggerd worden?
Ik heb tot nu toe inderdaad nog niet zo'n goede indruk gekregen van de verschillende soorten emu's die er beschikbaar zijn.
In de regel een zooitje wat config opties betreft, ongedocumenteerd, geen sourcecode beschikbaar voor jan en alleman (wat mij doet vermoeden dat de code net zo'n rommeltje is als het er aan de buitenkant uit ziet)

Natuurlijk ben ik blij dat er mensen zijn die hun vrije tijd in ontwikkeling van emu's willen steken, spaart ons weer een paar tientjes aan een CI adapter, maar door zulke projecten in een opensource community te plaatsen, wordt (en blijft) het produkt doorgaans stabieler.

Als een emu crasht, zou je een corefile kunnen laten dumpen, en die aan de emu ontwikkelaars geven, zodat ze de bug kunnen oplossen.
Crashende processen dumpen core als de core limiet wordt opgekrikt (op embedded sytemen staat de core limiet doorgaans op nul, omdat je flash anders binnen de korste keren volloopt als je buggy software draait)

# ulimit -c unlimited

Als er nu wat crasht (met een segfault), wordt er een coredump (core.pid) gedumpt in de werk-directory van het crashende proces (voor slordig geschreven daemons is dat meestal de directory van waaruit je de daemon met de hand gestart hebt...)

Nu moet je het systeem goed in de gaten houden (met df controleren of de gebruikte ruimte drastisch toegenomen is), zodra er iets crasht, de corefile opzoeken, en copieren naar een PC, en met 'ulimit -c 0' verdere corefiles voorkomen.
Coredumps kunnen namelijk tientallen MB's groot zijn (maar op jffs2 nemen ze gelukkig maar een paar MB in, omdat ze goed comprimeerbaar zijn)

Citaat:

Die 7020 is mooie rommel, op mijn 7000 (waarvan voeding nu stuk is) , draaide het MAANDEN achtereen (uptime 90+ dagen) rete-stabiel

Als ik je verhaal goed begrijp, zal het niet zozeer aan de 7020 zelf liggen, meer aan de matige / wisselende kwaliteit van de uitgebrachtte emu's.
De techniek van een 7020 is stukken beter, met z'n NAND flash, aparte first stage bootloader (zodat je na een mislukte flash actie niet direct met een jtag programmer in de weer hoeft), en een stabielere voeding.
Dit was de reden voor mij om eindelijk eens van kabel op sateliet over te stappen ;-)

Citaat:

Smartcard is gewoon in interne reader met cardserver528

Misschien zou je eens cardserver (en newcamd) 6.1 kunnen proberen, deze gebruik ik eigenlijk ongeveer vanaf het begin, en draait best stabiel.
Ik gebruik overigens gemini 2.0, maar als je voor stabiliteit gaat, zou ik gewoon van een schone officiele stand uitgaan, en handmatig newcamd installeren, verder niets, geen cutting edge enigma's etc.
Minste kans op crashes.

[Tonskidutch]

Citaat:

En ik wil dus niets horen over netwerkinstellingen (tonidustski) of weet ik wat, want de EMU EMU EMU EMU EMU is het probleem.

wel dan probeer je toch eens de camd3 als je de emu .. de schuldige acht.

en stelt bij de camd3 ook eens na een test AU-S=0 in het camd3 config bestandje.

overigens hoef je echt niet zo pedant te worden als anderen je proberen te helpen en suggesties aandragen die eens te testen zijn... dat anderen niet weten wat al getest is geworden is je eigen gebrekkige informatie verstrekking..

cheers