# Is Dual Processor Support still MIA?



## TivoRocks193 (Aug 10, 2005)

Now 8 months after Tivo Premiere was released, did Tivo ever push out an update to support the dual core in the units? I recall them promising one 'shortly' but its been awhile now. Is it still MIA?


----------



## smbaker (May 24, 2003)

No second core

No progress on completing HDUI

Those 8 months have seen almost no progress. A couple of fixes for the nastier reboot problems some people were having, but the HDUI is still a bit flaky.


----------



## johnner1999 (Oct 26, 2002)

It's a unicorn 

Wait for the series 5 box

It will be -$59.99 (yes Tivo will pay you) monthly service will be $18.99 and a 5 year contract. Lol.


----------



## TivoRocks193 (Aug 10, 2005)

So did they fire their development team or are they all out on vacation? On paper the changes in Premiere were a welcome step forward but if they haven't made any progress in 8 months to refining the issues, it makes me wonder if they plan to fix these issues at all.


----------



## steinbch (Nov 23, 2007)

TivoRocks193 said:


> So did they fire their development team or are they all out on vacation? On paper the changes in Premiere were a welcome step forward but if they haven't made any progress in 8 months to refining the issues, it makes me wonder if they plan to fix these issues at all.


In the past eight months they have released multiple updates to the software. The initial Premiere shipped with version 14.0. They have updated to 14.1, 14.4, 14.5, 14.6, and 14.7 has started to show up on people's boxes. These updates have helped (not fixed) the speed issues and stability with the HDUI. They have also included things such as Pandora, FrameChannel, and soon to be Hulu+ (based on the press releases). I'd hardly say that the development team is out on vacation. That many software versions sent out to the public would require a large chunk of time writing, compiling, internally testing, beta testing, slow rolling, and full release.

I'm in no way claiming that TiVo has been doing an exceptional job at getting the Premiere better, but I just hate hearing people say that they aren't doing anything.


----------



## TivoRocks193 (Aug 10, 2005)

steinbch said:


> I'm in no way claiming that TiVo has been doing an exceptional job at getting the Premiere better, but I just hate hearing people say that they aren't doing anything.


It's not so much that they aren't doing anything as it is the resources aren't being focused in the right places. The two big impediments since day 1 that have prevented me from upgrading to Premiere have been 1) the second core being disabled 2) the buggy HDUI. The fact that neither of these issues have been solved by now is alarming.

I couldn't care less about the new integration they've added. If the core device is fundamentally broken, they should be working on that instead of adding new features.


----------



## lessd (Jan 23, 2005)

TivoRocks193 said:


> It's not so much that they aren't doing anything as it is the resources aren't being focused in the right places. The two big impediments since day 1 that have prevented me from upgrading to Premiere have been 1) the second core being disabled 2) the buggy HDUI. The fact that neither of these issues have been solved by now is alarming.
> 
> I couldn't care less about the new integration they've added. If the core device is fundamentally broken, they should be working on that instead of adding new features.


At the start TiVo said that they had stability problems using the 2nd core, except on this form no TiVo user knows about or would care about the 2nd core, I could disable the multi core operation on a new PC and I would bet less than 20% of people that purchased that computer would ever know. I know your all hoping the 2nd core gives you a good increase in menu speed but most people don't spend most of the time on the TiVo menu system, watching TV is the primary use and the most time spent on a TiVo. If the menu is faster but watching TV becomes unstable I don't want the 2nd core at all.


----------



## Andyistic (Sep 25, 2009)

johnner1999 said:


> It's a unicorn
> 
> Wait for the series 5 box
> 
> It will be -$59.99 (yes Tivo will pay you) monthly service will be $18.99 and a 5 year contract. Lol.


By then, DRM will have total hold over the entire functionality of the box.
You wont even be able to play a video in your "Now Playing" because any attempt to do so would be a violation.
Trying to connect HDMI to the box will cause the box to shut down,
and it will not restart until you unplug the HDMI.

Oh yes - I am looking forward to Series 5.


----------



## MediaLivingRoom (Dec 10, 2002)

Wait for Series 5 when it has quad core and only 2 will be turned on.


----------



## TivoRocks193 (Aug 10, 2005)

MediaLivingRoom said:


