[bpratt]

I'm retired now, but I spent over 30 years in the computer industry mostly as a systems programmer and many of the last years working on Unix and Linux systems. One of the jobs of a systems programmer is to determine and correct performance problems.

I don't claim to know how D* DVRs are programmed, but I know that they use a Linux operating system. Linux is a virtual system, which means that real memory is divided into pages. Many of the pages are fixed and not eligible for swapping. A good portion of the Linux operating is fixed and also any pages used for I/O operations are fixed. I believe the performance issues we now see on the HR2x systems is due to a thing called thrashing.
http://en.wikipedia.org/wiki/Thrashing_(computer_science)

Thrashing is caused when there are so few pages available for paging, the paging rate becomes excessive. The best solution to this problem is to increase real memory. Since this is not possible on existing HR2x systems, another solution needs to be found. I sometimes wonder if the programming staff at D* has any system level programmers and if anyone knows how to solve these problems. If they could streamline their code to make it smaller or find ways to free up some of the fixed pages it would help. Another way to help the problem would be to make all the crap they have added lately optional.

There are some things we can do to speed things up. If you want to add an external disk, get one that is high performance. The 5400 rpm green disks will not perform as well in a system that is doing heavy paging as a 7200 rpm disk. Also, the Linux file system is much different than the file systems used by Windows. Linux uses a journal to keep track of which sectors on disk are available, to chain disk segments together for large files, and to prevent disk corruption in case of a system crash or power failure. The journal resides both on disk and in fixed memory. The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing.

Any I/O pages must be fixed. If you are using Dual Live Buffers or Multi Room Viewing or a connection to the Ethernet, you are causing pages to be fixed and possibly causing the system to thrash.

 

[RACJ2]

I'm retired now, but I spent over 30 years in the computer industry mostly as a systems programmer and many of the last years working on Unix and Linux systems. One of the jobs of a systems programmer is to determine and correct performance problems.

I don't claim to know how D* DVRs are programmed, but I know that they use a Linux operating system. Linux is a virtual system, which means that real memory is divided into pages. Many of the pages are fixed and not eligible for swapping. A good portion of the Linux operating is fixed and also any pages used for I/O operations are fixed. I believe the performance issues we now see on the HR2x systems is due to a thing called thrashing.
http://en.wikipedia.org/wiki/Thrashing_(computer_science)

Thrashing is caused when there are so few pages available for paging, the paging rate becomes excessive. The best solution to this problem is to increase real memory. Since this is not possible on existing HR2x systems, another solution needs to be found. I sometimes wonder if the programming staff at D* has any system level programmers and if anyone knows how to solve these problems. If they could streamline their code to make it smaller or find ways to free up some of the fixed pages it would help. Another way to help the problem would be to make all the crap they have added lately optional.

There are some things we can do to speed things up. If you want to add an external disk, get one that is high performance. The 5400 rpm green disks will not perform as well in a system that is doing heavy paging as a 7200 rpm disk. Also, the Linux file system is much different than the file systems used by Windows. Linux uses a journal to keep track of which sectors on disk are available, to chain disk segments together for large files, and to prevent disk corruption in case of a system crash or power failure. The journal resides both on disk and in fixed memory. The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing.

Any I/O pages must be fixed. If you are using Dual Live Buffers or Multi Room Viewing or a connection to the Ethernet, you are causing pages to be fixed and possibly causing the system to thrash.

Sounds like we should ask DIRECTV to hire you as a consultant. Hopefully thy can figure this out, because some of the old DVR's like the HR20 seem to have performance issues. I'm not experiencing the performance issues with my HR34 or HR22 though.

 

[SFNSXguy]

These issues are not consistent... I have two HR20-700 both have WD20EURS AV-GP 2TB eSATA external drives. Their performance is generally excellent -- only occasional "slow down" reaction to remote control input for 5 min or so, then back to normal. They both are ethernet connected to my LAN and have multi room video too. Remote access is somewhat slower, but not annoying.

 

[TomCat]

I'm retired now, but I spent over 30 years in the computer industry mostly as a systems programmer and many of the last years working on Unix and Linux systems. One of the jobs of a systems programmer is to determine and correct performance problems.

I don't claim to know how D* DVRs are programmed, but I know that they use a Linux operating system. Linux is a virtual system, which means that real memory is divided into pages. Many of the pages are fixed and not eligible for swapping. A good portion of the Linux operating is fixed and also any pages used for I/O operations are fixed. I believe the performance issues we now see on the HR2x systems is due to a thing called thrashing.
http://en.wikipedia.org/wiki/Thrashing_(computer_science)

