Questions about the Series 3

Advertisements

If you have a star type wired system, I don't see that you would have to isolate the Tivos in some way. Simply because they send fewer packets on the 100Mbit/sec conveyor doesn't mean the conveyer belt is going slower, or that congestion on their belt has any effect on anyone elses belt. And if you are imagining something like a "FedEx sorting room" problem at the switch congestion at the switch, most of that sort of thing doesn't happen because of the smarts in the switch that do things like effectively wire two conveyors together when they are sending traffic (no "collissions- no further management needed).

That is a metaphoric representation of why I don't think you will have a problem even though the T3's might pump data out at slower rates.

The way you are thinking about the internals of the T3 is mistaken, but your feeling that there will be network constraints there is true. Dan pointed out that because it is 100BaseT then the connection out from the T3 has an actual max aroung 70Mbits. So whatever they do inside the box, they are stuck with that because they didn't do 1000BaseT. So you aren't going to initiate a transfer and Boom- it's there on your local T3. Maybe you can jump ahead quickly to points by precaching, so maybe having the Boom transfer gives you nothing.

The problem with the way you are thinking about it is that realtime embedded systems designed for particular tasks are not so centralized as general purpose CPUs. If the CPU can stay out of something, it will. Things are very much going on in parallel. The CPU is not involved with Mpeg2 encoding in an S2 for example. The CPU is pretty much twiddling its thumbs while the encoder shovels bits onto the hard drive. The CPU just steps in to initiate the transfers, configure them, and fire them off. I don't know the particulars, but it is wrong to assume the CPU being the crucial bottleneck. In a properly balanced and most efficient system (both from production cost and from user percieved performance)- the perfect system is where all components are right up very close to being overwhelmed by the task. The complication of this effort is why new custom engineering designs for realtime systems take so long. It is truly and art form that has to be understood to be appreciated.

The guys that do such real time systems are amazing.

 

No reason they couldn't use two standard IDE drive(s). One data bus for each drive.

Right. Sometimes it is in way over its head, othertimes it is idling. ITV was attempting to extrapolate from the encoding task, thinking that since the input in the S3 was digital, the "CPU" would no longer have to do encoding and so there would be a benefit from being "freed up". But in fact it never was burdenned by encoding. Still the overall picture that there would be performance bottlenecks is correct. We just have no way of making much more than external guesses what they would be.

 

Case of degree. The max resolution of the S2 is around 720x480. Also the inbound data rate to an S2 would not be up to the task of HDTv's 20Mbits/second.

Outside of what Mega related in his trip report and TivoPony related, the behavior with S2 is all crackpot speculation, with myself being one of the worst offenders. You probably recall the speculation that you could MRV through the server to downres the file. Well, alternately, the T3 could perform a hardware downres conversion of the HD Mpeg. Nicer that way because the S2 gets it in real time, and gets it at a data rate that it can handle. Then there is the "Do it in a USB peripheral to extend the life of the S2 architecture" trick.

But these scenarios are all shear fantasy at this point. A lot of fun, until TivoPony butts in and makes a definitive announcement about some mind blowing feature and proves us all wrong.

 

I thought we were talking about theoretical S3 system. How do we know how the system was designed? I understand that highly parallel systems introduce complexity. Cripesake- the bugga's got 6 tuners in it.[edit- actually only 2, according to TivoPony in the CES video] Anyhow parallel buses is a way to go, and HD storage balancing is not rocket science.

With that said, I am think I am wrong because they said 250GB hard drive singular, and IDE. Now, if they said 280GB of storage, I would have some room to make a case. If they are 100Mbit transfer rate, the bandwidth is there, but there is going to be a whole lot of head banging going on with the high stress scenario mentioned.

 

Gee. I didn't even notice that Dan already answered you. Sorry for butting in. Anyhow, if you are talking about MRV, then yeah, that's the picture and we are dependent on Tivo to develop it. If you simply want to watch an HD show on an S2 Tivo or for that matter on a DVD, then there will be tons of different ways for folks to do it- similar to the sorts of things you can do with TTG video on a PC. For that you wouldn't be dependent on Tivo at all, but such transfers would take on the order of hours to convert. Think lots and lots of hours for a typical HD movie, on a typical home PC.

 

I wouldn't bet on seeing downresing as feature bundled in a box, either. I just mention it as a technical possibility. Because downresing/ transcoding is a VERY popular application though- less for this, than for generating portable video, I'd not be surprized if you saw a Downresing peripheral. Transcoding has some interesting optimizations you can do in parrallel if you have dedicated hardware.

But in this case we are talking mpeg2 to Mpeg2. I don't know how they assemble the 8x8 DCT blocks, but if it is anything like JPEG, you could simply drop every other DCT and you'd have a downres'd picture without even having to transfor the DCT block into an actual 8x8 bitmap.

Maybe I'm full of crud about that, but I am sure that a cheap external box could be built. Maybe people would like that as a docking station for a portable video device, but it could be unipurpose- it could also offload the Muxing process so TTG would go faster, and it could handle HDTV downresing.

 

Excellent point.