> Wait for Series 5 when it has quad core and only 2 will be turned on.


HA!


----------



## crxssi (Apr 5, 2010)

TivoRocks193 said:


> Now 8 months after Tivo Premiere was released, did Tivo ever push out an update to support the dual core in the units? I recall them promising one 'shortly' but its been awhile now. Is it still MIA?


As far as I have read/seen, no, the second core is still not used (nor even enabled in the kernel). And some additional information from my other posts on this topic might be helpful:

Enabling the second core won't necessarily do all that much for improving the speed of the user interface unless the UI is properly *threaded*. And we don't even know if the base environment they are using (Flash) is coded to be threaded efficiently (or at all). It is not a matter of just "turning something on". And even then, it won't be some miracle. It might help with preventing unusual slow downs at the OS level (since Linux, itself, has been fully threaded forever) when the system is loaded. But CPU loading during user interaction on a TiVo usually only occurs when performing a network transfer (or using the UI). "Recording" doesn't use much CPU at all, and housekeeping is mostly done at program guide updating (which is likely when it is not being used) or during a season pass change (which is neither often nor terribly slow).

If the UI is not threaded, then the other core will sit idle 99% of the time waiting for something to do. If allowed to, the OS, itself (Linux) will happily do other stuff that it can on the other CPU, even if the UI is trapped in a single thread mode. But that probably won't amount to any perceived increase in performance to the end user... which is all that really matters. It might mean less occasional "slowdowns", but to a non-threaded or minimally threaded UI, it would never increase the speed beyond the "normal baseline", it would just help it from being slowed down during other loads (like network transfer, or a tuning change in the background).

The UI could benefit tremendously from more efficient coding. The big improvements in performance we have seen so far were all done from fixing bad code design. Once it is efficient, then they should look at threading. So asking if the second CPU is enabled yet is not really the correct question to be asking.


----------



## johnner1999 (Oct 26, 2002)

This correct they need to optimize the current code before adding to it. I work near a software development team and we support about 4 main applications with about 60 sub apps. 8 months to optimize code for a single unit would not be accepted. TiVo only has two real products it's s4 box and cable boxes. I guess website and programing too. Seems sad IMHO not to mention the years between the s3 and announcing the s4....

Oops forgot they are also working on a directv box too

Maybe they only have a few people in development, I don't know the whole picture but ....



crxssi said:


> As far as I have read/seen, no, the second core is still not used (nor even enabled in the kernel). And some additional information from my other posts on this topic might be helpful:
> 
> Enabling the second core won't necessarily do all that much for improving the speed of the user interface unless the UI is properly *threaded*. And we don't even know if the base environment they are using (Flash) is coded to be threaded efficiently (or at all). It is not a matter of just "turning something on". And even then, it won't be some miracle. It might help with preventing unusual slow downs at the OS level (since Linux, itself, has been fully threaded forever) when the system is loaded. But CPU loading during user interaction on a TiVo usually only occurs when performing a network transfer (or using the UI). "Recording" doesn't use much CPU at all, and housekeeping is mostly done at program guide updating (which is likely when it is not being used) or during a season pass change (which is neither often nor terribly slow).
> 
> ...


----------



## orangeboy (Apr 19, 2004)

johnner1999 said:


> This correct they need to optimize the current code before adding to it. I work near a software development team and we support about 4 main applications with about 60 sub apps. 8 months to optimize code for a single unit would not be accepted. TiVo only has two real products it's s4 box and cable boxes. I guess website and programing too. Seems sad IMHO not to mention the years between the s3 and announcing the s4....
> 
> Oops forgot they are also working on a directv box too
> 
> Maybe they only have a few people in development, I don't know the whole picture but ....


509 full time employees, according to yahoo finance. Not a very big company...


----------



## TivoRocks193 (Aug 10, 2005)

I wonder if they outsourced the Premiere platform. As a software developer myself it reeks of software completed by an outside firm where afterward getting any kind of update to the original is difficult either because the company is holding out for money, or the code has been turned over to the in-house team that has to learn how it works. I find in striking they launched a brand new platform but then backed off obvious/easy updates to it for almost a year.


----------



## SullyND (Dec 30, 2004)

Where did TiVo *promise* dual core support?


----------



## crxssi (Apr 5, 2010)