Thrashing is caused when there are so few pages available for paging, the paging rate becomes excessive. The best solution to this problem is to increase real memory. Since this is not possible on existing HR2x systems, another solution needs to be found. I sometimes wonder if the programming staff at D* has any system level programmers and if anyone knows how to solve these problems. If they could streamline their code to make it smaller or find ways to free up some of the fixed pages it would help. Another way to help the problem would be to make all the crap they have added lately optional.

There are some things we can do to speed things up. If you want to add an external disk, get one that is high performance. The 5400 rpm green disks will not perform as well in a system that is doing heavy paging as a 7200 rpm disk. Also, the Linux file system is much different than the file systems used by Windows. Linux uses a journal to keep track of which sectors on disk are available, to chain disk segments together for large files, and to prevent disk corruption in case of a system crash or power failure. The journal resides both on disk and in fixed memory. The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing.

Any I/O pages must be fixed. If you are using Dual Live Buffers or Multi Room Viewing or a connection to the Ethernet, you are causing pages to be fixed and possibly causing the system to thrash.

Its good to see you on this forum; I remember you from other forums but it seems we rarely see you here.

I think you are probably right about all of this. I assume that the larger file size of the graphics for the HD GUI probably only aggravate this problem. If DTV had given me the option of a shiny new GUI but at the expense of operating speed, I would have said "No, thanks. I'll stick with my ugly 2-dimensional 1988 SD GUI and enjoy a reasonable interaction with my DVRs rather than be treated to watching the shiny new GUI pages for much longer than it takes for me to get bored with them while I am waiting for the next screen to load." And I wouldn't have GUI nag screens to deal with whenever I dub off an SD copy to my DVDR, either.

But you know what's really shocking about this [not]? They never asked my opinion, they just yanked down my trousers and forced upon me (to put it delicately in a family-friendly forum) the new shiny HD GUI, the broken "Smart" search, and the significant decrease in recording reliability that we have seen creep in within the last couple of years.

The quality of DTV DVRs has steadily been going down, while the quality and feature set of DISH DVRs has been steadily going up over the last couple of years, and they will eventually meet in the middle and lap each other. At some point I will be longing for the green grass on the other side of that fence.

I think they need to wake up and smell the propane.

One question, isn't the throughput of the SATA protocol the limiting factor here, meaning that the mild increase in speed from a 7200 RPM HDD might not really amount to much? There certainly are drawbacks as far as heat are concerned.

 

[RACJ2]

Its good to see you on this forum; I remember you from other forums but it seems we rarely see you here.

I think you are probably right about all of this. I assume that the larger file size of the graphics for the HD GUI probably only aggravate this problem. If DTV had given me the option of a shiny new GUI but at the expense of operating speed, I would have said "No, thanks. I'll stick with my ugly 2-dimensional 1988 SD GUI and enjoy a reasonable interaction with my DVRs rather than be treated to watching the shiny new GUI pages for much longer than it takes for me to get bored with them while I am waiting for the next screen to load." And I wouldn't have GUI nag screens to deal with whenever I dub off an SD copy to my DVDR, either.

But you know what's really shocking about this [not]? They never asked my opinion, they just yanked down my trousers and forced upon me (to put it delicately in a family-friendly forum) the new shiny HD GUI, the broken "Smart" search, and the significant decrease in recording reliability that we have seen creep in within the last couple of years.

The quality of DTV DVRs has steadily been going down, while the quality and feature set of DISH DVRs has been steadily going up over the last couple of years, and they will eventually meet in the middle and lap each other. At some point I will be longing for the green grass on the other side of that fence.

I think they need to wake up and smell the propane.

One question, isn't the throughput of the SATA protocol the limiting factor here, meaning that the mild increase in speed from a 7200 RPM HDD might not really amount to much? There certainly are drawbacks as far as heat are concerned.

I would totally agree with you, if that was happening to me. What I can't figure out is why my experience is the complete opposite. My HR22 was worse when I had the SD GUI, sometimes working decent, other times completely annoying. For instance the Menu and Guide taking 5+ seconds to pop up and freeze ups when scrolling through the guide. And trying to key in a channel, was like throwing darts at a dart board to select your channel.

Since the latest version of the HD GUI was downloaded, its worked better then ever. My Menu and Guide pop up within 3 seconds, channel changes are working much better and no freeze ups when scrolling through the guide. So for me, they not only made it look up to date, they improved performance. So why are some subscribers having the exact opposite happen to their DVR?

 

[BattleScott]

