48 replies to this topic

[Zuppelan]

Inmiddels is ook bekend of de Vu+ Uno 4K / Enigma2 de load van 15 streams aan kan. Het antwoord is ja: Bij het betreffende aantal streams is 1 kern ongeveer 2/3 bezet met het streamen. De tweede kern blijft dus volledig beschikbaar voor overige taken en de ontvanger blijft prima bedienbaar.

 

Wel is het me menigmaal gelukt deadlocks in Enigma2 te veroorzaken. Dit heeft niet zozeer te maken met de streams zelf, maar met de Pi's die berichtjes via de webif sturen naar de GUI van de ontvanger. Als de PI's in een lus terecht komt, bijvoorbeeld als Omxplayer niet opstart en ze blijven proberen, gaan er meer berichten naar de GUI dan de ontvanger kan tonen (met inachtneming van de timeout). Ondanks dat de Pi's inmiddels pauzes in acht nemen voor zij herstarten, lijkt een regelmatige stream van berichten op de GUI Enigma2 flink van de wijs te brengen, waarna de boel opnieuw gestart moet worden. Dit zal nog wat aandacht vereisen.

 

Maar de conclusie is wel dat een FBC-ontvanger met OpenPLi beslist geschikt is als kopstation voor een private analoge kabelinstallatie, mits uitgerust met de nodige aanvullende hardware om er analoog van te maken.

[WanWizard]

Er draait helaas geen webserver op de box, de webif is gewoon een listener in python, in dezelfde namespace als enigma zelf. Dus hang je die op, dan hangt alles op.

[wortellica]

Leuk om te zien...

[Jork]

+1

[MiLo]

Wel is het me menigmaal gelukt deadlocks in Enigma2 te veroorzaken. Dit heeft niet zozeer te maken met de streams zelf, maar met de Pi's die berichtjes via de webif sturen naar de GUI van de ontvanger. Als de PI's in een lus terecht komt, bijvoorbeeld als Omxplayer niet opstart en ze blijven proberen, gaan er meer berichten naar de GUI dan de ontvanger kan tonen (met inachtneming van de timeout). Ondanks dat de Pi's inmiddels pauzes in acht nemen voor zij herstarten, lijkt een regelmatige stream van berichten op de GUI Enigma2 flink van de wijs te brengen, waarna de boel opnieuw gestart moet worden. Dit zal nog wat aandacht vereisen.

Wat voor "berichtjes" zijn dat dan?

't moet wel mogelijk zijn om te regelen dat die berichten wat cooperatiever worden afgehandeld in de webserver, zodat andere taken ook nog een kans krijgen.

[WanWizard]

De omschrijving lezende bedoelt hij HTTP requests om de box opdrachten te geven via de WebIf. Ik kan me voorstellen dat als die van tig kanten komen, en ook nog eens kunnen loopen, de webif dat niet kan bijbenen...

[MiLo]

Ook heb ik de afgelopen dagen een beetje wat krachttermen geuit richting degene die de pigpio unit geschreven heeft: Objectgeoriënteerd met een "driver" die een GPIO aan moet maken.

Dat komt omdat GPIO lijnen bedienen niet iets is dat de kernel zomaar aan user programma's kan overlaten. Er is geen manier om het goed te doen. Voor elke GPIO lib heb je altijd root rechten nodig, omdat je niet wil dat de webserver ergens kortsluiting kan veroorzaken ofzo. Er is een vervanger voor de /sys/class/gpio/ interface die wat netter werkt vanuit C op de nieuwere kernels, maar ook daarvoor moet je root zijn. Je moet dus altijd een soort GPIO servertje maken die de betreffende GPIO's opent als root, en dan de rootrechten loslaat en dan requests van je programma afhandelt.

Wat wel redelijk werkt is om "gpio" inputs naar buttons te mappen (gpio-button driver), en outputs naar LEDs. Daarmee heb je interrupt-driven input, dus geen poll loop nodig. En voor de LEDs heb je een mode waarin de kernel gegarandeerd de stand weer terug zet na een time-out, daarmee heb ik wel eens elektrische modeltreinwissels bediend... Via udev/mdev ruls kun je dan de access rechten regelen zodat je geen root hoeft te zijn.

Edited by MiLo, 5 April 2019 - 18:46.

[Zuppelan]

Wat voor "berichtjes" zijn dat dan?

't moet wel mogelijk zijn om te regelen dat die berichten wat cooperatiever worden afgehandeld in de webserver, zodat andere taken ook nog een kans krijgen.

http://ontvanger/web...ype=1&timeout=5

Ik zal eens kijken of ik iets reproduceerbaars kan maken, door bijvoorbeeld de nodige berichten in een lus naar de ontvanger te sturen. Sowieso lijkt het me geen slecht idee om als de hoeveelheid berichten in de queue (elk bericht heeft een timeout dus wordt pas na enige tijd getoond) te groot wordt op een bepaald moment te groot wordt geen nieuwe berichten meer te accepteren (beantwoordt bijvoorbeeld met HTTP 503 Server busy), dat voorkomt dat je talloze malen op de exit-knop op de afstandsbediening moet drukken om al die berichten van het scherm te krijgen.

[Zuppelan]

Dat komt omdat GPIO lijnen bedienen niet iets is dat de kernel zomaar aan user programma's kan overlaten. Er is geen manier om het goed te doen. Voor elke GPIO lib heb je altijd root rechten nodig, omdat je niet wil dat de webserver ergens kortsluiting kan veroorzaken ofzo. Er is een vervanger voor de /sys/class/gpio/ interface die wat netter werkt vanuit C op de nieuwere kernels, maar ook daarvoor moet je root zijn. Je moet dus altijd een soort GPIO servertje maken die de betreffende GPIO's opent als root, en dan de rootrechten loslaat en dan requests van je programma afhandelt.

Wat wel redelijk werkt is om "gpio" inputs naar buttons te mappen (gpio-button driver), en outputs naar LEDs. Daarmee heb je interrupt-driven input, dus geen poll loop nodig. En voor de LEDs heb je een mode waarin de kernel gegarandeerd de stand weer terug zet na een time-out, daarmee heb ik wel eens elektrische modeltreinwissels bediend... Via udev/mdev ruls kun je dan de access rechten regelen zodat je geen root hoeft te zijn.

Hmmm... Er is een /dev/gpiomem die wel voor niet-root gebruikers toegankelijk is en tevens het voordeel heeft dat als je die mapt, je altijd het juiste stuk geheugen mapt (verschil per model Raspberry) terwijl bij /dev/mem je zelf verantwoordlijk bent voor het gebruiken van het juiste adres.

Ik had er hierboven nog geen woorden aan besteed, maar als je naar mijn laatste broncode kijkt dan zie je dat ik de pigpio.pas unit vervangen heb door een zelfgeschreven unit gpio_rpi.pas unit die de genoemde nadelen niet heeft. Door slim gebruik van mmap en absolute variabelen heeft die unit gelijk een superlage overhead (lager dan de WiringPi library die voor C aangeboden wordt), doordat de compiler alle adresberekeningen kan reduceren tot een constante.

Edited by Zuppelan, 5 April 2019 - 21:55.