SullyND said:


> Where did TiVo *promise* dual core support?


As far as I know, they didn't. I don't think they advertise it as dual core either, although it might be listed in the specs (which would be somewhat misleading).


----------



## smbaker (May 24, 2003)

TivoRocks193 said:


> I wonder if they outsourced the Premiere platform.


This is my gut feeling too (although no evidence to back it up). It feels like code that was outsourced, engineered to fit the bare minimum of whatever contractual agreement there was at the time, and then abandoned by the outsourced developer. Whomever coded the Premiere didn't really care about getting the product right, just cared about getting it done to minimum specifications and getting paid. It's like hiring out a construction project to the lowest cost contractor.

I continue to disagree with these repeated assertions that the second core won't speed up performance. It's running Linux. Linux supports dual cores. There's a number of OS tasks that can be performed in the background. The Tivo backend and the UI frontend can probably make use of dual cores without the UI itself needing to be threaded. Recording management, program guide updating, recording itself, can all be done in the background without requiring a threaded UI. It's akin to saying that if I write a single-threaded app in Windows that I won't gain any advantage from a second core, which is simply untrue unless the application is computation-bound. Tivo's UI is not a computation-bound application. There's just no evidence that the second core won't improve performance, and common practice says that it will.


----------



## Shagger (Nov 2, 2007)

smbaker said:


> ...There's just no evidence that the second core won't improve performance, and common practice says that it will...


+1

I say enable the 2nd core to a number of beta testers and gather real world test data about performance improvement. I'll go ahead and put my name out there...


----------



## shaown (Jul 1, 2002)

I really wonder if the second core is already enabled.
I remember the talk that it was not back when the premiere launched but
1) That could really have meant it was not being utilized properly
2) It could have been turned on with 14.4, 14.5, or 14.6 - and there just has not been that big a difference.

Thanks,
-Shaown


----------



## Andyistic (Sep 25, 2009)

How does one view the boot-up messages from Linux when the system starts up?
Is there a way to hook up like a terminal to the box?
That would tell us for sure if the second core is operational.


----------



## MediaLivingRoom (Dec 10, 2002)

The second core if turned on, can take over for Tom Rogers and fix TiVo.


----------



## crxssi (Apr 5, 2010)

smbaker said:


> I continue to disagree with these repeated assertions that the second core won't speed up performance.


Hope you are not talking about me. I never said it would not speed up performance. I said it "won't necessarily do all that much". Big difference. But, it is OK to disagree. We are all operating on "not enough information".



> It's running Linux. Linux supports dual cores. There's a number of OS tasks that can be performed in the background. [...] There's just no evidence that the second core won't improve performance, and common practice says that it will.


It *will* improve performance, but there is no evidence that it will provide a meaningful or noticeable improvement. Common practice for such a dedicated/embedded-type system with not many CPU hungry background tasks (except networking), and a heavy, single-user UI, would tend to disagree with your statement.

I will stake my 25 years of professional computer experience (19 of which is with hundreds of various Linux systems; and the majority of that with multiprocessing Linux systems) that simply enabling a second core in a today-era Premiere will result in "not much noticeable gain in performance" if the UI is not properly threaded (that is a big if). They have taken FOREVER to fix UI and system issues the the Premiere (many of which still remain), so my confidence in them having a properly or even marginally threaded UI is extraordinarily low.

If there were magical (IE- significant) gains to be made by enabling/using the second core, I am guessing they would have done so already. Linux supports multiprocessing very well and has for many years, so there is really little to no reason to intentionally disable the second core. Only things I can think of is perhaps to stay under a certain power profile, maybe they have some really bad proprietary driver that craps out, or maybe the hardware design or certain components are flaky and simply has bugs running in multiprocessing mode.


----------



## JamieP (Aug 3, 2004)

Andyistic said:


> How does one view the boot-up messages from Linux when the system starts up?
> Is there a way to hook up like a terminal to the box?
> That would tell us for sure if the second core is operational.


You can pull the drive and access the var partition from a linux box to examine the kernel log with the bootup messages. It's been checked before for older release, up through 14.4 anyway. I'm not sure anyone has checked 14.7 yet.

Here's the word from TiVoPony on the expected benefit of the second core: link.


