How many streams can Hopper output at one time?

rdinkel said:
I may be way off base, but I understood that each Joey and Hopper user would have full trick play capabilities.
Then the streams you can join doesn't make sense.

This requires a DIRT member to give us the real answer,

Sent from my Toshiba Thrive using SatelliteGuys
 
Then the streams you can join doesn't make sense.

This requires a DIRT member to give us the real answer.
Sent from my Toshiba Thrive using SatelliteGuys
Sure it does. They could allow trick play anywhere within the current buffer independently for each joey. Whether or not it is implemented that way, I don't know.

You seem to be assuming they will essentially be broadcasting the "stream" - I don't think that's the case.
 
I count 16: PTA record (counts as 4), two other records from the satellite tuners, two from OTA record, play out to two Hoppers and 6 Joeys all from the same Hopper. Add two more for OTA. My best guess is that each stream is on the order of 4-5 Mb/s. That's a total of around 10 MB/s so pretty much any modern hard drive should be able to handle it even considering multiple streams (not just one large one). The hard drive may not be the bottleneck in a large system that pulls all streams from one Hopper.

Actually PTA is really ONE stream being laid down on the HDD and should be counted as ONE stream for this discussion. Remember the way PTA works is that only one sat tuner will access the LIL spotbeam and discards all data from that Xpndr but the big 4 broadcasters and lays that down on the HDD.
 
The technical limit is 3 Tuners due to the fact that its designed to work on only 1 coax cable.

With Dish Networks current technology, you can only run a maximum of 3 satellite tuners on a single coax cable. Its very simple, if you run more than 3 Tuners, it will require a second coaxial cable to the set top box.

For most people having 2 cables to the receiver is not an issue, but there is a good perentage of customers out there that their homes are pre-wired for cable and running a second cable is simply not an option due to the costs of fishing walls, or the customer may not approve of running cable on an outside wall.

The problem is with 2 satellite in cables, your going to have a significantly higher number of cancelled installations.

As far as the Joey Boxes, I think there is a potential to run more than 4 of them but again your limited to the 3 Tuners. The more people living in a customers household, and the more Joey boxes you add to the setup, the less satisfied customers will be.

In a 4 TV household with 4 family members, someone is bound not to be happy when they want to watch what they want to watch and have to hop onto an other family members TV show because there are not enough tuners available.

Bottom line, we wouldn't have this issue if Dish had Directv's SWM Technology.
 
As far as the Joey Boxes, I think there is a potential to run more than 4 of them but again your limited to the 3 Tuners. The more people living in a customers household, and the more Joey boxes you add to the setup, the less satisfied customers will be.

In a 4 TV household with 4 family members, someone is bound not to be happy when they want to watch what they want to watch and have to hop onto an other family members TV show because there are not enough tuners available.
Not true. They won't have to hop on another family member's show...they could watch a DVR recording. In fact, all 4 TVs could watch DVR recordings while the 3 tuners are recording other shows.
 
Good to know. I thought the main Hopper and each Joey had two tuners to work with. Now I would not want to ever upgrade to a Hopper Joey system. I rather have separate two tuner receivers like I have now. The reason is because I like having my own content on my dvr without the other households programs on there. My mother records two things at the same time and still watches OTA so one tuner for her would be disastrous. We are always using the two tuner feature.
 
Good to know. I thought the main Hopper and each Joey had two tuners to work with. Now I would not want to ever upgrade to a Hopper Joey system. I rather have separate two tuner receivers like I have now. The reason is because I like having my own content on my dvr without the other households programs on there. My mother records two things at the same time and still watches OTA so one tuner for her would be disastrous. We are always using the two tuner feature.
Still, you could have 2 hoppers separated by an isolator which would give you a similar setup you have with 2 separate receivers, except it would be 2 separate 3-tuner receivers instead of 2-tuner. :)
 
I do not think that the HD is bottleneck in the system. Dish probably uses large allocation blocks, so seeking is probably not much of an issue (after all a minimum of 1 second allocation would solve seeking issues).

Where I see the issue is in the capabilities of the chipset. Remember this is not a general purpose CPU. It is highly specialized and has hardware assist for its duties. So, the real question of how many streams it can handle at once is probably limited by the design. Until it gets in the field and is tested we will probably not know. This is probably not something Dish will ever publish, CSRs will probably not know anything, unless there is some really low limit that a lot of customers will hit.

Since Dish limits the number of TVs on one account, they probably designed the system to handle that number at a minimum.
 
It isnt just about throughput, but more about seek times and read/write head movement. Serving up more than 4 data streams stored in different areas of the hard drive and 3 record streams to other areas of the hard drive, perhaps it is a technical limit that only 3 tuners and 4 TV streams can be handled by the disk. This isn't even taking into account writing OTA streams and perhaps technical hard drive limits are what is delaying OTA tuner support
as well.
To address these concerns, I built a simple model that takes disk latency into consideration:

Sustained transfer (MB/s) 60
Average latency (mS) 10
Streams 16
Chunck (mS) 320
Time spent seaking/chunk (mS) 160
Time remainig for transfer (mS) 160
Bandwidth after seek (MB/s) 30
Bandwidth/stream (Mb/s) 5
Bandwidth needed for all streams (MB/s) 10
Bandwidth utilization 33%

This says that only 33% of the available disk bandwidth is used to support 16 streams of 5 Mb/s each. So I stand by my original statement that the hard drive probably isn't a bottleneck.

For reference, a WD Caviar Black has a sustained transfer rate of 138 MB/s and an average latency of 4.2 mS. I reduced transfer rate and increased latency as more of a worst case.

The key to minimizing affects of latency is to read enough of each stream which I call the "chunk". In this case I used 320 mS (about 400 512 byte sectors). The system is more responsive for "trick playback" with a smaller chunk; less bandwidth is needed for a larger chunk - it's a tradeoff.


I counted PTA as 4 streams to disk because it makes most sense (to me) to disassemble the "big 4" into separate programs and write them to disk separately. PTA could be written as a single $16-20 Mb/s stream and taken apart during playback. That means less bandwidth writing PTA to disk (fewer seeks) but more bandwidth and processing during playback.
 
kwindrem:

Are you using benchmark data for the sustained throughput or specifications?

You should be using a random model for this, as the 16 streams are unlikely to be geometrically close to one another.

While command queueing can help i think 16 streams is a bit optimistic. I'd say 8-10 is more realistic. That's still quite a bit though.

Sent from my MB855 using Tapatalk
 
kwindrem:

Are you using benchmark data for the sustained throughput or specifications?

You should be using a random model for this, as the 16 streams are unlikely to be geometrically close to one another.

While command queueing can help i think 16 streams is a bit optimistic. I'd say 8-10 is more realistic. That's still quite a bit though.

Sent from my MB855 using Tapatalk

I would make the assumption that Dish would allocate a minimum of 1 megabyte clusters with a 4k sector size. 1 MB would be 8 mbit or .5 (at OTA HD rates) to 1.5 (at thier MPEG-4 rates) seconds of video. This would eliminate any HD bottle neck since with 16 streams active they would only need around 16-32 seeks a second. No one is going to complain about wasted space if there is an extra .5 to 1.5 seconds of video in their recording.
 

Question about how long the hiring process takes.

Any chance that this idea would work

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 2)