I would totally agree with you, if that was happening to me. What I can't figure out is why my experience is the complete opposite. My HR22 was worse when I had the SD GUI, sometimes working decent, other times completely annoying. For instance the Menu and Guide taking 5+ seconds to pop up and freeze ups when scrolling through the guide. And trying to key in a channel, was like throwing darts at a dart board to select your channel.

Since the latest version of the HD GUI was downloaded, its worked better then ever. My Menu and Guide pop up within 3 seconds, channel changes are working much better and no freeze ups when scrolling through the guide. So for me, they not only made it look up to date, they improved performance. So why are some subscribers having the exact opposite happen to their DVR?

Because we all use the same equipment, but we all don't use it the same way. And Im not talking about extrenal drives and such, I mean how we use the device itself.

I have an HR22 as well, and it is at least as bad as it was before the release, but hard to tell if it is worse or not. I also have and HR-24 that was great prior to the release, but is now suffering the problems outlined here.

As a simple example, lets assume that there is a problem with the way the application is written and it resides within the "to-do-list" (please not here!!!) function. Each time the user accesses it, the application is not properly handling an event or exit routine, or whatever and it locks up a little bit of precious resources. In this imaginary scenario, users who use the to-do-list will eventually start complaining about slowness, hang-ups etc. Those who don't, will look at them in wonder and say "strange, my DVR is working great".

Not to defend the application team too much, but this is a universal issue with software testing and support. Most times the fix is easy, finding the cause is the nightmare...

 

[bpratt]

One question, isn't the throughput of the SATA protocol the limiting factor here, meaning that the mild increase in speed from a 7200 RPM HDD might not really amount to much? There certainly are drawbacks as far as heat are concerned.

You are right, there probably is only a slight improvement to be seen from a faster disk or faster processor. The only solution is to streamline the code, free up more memory pages or add more real memory.

 

[John Strk]

The best solution to this problem is to increase real memory.

I couldn't agree more! Just like a PC, the more applications and software you add the slower it runs without adding additional memory or getting a newer faster PC.

Another way to help the problem would be to make all the crap they have added lately optional.

Agreed. While some of these things might be nice to have on a DVR (Score Guide), most of this CRAP (Apps, Youtube, Pandora, annoying ads in the guide, etc.) are just adding to the existing software issues and slowing down our boxes! If I want access to these things I can use my smart phone or computer. Enough is enough. Give me a fast functional HD-DVR that does what it's supposed to do!! :nono2:

 

[djrobx]

One question, isn't the throughput of the SATA protocol the limiting factor here, meaning that the mild increase in speed from a 7200 RPM HDD might not really amount to much? There certainly are drawbacks as far as heat are concerned.

No. I'm not sure which revision of SATA they're using, but the biggest performance gain from a 7200 RPM disk (or SSD, for that matter) comes from a decrease of random-access seek time. Even the oldest SATA rev can do 150MB/sec which is pretty fast.

Let's say you pull up the guide. The DVR is also busy recording the live stream, playing a recording, and possibly serving up video to another DVR in the background. Now you're also asking it to pull guide data information out of the database. Add in virtual memory "thrashing" - the disk has to service several things simultaneously. It has to jump from location to location repeatedly to keep all of its clients satisfied. A disk that can make each jump with less delay will be far more performant, even if the max MB/sec rates were the same. Higher RPMs mean the data will arrive under the disk head following a seek in less time, on average.

 

[TomCat]

No. I'm not sure which revision of SATA they're using, but the biggest performance gain from a 7200 RPM disk (or SSD, for that matter) comes from a decrease of random-access seek time. Even the oldest SATA rev can do 150MB/sec which is pretty fast.

Let's say you pull up the guide. The DVR is also busy recording the live stream, playing a recording, and possibly serving up video to another DVR in the background. Now you're also asking it to pull guide data information out of the database. Add in virtual memory "thrashing" - the disk has to service several things simultaneously. It has to jump from location to location repeatedly to keep all of its clients satisfied. A disk that can make each jump with less delay will be far more performant, even if the max MB/sec rates were the same. Higher RPMs mean the data will arrive under the disk head following a seek in less time, on average.

Well, yes. Most of us understand how a HDD works, and the ramifications to access time if the RPMs are different, and that multiple tasks and limited memory increases paging times. We all get it.

But do the overlords at DTV get it?

All this in spite of the fact that the 5400 RPM HDD is able to stream 12 HD programs at once at modern throughput speeds. Its not a throughput issue due to recordings or playbacks, but for everything else that happens around that, although we could eliminate the playback task when we are in the guide very easily if they would JUST LET US TURN OFF THE PIG AS A USER PREF like we've been asking for since 2007.