----------



## smbaker (May 24, 2003)

JamieP said:


> Here's the word from TiVoPony on the expected benefit of the second core: link.


Unfortunately, he pretty much states the obvious - that the second core will yield improvement that is greater than nothing and less than double.



crxssi said:


> If there were magical (IE- significant) gains to be made by enabling/using the second core, I am guessing they would have done so already. Linux supports multiprocessing very well and has for many years, so there is really little to no reason to intentionally disable the second core.


It's hard to speculate why the Tivo development team behaves as they do. Converting the remaining SD screens in the UI over to HD is also something that I would consider to be minimal work, and yet 8 months have elapsed with no progress on it. For reasons unknown, development is plodding along at a snails pace.

The problem with doing a half-baked buggy release like they did with the Premiere is that it's very possible that an actual hardware flaw could have crept into the design and was mistaken for any easy-to-fix software flaw.

At this point, I have little faith that this product will ever live up to its potential. It may take someone buying out Tivo and firing the management team to get product development back on track.


----------



## duncan7 (Sep 17, 2004)

crxssi said:


> As far as I have read/seen, no, the second core is still not used (nor even enabled in the kernel). And some additional information from my other posts on this topic might be helpful:
> 
> Enabling the second core won't necessarily do all that much for improving the speed of the user interface unless the UI is properly *threaded*. And we don't even know if the base environment they are using (Flash) is coded to be threaded efficiently (or at all). It is not a matter of just "turning something on". And even then, it won't be some miracle. It might help with preventing unusual slow downs at the OS level (since Linux, itself, has been fully threaded forever) when the system is loaded.


I'd say enabling the second core would be worthwhile If it shaved even 25% off the boot time. I wouldn't mind the reboots nearly so much if I could time them with a watch instead of a sundial.

If the UI isn't multi-threaded, what's the mechanism for an erosion of stability when the second core's hot? Bad compiler design?


----------



## TivoRocks193 (Aug 10, 2005)

Why are you all convinced adding the second core wouldn't do anything? Tivo isn't single threaded. These days you can watching 1 show while recording 2 more, while also transferring a show to your computer. On top of that, the Tivo transfer speed has drastically improved with performance directly related to the processor.

Regardless of the evidence performance could improve, it seems suspicious to me that any self-proclaimed 'expert' would make such claims without any hard data. Once they do finally unlock the second core, I'm sure someone will benchmark it and we'll know then for sure.


----------



## crxssi (Apr 5, 2010)

TivoRocks193 said:


> Why are you all convinced adding the second core wouldn't do anything?


Nobody said that. Please re-read.



> Tivo isn't single threaded. These days you can watching 1 show while recording 2 more, while also transferring a show to your computer.


That is multitasking, not threading. Threading is splitting one task (like the UI) into pieces that can be sent to multiple CPU's. It is parallel processing.



> On top of that, the Tivo transfer speed has drastically improved with performance directly related to the processor.


That is more a function of the chipset and ASICS.


----------



## TivoRocks193 (Aug 10, 2005)

crxssi said:


> Enabling the second core won't necessarily do all that much for improving the speed of the user interface


Really?


----------



## crxssi (Apr 5, 2010)

duncan7 said:


> I'd say enabling the second core would be worthwhile If it shaved even 25% off the boot time. I wouldn't mind the reboots nearly so much if I could time them with a watch instead of a sundial.


That is a good point. Of course, I think it would be worthwhile even if only 5%. The TiVo boot speed is absolutely abysmal. Comparison: My single-core, rather slow netbook boots Linux all the way to X in about 20 seconds; and that is unoptimized. Of course, one would hope not to have to reboot a TiVo (I never have to reboot my Linux desktop, for example; except for the occasional kernel or glib update every 3 or 4 months).



> If the UI isn't multi-threaded, what's the mechanism for an erosion of stability when the second core's hot?


Not sure what you are talking about there. I am not aware there are any claims that when a TiVo is running dual-core it would overheat (which would also imply high-use of the other core, something else I would be very skeptical about except maybe during a network transfer or indexing job).



> Bad compiler design?


Nothing is wrong with the Linux compiler or other sub-systems in regards to multi-cpu operation. Multiprocessing on Linux has been solid since at least 1996/97. Of course, who knows what TiVo has done to the Linux kernel in their particular product.


