4000 and HDTV poll
- Status
- Not open for further replies.
1 - 9 of 9 Posts
Let's say it this way......when the 4000 comes down in price (or have a very attractive offer for current users and something to do with their old boxes) then I MAY buy it.
HDTV on the other hand is still WAAAAAAAAAY too expensive for 85%+ of the public, but the FCC wants to force everyone to use it, so for those of us who can't afford to replace every TV in the house to a "HDTV compliant" set, in a few years, we will all have to buy adapters for EVERY TV, just to watch TV.
Which does make me wonder......how are the current Replay units doing with HDTV? [is it chopping the extra signal it doesn't use, thus rendering the HDTV part of the signal useless?] Will the 4000 units support HDTV with no problems? Will we have to buy an adapter with EITHER box? Or will we all have to get a Replay 5000 to get ANY usable HDTV functionality? (like working as an adapter with CURRENT TVs) [Too many questions.....probubly the wrong place to be asking as well.....maybe I'll post the question later on.]
HDTV on the other hand is still WAAAAAAAAAY too expensive for 85%+ of the public, but the FCC wants to force everyone to use it, so for those of us who can't afford to replace every TV in the house to a "HDTV compliant" set, in a few years, we will all have to buy adapters for EVERY TV, just to watch TV.
Which does make me wonder......how are the current Replay units doing with HDTV? [is it chopping the extra signal it doesn't use, thus rendering the HDTV part of the signal useless?] Will the 4000 units support HDTV with no problems? Will we have to buy an adapter with EITHER box? Or will we all have to get a Replay 5000 to get ANY usable HDTV functionality? (like working as an adapter with CURRENT TVs) [Too many questions.....probubly the wrong place to be asking as well.....maybe I'll post the question later on.]
Joined
·
204 Posts
OK, so we bit and bought a large HDTV-ready set and a DirectTV HDTV receiver. It *was* a pain to set up, and the off-the-air situation is atrocious.
BUT, wait until you see some of your favorite programs in HDTV! The Sopranos and Band of Brothers are just --- different. It's a completely wonderful change, and it's painful to watch the standard def stuff now. Go to a store that has some nice sets, and ask if they can bring up HD Net. The quality is even better than The Sopranos, et al. Instead of going from film, they're using HD video cams.
Over the past few months HDTV pricing has come down considerably, and it's expected to continue crashing over the next six months. Last year it was time for the rabid lunatic fringe to get HDTV. Now it's time for the early adopters. By end-2002 I'd guess HDTV will represent a reasonable (but still under 15%) percentage of new TV sales.
In another thread , I expressed concerns with Replay's choices in the 4000, and ignoring HDTV was one of them. HDTV already has a higher uptake rate than PVRs, and my guess is that a large number of potential RPTV customers will fuss over the fact that their time-shifted programs will be in standard def. There are also issues with sending remote codes to shift receivers from HD to SD.
HDTV's MPEG4 data rate is 20 Mbits/sec according to this page . I think current systems are 80 Mbits/sec. Whatever! 80 Mbits/sec = 10 Mbytes/sec, which is well in doable range for an IDE drive, even factoring in file system overhead. PVRs that handle HDTV will have to be integrated with the receivers, if only for the copy protection insanity.
Bottom line: I'm still cranky about the feature set of the 4000. I'll probably buy one six months after it comes out, but not before griping some more.
Two great sources of info:
www.hdtvinsider.com (gets you a newsletter)
www.hdtvgalaxy.com (good program listings)
Cheers
BUT, wait until you see some of your favorite programs in HDTV! The Sopranos and Band of Brothers are just --- different. It's a completely wonderful change, and it's painful to watch the standard def stuff now. Go to a store that has some nice sets, and ask if they can bring up HD Net. The quality is even better than The Sopranos, et al. Instead of going from film, they're using HD video cams.
Over the past few months HDTV pricing has come down considerably, and it's expected to continue crashing over the next six months. Last year it was time for the rabid lunatic fringe to get HDTV. Now it's time for the early adopters. By end-2002 I'd guess HDTV will represent a reasonable (but still under 15%) percentage of new TV sales.
In another thread , I expressed concerns with Replay's choices in the 4000, and ignoring HDTV was one of them. HDTV already has a higher uptake rate than PVRs, and my guess is that a large number of potential RPTV customers will fuss over the fact that their time-shifted programs will be in standard def. There are also issues with sending remote codes to shift receivers from HD to SD.
HDTV's MPEG4 data rate is 20 Mbits/sec according to this page . I think current systems are 80 Mbits/sec. Whatever! 80 Mbits/sec = 10 Mbytes/sec, which is well in doable range for an IDE drive, even factoring in file system overhead. PVRs that handle HDTV will have to be integrated with the receivers, if only for the copy protection insanity.
Bottom line: I'm still cranky about the feature set of the 4000. I'll probably buy one six months after it comes out, but not before griping some more.
Two great sources of info:
www.hdtvinsider.com (gets you a newsletter)
www.hdtvgalaxy.com (good program listings)
Cheers
Quote:
I feel I should point out that hard drive performance has been hugely overrated in past years. You see the manufacturers talking about transfer speeds of 33...40...66...80...133...160 megabytes per second, and they aren't telling you the whole story.
The whole story is that's how fast the bus is, and if you're really super lucky, the drive will be able to pump bits into our out of its internal buffer onto the bus that fast, but that buffer is... what? 16MB at best. That's clearly less than a second's worth of 40MB/sec transfer rate.
For sustained data transfer, the actual data rate is ultimately limited by the rate at which the drive's heads fly over the bits on the disk (or more accurately, the rate at which the bits on the disk spin under the disk's head). That rate is governed by two factors: the rate at which the disk spins, and the density of the data on the disk itself.
Here, higher density drives do mean a higher transfer rate, but the differences aren't growing as fast as the manufacturers' claims. Quadruple the data density (as measured in bits per square inch) and you'll see a doubling of transfer rate.
So, in '94, I bought a 4GB 7200 RPM fast/wide SCSI drive that on a good day could do around 6MB/second sustained (20MB/sec burst). Come forward 7 years and pick up a 160G drive in a similar form factor. All other things being equal, that's a 40x increase in data density,meaning about a 6.25x increase in data rate. Oh, you say that 160G drive is only 5400RPM (actually, I don't know)? make that a 4.75x increase in data rate.
In reality, if you can get a SCSI LVD 10,000 RPM drive to sustain a real 20MB/second for an hour, you're doing pretty good - and those are the fast drives. Not impossible, but still high end. If you're talking a 10MB/second data rate for video, then you're going to need at least 20MB/second to record one, watch another, and that's leaving one huge factor out of the equation.
The huge factor that is left out of the equation is disk head seek times. For track to track seeks, you end up spending a significant amount of your time waiting for the seek. That's why a sustained, hour long transfer will come up less than theoretically possible - because you're going to be doing a lot of one-track seeks during that time, and in the world of 20MB/sec transfers, any mechanical movement is going to seem like it takes ages. Which is why a drive that even advertises a "native transfer rate" (meaning the rate at which bits fly under the heads) of something big is going to show considerably less in a sustained transfer.
That's all assuming the data you're reading/writing is on adjacent tracks. For a continuous read or continuous write process on an unfragmented disk, that'll probably be the case.
But, take the case where we're playing one show while recording another. Here, the seek time becomes huge, and effective transfer rates plummet, because we're seeking over large distances. Whereas access times for reading while on track can be measured in micro or nanoseconds, seek times are measured in milliseconds. Talking non-unitary powers of ten here. And even if that doesn't kill you, you'll have an average of a half a rotation's rotational latency to deal with after the seek. The best way to compensate for that is to have a REALLY BIG RAM buffer to reduce the frequency of the seeking. If your data demand is 10MB/sec to read or write, it would seem that a 1 sec buffer in both directions would be a start, meaning a 20MB buffer. Pretty cheap in modern day, but still a lot of RAM.
Of course, pull one recoverable error out of this and the whole house of cards collapses.
Now, there's a lot of other monkeying you can do. For one thing, you can double your data rate by reading more than one bit at a time. For all I know, some drives may do that (or not - I really don't know).
But there are other gotchas. In the name of squeezing every last ounce of data into the drive, they build them with a constant data density. That means the bits are packed as tightly on the outer tracks as they are on the inner tracks. But, the disk rotates at a constant speed so... the data rate is variable. You get a faster data rate on the outer tracks than on the inner tracks. Hook the new drive up, run an hour's worth of speed benchmark, figure you have a fast enough drive, only to discover that it isn't fast enough when it's nearly full. "Native Transfer Rates" also tend to emphasize the fast end of the scale.
If someone told me that they could get an IDE drive to sustain a 10MB/second read and simultaneous 10MB/second write (and the file system overhead would be pretty negligible) for an hour or two at a shot - that wouldn't hugely surprise me. It just don't take the possibility of it happening with just any IDE drive to be a foregone conclusion.
(In case anyone actually read this far and has enough interest left to wonder, yes, I did start my early years computing theoretical disk transfer rates - at first using a slide rule. As demonstrated here, I can be absolutely insufferable when it comes to talking about seek latency, rotational latency, transfer rates and channel utilizations.)
| Originally posted by richardkaufmann Whatever! 80 Mbits/sec = 10 Mbytes/sec, which is well in doable range for an IDE drive, even factoring in file system overhead. |
The whole story is that's how fast the bus is, and if you're really super lucky, the drive will be able to pump bits into our out of its internal buffer onto the bus that fast, but that buffer is... what? 16MB at best. That's clearly less than a second's worth of 40MB/sec transfer rate.
For sustained data transfer, the actual data rate is ultimately limited by the rate at which the drive's heads fly over the bits on the disk (or more accurately, the rate at which the bits on the disk spin under the disk's head). That rate is governed by two factors: the rate at which the disk spins, and the density of the data on the disk itself.
Here, higher density drives do mean a higher transfer rate, but the differences aren't growing as fast as the manufacturers' claims. Quadruple the data density (as measured in bits per square inch) and you'll see a doubling of transfer rate.
So, in '94, I bought a 4GB 7200 RPM fast/wide SCSI drive that on a good day could do around 6MB/second sustained (20MB/sec burst). Come forward 7 years and pick up a 160G drive in a similar form factor. All other things being equal, that's a 40x increase in data density,meaning about a 6.25x increase in data rate. Oh, you say that 160G drive is only 5400RPM (actually, I don't know)? make that a 4.75x increase in data rate.
In reality, if you can get a SCSI LVD 10,000 RPM drive to sustain a real 20MB/second for an hour, you're doing pretty good - and those are the fast drives. Not impossible, but still high end. If you're talking a 10MB/second data rate for video, then you're going to need at least 20MB/second to record one, watch another, and that's leaving one huge factor out of the equation.
The huge factor that is left out of the equation is disk head seek times. For track to track seeks, you end up spending a significant amount of your time waiting for the seek. That's why a sustained, hour long transfer will come up less than theoretically possible - because you're going to be doing a lot of one-track seeks during that time, and in the world of 20MB/sec transfers, any mechanical movement is going to seem like it takes ages. Which is why a drive that even advertises a "native transfer rate" (meaning the rate at which bits fly under the heads) of something big is going to show considerably less in a sustained transfer.
That's all assuming the data you're reading/writing is on adjacent tracks. For a continuous read or continuous write process on an unfragmented disk, that'll probably be the case.
But, take the case where we're playing one show while recording another. Here, the seek time becomes huge, and effective transfer rates plummet, because we're seeking over large distances. Whereas access times for reading while on track can be measured in micro or nanoseconds, seek times are measured in milliseconds. Talking non-unitary powers of ten here. And even if that doesn't kill you, you'll have an average of a half a rotation's rotational latency to deal with after the seek. The best way to compensate for that is to have a REALLY BIG RAM buffer to reduce the frequency of the seeking. If your data demand is 10MB/sec to read or write, it would seem that a 1 sec buffer in both directions would be a start, meaning a 20MB buffer. Pretty cheap in modern day, but still a lot of RAM.
Of course, pull one recoverable error out of this and the whole house of cards collapses.
Now, there's a lot of other monkeying you can do. For one thing, you can double your data rate by reading more than one bit at a time. For all I know, some drives may do that (or not - I really don't know).
But there are other gotchas. In the name of squeezing every last ounce of data into the drive, they build them with a constant data density. That means the bits are packed as tightly on the outer tracks as they are on the inner tracks. But, the disk rotates at a constant speed so... the data rate is variable. You get a faster data rate on the outer tracks than on the inner tracks. Hook the new drive up, run an hour's worth of speed benchmark, figure you have a fast enough drive, only to discover that it isn't fast enough when it's nearly full. "Native Transfer Rates" also tend to emphasize the fast end of the scale.
If someone told me that they could get an IDE drive to sustain a 10MB/second read and simultaneous 10MB/second write (and the file system overhead would be pretty negligible) for an hour or two at a shot - that wouldn't hugely surprise me. It just don't take the possibility of it happening with just any IDE drive to be a foregone conclusion.
(In case anyone actually read this far and has enough interest left to wonder, yes, I did start my early years computing theoretical disk transfer rates - at first using a slide rule. As demonstrated here, I can be absolutely insufferable when it comes to talking about seek latency, rotational latency, transfer rates and channel utilizations.)
Joined
·
204 Posts
Here's the latest performance data I could find on IDE drives:
http://www4.tomshardware.com/storage...rmance-06.html
You'll notice that over a wide range of drives, sustained sequential performance is very comfortably over 10MB/s. For an HDTV app I'll assume the use of one of the mid-range drives that can sustain better than 20MB/s. (I just picked up a new Maxtor 80GB 5400 RPM drive that seems a lot faster than the old 536 that Tom's Review had.)
You make a good point about seek times. I'd assume you'd cover this (as you mentioned) with increased RAM (which is -- at least right now -- ludicrously cheap . 128MB is around $5 to the end-user. That would hide ~13 seconds of HDTV stream (4X more whenever a switch to MPEG-4 happens -- does anybody know if there's a timetable for this?).
The design of the file system is critical for multimedia apps. (5-10 years ago OS scheduling, file system and users interfaces for streaming multimedia was the research topic du jour at a lot of universities and labs.) If you can get the granularity to 8MB (all reads and writes are of 8MB's worth of data -- and are guaranteed to be sequential), then you could even cover cross-disk seeks: assume 20MB/s sequential write on the drive; 2MB = 400 msecs. Seek time is between 10 - 20 msecs these days, which would retard performance less than 5%.
I know that the drive's firmware can remap blocks, but I also understand (but don't know the details about) that the video editing folks (like Avid) have negotiated with the drive manufacturers to address these issues. Was this the error recovery you were referring to? Or were you referring to a higher-level recovery feature in the file system?
Bottom line: If I really wanted to make an HDTV PVR, I'd probably use two of the cooler drives and stripe the data.
Anyway, Toots, thanks for the thoughtful reply!
Cheers,
http://www4.tomshardware.com/storage...rmance-06.html
You'll notice that over a wide range of drives, sustained sequential performance is very comfortably over 10MB/s. For an HDTV app I'll assume the use of one of the mid-range drives that can sustain better than 20MB/s. (I just picked up a new Maxtor 80GB 5400 RPM drive that seems a lot faster than the old 536 that Tom's Review had.)
You make a good point about seek times. I'd assume you'd cover this (as you mentioned) with increased RAM (which is -- at least right now -- ludicrously cheap . 128MB is around $5 to the end-user. That would hide ~13 seconds of HDTV stream (4X more whenever a switch to MPEG-4 happens -- does anybody know if there's a timetable for this?).
The design of the file system is critical for multimedia apps. (5-10 years ago OS scheduling, file system and users interfaces for streaming multimedia was the research topic du jour at a lot of universities and labs.) If you can get the granularity to 8MB (all reads and writes are of 8MB's worth of data -- and are guaranteed to be sequential), then you could even cover cross-disk seeks: assume 20MB/s sequential write on the drive; 2MB = 400 msecs. Seek time is between 10 - 20 msecs these days, which would retard performance less than 5%.
I know that the drive's firmware can remap blocks, but I also understand (but don't know the details about) that the video editing folks (like Avid) have negotiated with the drive manufacturers to address these issues. Was this the error recovery you were referring to? Or were you referring to a higher-level recovery feature in the file system?
Bottom line: If I really wanted to make an HDTV PVR, I'd probably use two of the cooler drives and stripe the data.
Anyway, Toots, thanks for the thoughtful reply!
Cheers,
Quote:
Yah, like I said, I wouldn't be surprised if they could do it, but I'd be surprised if the generic case could.
As for file system overhead: I really don't think it's an issue on the ReplayTV. From what I've been able to guess, the file system probably just tries to preallocate a large (half hour... hour or length of show?) block of contiguous disk and write to it in one fell swoop. For all I know, it goes ahead and writes the retrieval information for that before it's written the first block.
In any case, even on the puny partition (first partition), it looks like it allocates in multi-cluster chunks, and as for the big partition - I don't remember what the allocation unit on it is, but as I recall it's easily large.
One of the big issues of file system performance is how it deals with multiple simultaneous file system requests (as in the case of multitasking OSes), multiple simultaneous allocation streams, and interlocking the whole mess. For the most part, these issues are absent in the ReplayTV environment. The worst you expect for file system overhead on the Replay would be the occasional backtrack to the file index block to update the retrieval pointer to reflect the latest allocation. Since the Replay's allocation map is all in-RAM (built when the drive is mounted), and doesn't exist anywhere on the disk at all, there won't even be seeks back to update the allocation table.
The thing about error recovery is:
Standard error recovery is to try to re-read the sector a few times (meaning a few disk revolutions worth of latency), and if that doesn't work, recalibrate (seek to some preset area - like track 0 - then seek back to the proper cylinder) and try again. Lather, rinse, repeat. Even recoverable errors can take ages, and in the case of 60G Maxtor drives, are a major source of stuttering on my unit.
| Originally posted by richardkaufmann Here's the latest performance data I could find on IDE drives: http://www4.tomshardware.com/storage...rmance-06.html You'll notice that over a wide range of drives, sustained sequential performance is very comfortably over 10MB/s. For an HDTV app I'll assume the use of one of the mid-range drives that can sustain better than 20MB/s. (I just picked up a new Maxtor 80GB 5400 RPM drive that seems a lot faster than the old 536 that Tom's Review had.) Cheers, |
As for file system overhead: I really don't think it's an issue on the ReplayTV. From what I've been able to guess, the file system probably just tries to preallocate a large (half hour... hour or length of show?) block of contiguous disk and write to it in one fell swoop. For all I know, it goes ahead and writes the retrieval information for that before it's written the first block.
In any case, even on the puny partition (first partition), it looks like it allocates in multi-cluster chunks, and as for the big partition - I don't remember what the allocation unit on it is, but as I recall it's easily large.
One of the big issues of file system performance is how it deals with multiple simultaneous file system requests (as in the case of multitasking OSes), multiple simultaneous allocation streams, and interlocking the whole mess. For the most part, these issues are absent in the ReplayTV environment. The worst you expect for file system overhead on the Replay would be the occasional backtrack to the file index block to update the retrieval pointer to reflect the latest allocation. Since the Replay's allocation map is all in-RAM (built when the drive is mounted), and doesn't exist anywhere on the disk at all, there won't even be seeks back to update the allocation table.
The thing about error recovery is:
Standard error recovery is to try to re-read the sector a few times (meaning a few disk revolutions worth of latency), and if that doesn't work, recalibrate (seek to some preset area - like track 0 - then seek back to the proper cylinder) and try again. Lather, rinse, repeat. Even recoverable errors can take ages, and in the case of 60G Maxtor drives, are a major source of stuttering on my unit.
1 - 9 of 9 Posts
- Status
- Not open for further replies.
Join the discussion
AVS Forum
A forum community dedicated to home theater owners and enthusiasts. Come join the discussion about home audio/video, TVs, projectors, screens, receivers, speakers, projects, DIY’s, product reviews, accessories, classifieds, and more!
Full Forum Listing
Recommended Communities
Join now to ask and comment!