I think bpratt's comment about too much peripheral crap is right on the money. There are HR24 owners complaining as well, and that unit has a microprocessor that is virtually twice as fast as the others. That points to virtual memory paging issues.

And as far as "how we use" the DVR, I'm not doing anything all that exotic here; I'm just turning it on and going to the list or the guide, or deleting one program after watching and then trying to watch another. I couldn't give two $#!+s about pandora or MRV or DOD or (cr)apps. Users like me are the target demographic users; we are at the top of the bell curve.

Its the old trying to stuff 8 lbs of $#!+ into a 5-lb bag.

I also am beginning to wonder about the power saver feature. I find the unit even more sluggish when raised from that mode. Many say that all that happens in that mode is that the front panel is turned off. I got hammered unmercifully here for disagreeing, but then no one could present a cogent argument either way, so the issue was dropped. I do know that when it sleeps in power save it is 9 degrees cooler than when it is not asleep, so there must be more power at work in that mode, regardless of what they say. Possibly it stops indexing in power save mode and then hurries up and does it when awake, and when I am trying to get the damned thing to scroll the guide.

Another issue: Apple makes both hardware and software. If you buy a Mac Book Air, for example, the current OS (Lion) is tuned for the chips in that laptop (Sandy Bridge i5's and i7's). It runs like a well-oiled Lamborghini. Whatever succeeds Mountain Lion will be tuned for Ivy Bridge chips. But try to run a 2007 dual-core 2 Mac on Lion, and the experience is not that great. I have a intel Mac Mini that I got in 2006 loaded with Tiger. It fully booted from a dead stop in 18 seconds flat. Damned impressive. When upgraded to Leopard, that took two minutes or more until I maxed out the RAM. Still takes a long time.

My point is this: Even if you control the hardware and OS closely, they need to be matched for optimum performance. An Apple computer is good for about two major up revs before the OS outpaces the hardware. I can't go to the "DTV Store" and buy the latest DVR (well, maybe I can) and I certainly can't run an older OS that is more matched to my HR20 if I so choose. We are disenfranchised from doing so.

And Apple controls this process closely, but DTV can't, because they don't have iron-handed control over both software and hardware, and they don't have the vision to do that choreography as elegantly as Apple. So we end up with an OS mismatched to or overmatched to the hardware. And even older hardware in the Apple universe is iffy with a newer OS. DTV is killing us here. They are the only ones with the control, and they are doing absolutely nothing to fix it.

DTV needs to get hold of this quickly, or suffer the consequences. I and every other typical user will not tolerate incompetence forever.

 

[Richierich]

These issues are not consistent... I have two HR20-700 both have WD20EURS AV-GP 2TB eSATA external drives. Their performance is generally excellent -- only occasional "slow down" reaction to remote control input for 5 min or so, then back to normal. They both are ethernet connected to my LAN and have multi room video too. Remote access is somewhat slower, but not annoying.

I have a similar experience having 5 HR24-500s all with 2 TB WD20EADS Drives in them.

The reason I think all of mine work Perfectly and Fast is that I have a Faster CPU, More RAM than the other Models and a Faster 7200 RPM Drive with a larger Cache (32Mb) so there is less Paging, etc.

That is why I bought the Faster Drives with a larger Cache along with having more Capacity to Store Recordings so all that along with a Faster CPU and More RAM all add up to a Better DVR.