----------



## crxssi (Apr 5, 2010)

TivoRocks193 said:


> Really?


You apparently already read that. Why you are quoting it again is a mystery. If you are trying to make some point then perhaps you still don't comprehend the meaning of the words "won't necessarily" or "all that much"?

Here I will help you:

"wouldn't do anything" is not at all the same as "won't necessarily do all that much".


----------



## CharlesH (Aug 29, 2002)

crxssi said:


> The TiVo boot speed is absolutely abysmal. Comparison: My single-core, rather slow netbook boots Linux all the way to X in about 20 seconds; and that is unoptimized.


In earlier discussions about TiVo boot time, it was stated that a large part of the boot time is spent verifying that the software has not been modified. Like reading every executable module to validate its signature. Apparently this is required to get the required DRM certifications.


----------



## crxssi (Apr 5, 2010)

CharlesH said:


> In earlier discussions about TiVo boot time, it was stated that a large part of the boot time is spent verifying that the software has not been modified. Like reading every executable module to validate its signature. Apparently this is required to get the required DRM certifications.


Yep, I saw that thread. Insane. And probably correct. Isn't DRM so wonderful? As typical with DRM- the honest consumers suffer who pay for boxes, pay for service, pay for cable, pay for encrypting cable cards, forced HDCP TV's, and get stopped by the wonderful "copy bit"... while the torrent guys just download whatever they want with no restrictions at all. And the media companies continue to wonder why their content is constantly stolen. Sorry, had to grumble some.


----------



## johnner1999 (Oct 26, 2002)

well reading into things when you have no real clu of what is going on inside a company is dangerous... 

... BUT what the heck  


I have been noticing a few job postings on twitter from tivo in the past 2-3 weeks. I wonder if they are seeing the errors in their action on the S4? or maybe people have started to churn faster (writing on the wall? or maybe google snatched them up?) But if anything I doubt TiVo will abandon the S4, unless they didn't sell many (could be why they are giving them away now and using the wireless telco or razor and blade strategy) 

BUT who knows - all I know is if you use the HD menus now your tivo box experience TO ME ANYWAY feels like a hack job of non standardized menus and functions. And I still see sero reason for using Flash still!


----------



## smbaker (May 24, 2003)

johnner1999 said:


> But if anything I doubt TiVo will abandon the S4, unless they didn't sell many


For the most part, they are a one-product company. If they were to abandon the S4, then one questions exactly where they would get revenue. It's true they have some partnerships going on, but as I understand those partnerships are for DVR software -- software development directly overlaps with the Premiere. To see such little progress is perplexing.


----------



## aaronwt (Jan 31, 2002)

I don't really care about boot time since the only times my TiVos boot is for a software update. And they reboot automatically at 2AM when I'm in bed. So I don't need it to be any faster for the one time in twenty that I might actually boot a box for a software update before the normal 2AM reboot. I can easily wait the few minutes.


----------



## crxssi (Apr 5, 2010)

aaronwt said:


> I don't really care about boot time since the only times my TiVos boot is for a software update. And they reboot automatically at 2AM.


But you WOULD care if you were one of the people that have to keep rebooting because the box stops responding to remote commands...
http://tivocommunity.com/tivo-vb/showthread.php?p=8287298


----------



## lessd (Jan 23, 2005)

crxssi said:


> But you WOULD care if you were one of the people that have to keep rebooting because the box stops responding to remote commands...
> http://tivocommunity.com/tivo-vb/showthread.php?p=8287298


The real problem is not the re-boot time but the remote hanging up, that should be fixed way before the boot time should even be looked at. (I had that problem before v4.6, have not had it after 14.6).


----------



## bsmith1051 (Nov 15, 2009)

lessd said:


> The real problem is not the re-boot time but the remote hanging up


I suspect the crash/reboots are being caused by networking code which has had all error-checking stripped out to make it as fast as possible, but which then leaves it vulnerable to any Internet interruption. So, rather than timeout and gracefully recover/continue, the code becomes unstable -- and the unit is forced to restart.

