95 replies to this topic

[Lost in Space]

DMM already has problems in their current OE 2.0 as the enigma2 code is not threadsafe (see latest commits and problems these cause for some plugins), the enigma2 code you are using is even older, so for a fully multithreaded enigma2 you would need to rewrite much more.

 

Just doing multithreadding in a single application like screengrabber, or the ambilight dameons, ... is one thing, really running threads in parrallel needs lots of synchronzation, usage of barriers, semaphores and quorums,... which is a completely different coding stile. And it is the worst if you start with a fat mainloop as it is now.

 

On the other hand enigma2 is NOT that fat, as it ran on VERY slow CPUs like the xilleon of the 7025 already with very limited Memory. Therefore if a single CPU is fast enough and you have enough memeory to cache everything there is no need for most of the suggested changes, and therefore I don't think that they are worth the effort or will happen at all.

 

The interessing things for multiple cores/CPU on a STB are recording threads and streaming threads ... and guess what already works now but is not CPU limited due to the involved IO ?

 

PS: People were dreaming of Zeppelins that could circle the world, then came the (jet) plane and these dreams were dead, but earth is now circled on a regular basis.

Edited by gutemine, 13 May 2013 - 12:32.

[pieterg]

I'm quite sure our enigma2 is threadsafe.

[Lost in Space]

Then read the latest commits of DMM and enjoy explaination and the disucssions with the Plugin developers in their board.

 

http://www.dream-mul...&threadID=17963

 

Believing is not knowing ...

Edited by gutemine, 13 May 2013 - 13:23.

[pieterg]

Our e2 mainloop is quite different from the one dmm is using (though we cannot check this anymore nowadays, but I assume the differences have only grown bigger since then).
So please do not make assumptions about thread safeness, without even looking at our code.

We've spent a lot of time chasing smartpointer and locking bugs over the last few years, and I'm quite sure the e2 core is threadsafe nowadays.

That doesn't mean you are allowed to call e2 functions from python threads however, that is another matter.

[Sjaaky]

Basically we have added an ASSERT(currentThread != mainThread) to eTimer and eSocketNotfier.

We did this to ensure plugins are not calling enigma2 core functionality from any thread other than the main thread.

To make sure a method is called on the main thread I would ASSERT(currentThread == mainThread).

BTW thread safe and "fully multi-threaded" are two different things IMHO. Like MiLo said "Even though E2 spawns a considerable number of threads, most of these threads spend their time waiting on other threads...". Our e2 is believed to be threadsafe, but that doesn't make it "fully multi-threaded" .

[Lost in Space]

Yes, I didn't want to confuse things further, the only problem is that if you want more threading this means different coding style and not just more synchronisation, waits and locks and debugging until they work without causing a mess :-)

 

So the promise of having threads to exploite multithreaded archtectures or multiple CPU cores shoudl stick more to the basic things like is it possible to have the writer thread for multipel recordings running in parallell without screwing up. And that is something which is usefull and already working and caused for example on Dreambox 8000 to decrease the CPU load when the cores were anabled in such case.

 

So it is wrong to say that users have to wait for OE XYZ or any major new developments and codechanges which are not even very likely to happen or would have huge impacts on the performance in case they ever occure.

[pieterg]

multiple recordings already use multiple threads in our e2

[Sjaaky]

So the promise of having threads to exploite multithreaded archtectures or multiple CPU cores shoudl stick more to the basic things like is it possible to have the writer thread for multipel recordings running in parallell without screwing up. And that is something which is usefull and already working and caused for example on Dreambox 8000 to decrease the CPU load when the cores were anabled in such case.

I agree the low-hanging fruit is already implemented. If the more difficult stuff is worth the effort remains to be seen.
 

So it is wrong to say that users have to wait for OE XYZ or any major new developments and codechanges which are not even very likely to happen or would have huge impacts on the performance in case they ever occure.

To which statement are you referring?

[Lost in Space]

Sometimes people/users don't know the effort and problems behind an implementation, they simply want it to work :-)

 

And I was talking about the OpenPLi 4.0 reference, but this was not thought negative, it is only not very likely that anybode will have dramatic improvements in this area as it would be a major re-write of some parts of the code. Enigma2 is is a much better design then enigma1 and Neutrino, but it has some limitations too.

 

And I mean this if you compare it to Frameworks like OpenTV. Hence choosing receiver Hardware is not everything and even drivers are not the point if they do the job - otherwise d-Box would have never made it to the Penguin.

Edited by gutemine, 13 May 2013 - 16:32.

[ims]

Hey guys, excuse me, but I think, that thought "Need a new receiver. Which one ?" to be completely lost in this thread

[gorski]

Cheapest new technology (but questionable drivers, as the first one on the market, without the proper BRDCM support) is GigaBlue Quad (€249).

 

Then, Ruby Cube (XBMC4STB) for some €290 and again, questionable drivers, HW, SW and so on, as it is just out...

 

Least problematic, with all its problems, it seems Duo2 but expensive (€499?)...

 

The most expensive and best drivers will probably be ET10K (Xtrend)...

 

DMM has Goliath planned for December, it seems (€999)...

 

Questions: GigaBlue Quad is single thread processor?

 

Dual Core or thread for Ruby Cube? But MIPS etc?

 

Dual Core for Duo2 = 2 x 1.3 GHz + tons or RAM!

 

We'll see for ET10K later on this year...

 

So, what are one's needs...???

 

(...there is an answer...)

[Rob van der Does]

The GB Quad and the Solo2 have the same CPU (BCM7356 @ 1300KHz). The Quad has suffered from driver issues but seems to be rather mature now.

 

The DUO2 has a different CPU (BCM7424 @ 1300KHz).

 

Both these soc's are not dual-core, but dual-threaded.

[gorski]

Thanx!

 

This is re. Xtrend new boxes coming up...

[gorski]

Damn... Didn't get it...

Attached Files

•  xtrend2014.jpg   71.53KB   61 downloads

[hemertje]

?

[gorski]

This I forgot to attach.

 

It is the ET planned new recs (Xtrend/Clark...)...