I could care Less about Apps, Pandora (which I have on my BluRay DVD Plaer), DoublePlay (which doesn't work as easily as TiVos Dual Live Buffer), etc.

I do Love and Use MRV (WHDVR Service).

Directv is just asking these tired old DVRs to do too much just so Directv can Boast that they are Better than Dish or Comcrap or whomever while creating a Monster of a DVR that doesn't do the Basic Fundamental Things as Fast or as Good as it should do.

I also have over 1,000 Recordings in my PlayList but it still comes up pretty Fast so that is not causing me problems when I would think it should. Go Figure.

I/O Paging is the Longest and Most Time Consuming Operation in a Computer and the more Paging you have to do the longer the CPU has to wait in order to perform other Tasks (even though it does Multitasking). It can only do so much while waiting for data in order to perform all of these myriad tasks and requests.

 

[dsm]

Ive had HR's since the first couple months they came out and there is one thing I've come to believe. I can't say for sure as this is purely anecdotal, but I find the units work better if I keep the drives with at.least 25% free space. I have one my kids load up and is always max'd out. That one is noticeably slower with the same hardware. By slower I mean guide or list coming up.

By the way, your mileage will vary with natlive mode, some TVs add a big delay to negotiate a new resolution. This isn't the hr's fault.

Having said that, since the new hd GUI, I do periodically hit some bad unresponsive situations. Really bad when it happens, like a minute to bring up the list or guide. Very strange and it has happened on all units. I think every time it has happened there was mrv outgoing from the unit.

Steve

 

[Richierich]

The Only Thing that is Slow on my HR24-500s is Channel Changing because of the HDMI Handshake and I don't watch that much Live TV so I really don't experience the Issues that the other less fortunate posters are having.

The only difference is I have Large 2 TB 7200 RPM WD20EADS Drives with a 32 Mb Cache so maybe that reduces the amount of Paging and I have Faster Seek Times.

Who Knows!!!

 

[drill]

wow ... this thread brings back memories ....

same discussion about 3 years ago. I and others made some of the same points that are discussed here: slow HR* DVR's, caused by crappy software, and added "features" that most people didn't want, slowing down the woefully underpowered hardware. the cry back then was for DirecTV to stop adding features and start improving their core DVR functionality. I guess that request fell on deaf ears. here are just a couple of those threads for reference:

http://www.dbstalk.com/showthread.php?t=164125
http://www.dbstalk.com/showthread.php?t=142335

 

[CCarncross]

Don't forget that one of the most requested features for a long time was an HD GUI....

 

[Richierich]

Don't forget that one of the most requested features for a long time was an HD GUI....

Yes, but not at the Expense of Speed because we have been screaming for more speed in a ton of Posts.

 

[Richierich]

The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing.

Then why do All 5 of my HR24-500s respond Very Fast with No Sluggishness at all with 2 TB WD20EADS Drives in them.

Perhaps it is because they have a Larger Cache and are 7200 RPM Drives and my HR24s have a Faster CPU with More RAM than the HR20, HR21, HR22, HR23 Models.

I don't know as I am not a Linux Systems Programmer but my DVRs work as expected but not my 2 HR23-700s both with 2 TB WD20EADS Drives in them.

The only difference I can see is that my HR24s have a Faster CPU with More RAM than the HR23-700s.

Also, I have MRV (WHDVR Service) and that does not Slow my HR24-500s down which should according to your Theory so Go Figure.

 

[acostapimps]

I'm retired now, but I spent over 30 years in the computer industry mostly as a systems programmer and many of the last years working on Unix and Linux systems. One of the jobs of a systems programmer is to determine and correct performance problems.

I don't claim to know how D* DVRs are programmed, but I know that they use a Linux operating system. Linux is a virtual system, which means that real memory is divided into pages. Many of the pages are fixed and not eligible for swapping. A good portion of the Linux operating is fixed and also any pages used for I/O operations are fixed. I believe the performance issues we now see on the HR2x systems is due to a thing called thrashing.
http://en.wikipedia.org/wiki/Thrashing_(computer_science)

Thrashing is caused when there are so few pages available for paging, the paging rate becomes excessive. The best solution to this problem is to increase real memory. Since this is not possible on existing HR2x systems, another solution needs to be found. I sometimes wonder if the programming staff at D* has any system level programmers and if anyone knows how to solve these problems. If they could streamline their code to make it smaller or find ways to free up some of the fixed pages it would help. Another way to help the problem would be to make all the crap they have added lately optional.

There are some things we can do to speed things up. If you want to add an external disk, get one that is high performance. The 5400 rpm green disks will not perform as well in a system that is doing heavy paging as a 7200 rpm disk. Also, the Linux file system is much different than the file systems used by Windows. Linux uses a journal to keep track of which sectors on disk are available, to chain disk segments together for large files, and to prevent disk corruption in case of a system crash or power failure. The journal resides both on disk and in fixed memory. The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing.

Any I/O pages must be fixed. If you are using Dual Live Buffers or Multi Room Viewing or a connection to the Ethernet, you are causing pages to be fixed and possibly causing the system to thrash.

I seriously think you should email Directv directly give them your insights on how they should do their jobs, who knows maybe they'll hire you as a Consultant or Programmer.

 

[Jon J]

Don't forget that one of the most requested features for a long time was an HD GUI....

Proving once again, "Be careful what you wish for."

 

[Rtm]

I think you nailed the problem.

It's akin to an old computer that can't keep up and even the HR24 has a hiccup here and there but its times better than the 22s. If you listen when your pushing through the menus and guide and pushing Play on a recording when it is taking you know the usual 10-20 seconds from the time you push play or resume. Natively not MRV recorded program on the 22s you can hear the hard drive just chirping away like its at max capacity.