If true, this would be a perfect use for the 2nd core: all Internet connections could be moved over and made more robust, and the main code would be updated to use/ignore whatever downloaded image and info there were (or weren't). So a flaky Internet connection would just be a cosmetic issue (as we would have expected but which we know from experience is currently a 'fatal' vulnerability)


----------



## smbaker (May 24, 2003)

bsmith1051 said:


> I suspect the crash/reboots are being caused by networking code which has had all error-checking stripped out to make it as fast as possible, but which then leaves it vulnerable to any Internet interruption.


There's no need to strip out error-checking to speed up code on something like the Premiere. On a highly-optimized high-bandwidth device, sure. The Premiere however uses a general purpose processor and a general purpose Linux operating system. Nothing in the Premiere is network performance bound.

If error-checking is missing then it's due to sloppy programming, not a performance optimization. There are a lot of programmers who unfortunately don't know how to write robust code, don't know to check the return values of systems calls that they expect to succeed, and don't know to design network code to use timeouts to ensure processes don't wait forever.


----------



## Phantom Gremlin (Jun 20, 2002)

smbaker said:


> There are a lot of programmers who unfortunately don't know how to write robust code, don't know to check the return values of systems calls that they expect to succeed, and don't know to design network code to use timeouts to ensure processes don't wait forever.


Well, TiVo claims to do product development in the USA, but their SEC boilerplate says stuff like:

_We have from time-to-time outsourced engineering work related to the design, development, and manufacturing of our products. We have and expect to in the future work with companies located in jurisdictions outside of the United States, including, but not limited to, Taiwan, India, Ukraine, United Kingdom, and Mexico._​
To outsourcing companies, TiVo is a source of cash, it's not a destination for "robust code".


----------



## crxssi (Apr 5, 2010)

bsmith1051 said:


> So, rather than timeout and gracefully recover/continue, the code becomes unstable -- and the unit is forced to restart. If true, this would be a perfect use for the 2nd core: all Internet connections could be moved over and made more robust, and the main code would be updated to use/ignore whatever downloaded image and info there were (or weren't). So a flaky Internet connection would just be a cosmetic issue (as we would have expected but which we know from experience is currently a 'fatal' vulnerability)


What you are sort-of describing is sandboxing combined with a monitoring system that monitors a heartbeat and restarts that code if there is a problem. Really has nothing do with with multi-core, multiprocessing, or threading.


----------



## lb3 (Feb 9, 2009)

duncan7 said:


> If the UI isn't multi-threaded, what's the mechanism for an erosion of stability when the second core's hot?





crxssi said:


> Not sure what you are talking about there. I am not aware there are any claims that when a TiVo is running dual-core it would overheat (which would also imply high-use of the other core, something else I would be very skeptical about except maybe during a network transfer or indexing job).


I believe they were trying to ask:
If the UI isn't multi-threaded, why would the system be less stable when both cores are being used?

I could be wrong, but that would be a first.....


----------



## smbaker (May 24, 2003)

crxssi said:


> What you are sort-of describing is sandboxing combined with a monitoring system that monitors a heartbeat and restarts that code if there is a problem. Really has nothing do with with multi-core, multiprocessing, or threading.


Ideally they would probably use an asynchronous call with event-driven programming. This was generally how Windows worked circa-1990's and largely still works today, so I'm sure Tivo could handle it.

For anyone who is not familiar with event-driven programming, basically the UI sits in a loop waiting for messages (from the OS or from user initiated events like keypresses or mouse movements). When an image is to be downloaded, an asynchronous call is made to a download process and immediately returns. The download process posts a message to the UI when the download is complete, which the UI receives via the message loop and then displays the image. Neither the UI nor the downloader individually needs to be multithreaded, nor is there any need for a multiprocessor. Each component runs while the other is idle.

Event-driven programming can make use of multiprocessing (i.e. the second core) as it would allow both the UI and the downloader to execute simultaneously. However, it's not a requirement.

The usual mistake (in this toy example) is when someone writes code that calls the downloader and waits for the downloader to complete. This causes the caller to block while the callee is working. Works fine in a controlled lab environment but fails miserably in real world situations.


----------



## BobCamp1 (May 15, 2002)

lb3 said:


> I believe they were trying to ask:
> If the UI isn't multi-threaded, why would the system be less stable when both cores are being used?
> 
> I could be wrong, but that would be a first.....


For the PC, there are many games that don't run well when dual-core processors are used. Especially the older games. Even though the game is not supposed to notice and the OS is supposed to be doing all the work.

There is probably some kind of dependence between the various applications inside the Tivo. Linux thinks they are independent when they are actually dependent. Linux tries to execute them on separate cores, but this causes code to get executed out of order, which leads to big problems.

This is even worse on an embedded system, especially when the code is inherited from a uniprocessor system. Embedded code (like PC games) often uses tricks to keep processor and memory usage down. If an app. is not built from the ground up to be multithreaded, it could have issues. Worse, it can be extremely difficult to figure out what's causing the problem. Especially when using Linux, which has a limited set of tools for this purpose.

I am not surprised at all that Tivo is having dual-core problems. They may have to rewrite a good chunk of their 10-year old code to get it to work in a dual-core system.


----------



## machpost (Dec 22, 2010)

TivoRocks193 said:


> I wonder if they outsourced the Premiere platform.


It was mentioned somewhere a while back that the developers working on the Premiere were based in Eastern Europe, but I don't remember exactly where.

I have to wonder if using Flash for the HDUI was a mistake, and if they're finding that it's simply not possible to make it run much faster on the existing hardware. Who knows, we may never see the guide and other menus updated to HD on the Premiere.


----------



## tivogurl (Dec 16, 2004)

johnner1999 said:


> But if anything I doubt TiVo will abandon the S4, unless they didn't sell many


That would tie in to my prediction that TiVo will abandon the S4 as too flawed and replace it. The glacial rate of improvement, to my mind, suggests several possibilities:

1) Their engineering team has been pared down to the bone. Things are slow because there are no bodies working on it.

2) The Flash UI simply cannot be "fixed" to improve its speed, and the interim releases are simply holding actions.

3) Enabling a 2nd CPU should have zero effect on system stability, the single-threaded apps that constitute the TiVo "system" won't care, and neither would a Linux kernel. That enabling the 2nd CPU apparently has deleterious effects on stability suggests an intractable design flaw (single-threaded filesystem?) that would require a total rewrite, which they aren't willing to do.

4) I've done plenty of multi-threaded work on Unix systems. It isn't that hard to do. I've even done stuff where the simpler option was to let the OS scheduler do the work for you by rewriting the system into multiple _processes_ rather than multiple threads within _one_ process. If they aren't doing it, it's because they don't want to. You don't need multiple CPUs to write and test MT software, the scheduler can multiplex threads for you.

5) Most of the engineering team has been retasked to work on an S4 replacement


----------



## Andyistic (Sep 25, 2009)

tivogurl said:


> That would tie in to my prediction that TiVo will abandon the S4 as too flawed and replace it. The glacial rate of improvement, to my mind, suggests several possibilities:
> 
> 3) Enabling a 2nd CPU should have zero effect on system stability, the single-threaded apps that constitute the TiVo "system" won't care, and neither would a Linux kernel. That enabling the 2nd CPU apparently has deleterious effects on stability suggests an intractable design flaw (single-threaded filesystem?) that would require a total rewrite, which they aren't willing to do.


Um ... which they aren't _able_ to do.
I'm guessing the Tivo programmers aren't the most skilled people.
Probably fresh out of high school. 

They probably have more than one person working on the code,
and therefore each portion being programmed isn't 100% compatible
with the other parts, and these slight incompatibilities are causing instability for the entire system,
such as the random reboots we see in the S4.


----------



## smbaker (May 24, 2003)

tivogurl said:


> 3) Enabling a 2nd CPU should have zero effect on system stability, the single-threaded apps that constitute the TiVo "system" won't care, and neither would a Linux kernel.


We don't really know this without knowing more about the system. I've done a lot of multithreading work too (in particular within the Linux kernel) and there are race conditions that will not show up on a single-threaded machine but will happen on a multiprocessor. Not knowing what custom kernel drivers may be used on the Premiere, this could be an issue. Some of the code in a Linux kernel (spinlocks, for one) is often compiled to a no-op on a uniprocessor machine.

I've had application code as well that performed differently on a multiprocessor, although it's far more rare than kernel issues. I've also had code that worked fine on a multiprocessor but failed on a uniprocessor.

I'm going to be in rare agreement with Tivo on this one -- until they can demonstrate the software works reliably on a single core, it's not wise to enable the second core. We have bugs that should have been fixed 8 months ago. For some reason the engineering resources are not being used to fix them. If they can't get basic bugs fixed in reasonable time then there's not much hope of the second core getting enabled either. Maybe 14.7 will get the bugs under control.


----------



## morac (Mar 14, 2003)

Andyistic said:


> Um ... which they aren't _able_ to do.
> I'm guessing the Tivo programmers aren't the most skilled people.
> Probably fresh out of high school.


It might not even be that. If you've ever had to work on poorly commented (or non-commented) legacy code, you know that sometime things are coded so poorly that it appears the only reason they work is by magic. I've worked on code like that in the past (I'd tell you what systems, but I don't want to panic anyone) and it's not fun since making a change in one area has a tendency to break things in a totally unrelated area. It gets to the point where if the code is working "well enough", you don't want to touch it.

I suspect that a lot of the old TiVo code is like that. Despite the new Flash UI, the Premiere contains mostly old C++ code from earlier models, which is why TiVo is always looking for C++ programmers.


----------



## tivogurl (Dec 16, 2004)

smbaker said:


> We don't really know this without knowing more about the system. I've done a lot of multithreading work too (in particular within the Linux kernel) and there are race conditions that will not show up on a single-threaded machine but will happen on a multiprocessor. Not knowing what custom kernel drivers may be used on the Premiere, this could be an issue. Some of the code in a Linux kernel (spinlocks, for one) is often compiled to a no-op on a uniprocessor machine.


Assuming you don't need locks, or that locks can be turned into no-ops, on a uniprocessor is a grave error. Take any simple app with pthread_create() and observe that the scheduler will multiplex your threads even on a uniprocessor.

I've certainly created my share of race conditions. Code that appeared to work on my 4 CPU testbed and instantly deadlocked on the customer's 256 CPU production machine. Oops. The fix, fortunately, was usually only a line or two of code. Saying that it "worked" with 4 CPUs would be wrong, though.

I don't think MT apps are that hard to write. Indeed, I think they're a lot simpler than using asynchronous I/O, which is a rat's nest of horrors.


----------



## smbaker (May 24, 2003)

tivogurl said:


> Assuming you don't need locks, or that locks can be turned into no-ops, on a uniprocessor is a grave error.


It's not a "grave error", it depends on the type of lock. Different kinds of locks have different uses. Spinlocks in the linux kernel are assumed to protect only code that does not block and cannot be preempted. Thus they can (and usually will) in the case of a uniprocessor kernel be optimized out of the kernel. I have personally seen and repaired bugs that were due to inappropriate use of spinlocks where the code worked fine when compiled for a uniprocessor but deadlocked when compiled for a multiprocessor.

The point I'm making is that uniprocessor code may differ from multiprocessor code. It's not simply a matter of 'turning on' the second core as some people think it is. When compiling for a uniprocessor without preemption the programmer can make assumptions about parallelism that are not valid if that code is executed on a multiprocessor.

Whether or not this is what's holding up the second core is speculation. It's certainly likely there are custom drivers in the Tivo kernel for some of the peripherals like the mpeg encoders/decoders, tuners, or cablecard.

Regardless, it's not rocket science, and Tivo needs be about getting the box tested for the second core, fix whatever problems exist, and push out the update. 8 months is too long.


----------



## BobCamp1 (May 15, 2002)

smbaker said:


> The point I'm making is that uniprocessor code may differ from multiprocessor code. It's not simply a matter of 'turning on' the second core as some people think it is. When compiling for a uniprocessor without preemption the programmer can make assumptions about parallelism that are not valid if that code is executed on a multiprocessor.
> 
> Regardless, it's not rocket science, and Tivo needs be about getting the box tested for the second core, fix whatever problems exist, and push out the update. 8 months is too long.


I worked on a project once where that happened. It took six months to figure out one fatal bug. It took 6 weeks just to figure out how to get the bug to appear more often than once a week. We had to get Motorola, the FPGA vendors, VxWorks, and our software engineers involved. Turns out the symptoms observed had nothing to do with the actual bug. That bug was a race condition that existed once in a great while when writing to flash.


----------

