|
||||||||
HDR Hard Drive slowing down through Fragmented files? |
![]() |
|
|
Thread Tools | Search this Thread |
|
|
#1 |
|
Forum Member
Join Date: Dec 2008
Posts: 2,494
|
HDR Hard Drive slowing down through Fragmented files?
Anyone else noticed this.
As my hard drive has become fuller and since deleting lots of programmes I've noticed that my box is now responding slower to remote commands. Theres a definitate lag time between pressing a button on the remote and the cursor moving on the screen. To my mind this is a hard drive defragmentation issue as it seems the whole box is slowing down. (Playback and recording are fine but booting and remote commands are slower). I've added a request for a deframentation facility in the feature requests but was wondering if others who've recorded a lot or deleted a lot are now noticing slow downs. |
|
|
|
|
Please sign in or register to remove this advertisement.
|
|
|
#2 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
I would imagine that the allocation blocks are sufficiently large that fragmentation would never be a problem.
There is no way that fragmentation should lead to generally slower response to the RC. Fragmentation really only affects large, sequential, data transfers and if they are suffering the device would not work reliably when viewing or recording. |
|
|
|
|
|
#3 |
|
Inactive Member
Join Date: Oct 2006
Posts: 1,489
|
Funny you should say that I've just been setting up to record stuff, and having around a 2 second delay when I'm key pressing.
Only used around 8% and its 2 days old. |
|
|
|
|
|
#4 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
I would imagine that the allocation blocks are sufficiently large that fragmentation would never be a problem.
There is no way that fragmentation should lead to generally slower response to the RC. Fragmentation really only affects large, sequential, data transfers and if they are suffering the device would not work reliably when viewing or recording. |
|
|
|
|
|
#5 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
Funny you should say that I've just been setting up to record stuff, and having around a 2 second delay when I'm key pressing.
|
|
|
|
|
|
#6 |
|
Forum Member
Join Date: Aug 2001
Location: London UK
Posts: 5,501
|
Why do people assume that PVRs are like PCs in requiring fast access to large volumes of data instantaneously?
Yes, PVRs have large storage requirements, but the bandwidth they need to access that data is fairly low. 6GB per hour, or about 13Gb/s, is about as demanding as a Sky+ gets in terms of data rates (dual recording while watching another). That's a pittance for modern hardware. FYI the allocation block size in Sky+ is about 1.5MB. Usually the box allocates clusters in pairs amounting to 3MB each. When dual recording this can generate fragmentation, but it certainly isn't an issue for a PVR. It never needs to load an entire file in a single go as fast as possible like a PC does. It certainly isn't causing a problem with your remote. I suggest you look at other factors, such as your batteries and interference from IR light sources - Unbelievably LCD TV's are a common source of IR interference. |
|
|
|
|
|
#7 |
|
Forum Member
Join Date: Dec 2008
Posts: 2,494
|
Quote:
I would imagine that the allocation blocks are sufficiently large that fragmentation would never be a problem.
There is no way that fragmentation should lead to generally slower response to the RC. Fragmentation really only affects large, sequential, data transfers and if they are suffering the device would not work reliably when viewing or recording. As to the remote, you are correct in saying that defragmentation can't directly affect the remote. However, I would think it could affect the boxes reponse to the remote command if elements of the control software require information to be retrieved from the hard drive and the hard drive is slowed through file defragmentation. BTW I have a plasma not an LCD. |
|
|
|
|
|
#8 |
|
Inactive Member
Join Date: Oct 2006
Posts: 1,489
|
with my 2 sec delay its not all the time, and I tried the remote right in front of the humax, it only sometimes slows right down, its only happened to me when i'm trying to go through the schedule
|
|
|
|
|
|
#9 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Fragmentation can affect a PC quite badly if allowed to build up and essentially although this is a PVR its using the hard drive in the same way that a pc does. If you get deleted files on any hard drive then the hard drive records into the sectors around them and its the jumping around from sector to sector to retrevive information that can slow things down.
Even with a 24Mb/s data rate and a relatively small 1MB block size there is still 333ms break between block fetches/writes. Since typical seek latency is 8ms and mean rotational latency is < 6ms this means that typical latency is 14ms so even if you were recording two and watching one very high rate HD streams you would still only use 42ms per second to account for drive latency. And that is with a relatively small 1MB block. Typical HD rates and SD rates give even more headroom. It really isn't going to affect performance. (Apart from anything else it would indicate extreme incompetance on the part of Humax if they had configured things this way and I'm certain they have the experience not to do that.) Quote:
BTW I have a plasma not an LCD.
Erm, yes, quite.
|
|
|
|
|
|
#10 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
But fragmentation is only a problem where seek latency is of the same (or a greater order of magnitude) as the inter transfer time.
Since typical seek latency is 8ms and mean rotational latency is < 6ms this means that typical latency is 14ms so even if you were recording two and watching one very high rate HD streams you would still only use 42ms per second to account for drive latency. And that is with a relatively small 1MB block. The above may not add up to fragmentation being a major issue, but can you suggest a reason other than disk performance (including device driver) as to why file delete is disabled while recording? |
|
|
|
|
|
#11 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
The above may not add up to fragmentation being a major issue, but can you suggest a reason other than disk performance (including device driver) as to why file delete is disabled while recording?
The amount of time it takes they could be defragmenting the drive as they go. ![]() They're certainly doing something pretty stupid and I hope they sort it out for the next update. |
|
|
|
|
|
#12 |
|
Forum Member
Join Date: Oct 2004
Location: Caer Lerion Lloegr
Posts: 309
|
Most here are too used to Windows systems! The Humax HDR application software is based around Unix/Linux and therefore should not be susceptible to fragmentation.
Without going into details, Linux will NOT split a file over a disk surface, instead, it finds the most appropriate space. You may theoretically encounter some fragmentation if the disk is allowed to become > 95% full, but not likely to affect performance as mentioned. |
|
|
|
|
|
#13 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
Without going into details, Linux will NOT split a file over a disk surface, instead, it finds the most appropriate space. You may theoretically encounter some fragmentation if the disk is allowed to become > 95% full, but not likely to affect performance as mentioned.
|
|
|
|
|
|
#14 |
|
Forum Member
Join Date: Nov 2008
Location: Co. Donegal
Posts: 797
|
Quote:
The amount of time it takes they could be defragmenting the drive as they go.
![]() |
|
|
|
|
|
#15 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Quite right Caoimhghin! The HDR file system (due to the box running a Linux kernel) is EXT3. See here: http://foxsatdisk.wikispaces.com/The+HDR+filesystem EXT3 does not need defragmenting like Windows filesystems. See here: http://geekblog.oneandoneis2.org/ind..._defragmenting Quote:
Honestly, I've no clue what the hell they are doing when they delete a file.
[cut] They're certainly doing something pretty stupid and I hope they sort it out for the next update. |
|
|
|
|
|
#16 |
|
Forum Member
Join Date: Sep 2006
Location: S Yorks
Posts: 367
|
Quote:
Quite right Caoimhghin! The HDR file system (due to the box running a Linux kernel) is EXT3. See here: http://foxsatdisk.wikispaces.com/The+HDR+filesystem
EXT3 does not need defragmenting like Windows filesystems. See here: http://geekblog.oneandoneis2.org/ind..._defragmenting As anyone with a Linux system knows, the time taken to delete a file is proportional to its size. Fire up your Pentium 4 or faster processor PC (remember how slower the CPU in the HDR runs) running Linux. Create a 3Gb, or 4Gb or even 7Gb (an hour of HD recording, say) file, then delete it - time how long it takes... and tell me who's stupid! |
|
|
|
|
|
#17 |
|
Forum Member
Join Date: Dec 2008
Posts: 2,494
|
Quote:
But fragmentation is only a problem where seek latency is of the same (or a greater order of magnitude) as the inter transfer time.
Even with a 24Mb/s data rate and a relatively small 1MB block size there is still 333ms break between block fetches/writes. I had a WD Raptor 10,000rpm hard drive in my pc and I could notice a difference from fragmentation. In fact game loading times went through the roof. Theoertically, according to what you have said that shouldn't have happened as with a drive as fast as the Raptor the chances of the latency exceeding the inter transfer time were zero. The rest of my PC was fast also so no obvious bottlenecks, in fact I had the fastest 3D mark Score in the World about 12 months ago for a machine running an 8800GT Graphics card. I think awo has a good point about file sizes. The average SD film is going to be many hundreds of megabytes. The average HD film is going to be in gegabytes. Thats bound to cause issues with unfragmented space as recording say a 1 hour programme into a slot previously occupied by a film is going to leave a free space area less than film sized. Get this happening across a drive and when the drive seeks out free space over overwriting "deleted" files, its bound to have to space film info in several seperated blocks that could in theory have gegabytes of info between them. Quote:
BTW I have a plasma not an LCD. Erm, yes, quite. ![]() |
|
|
|
|
|
#18 |
|
Forum Member
Join Date: Jan 2006
Location: Fife
Posts: 4,038
|
Quote:
There is no reason whatever why deletes cannot be scheduled. They don't have to be done straight away!
But some people are so ignorant and arrogant - to call the engineers stupid, when they know so little, is out of order! This thread, and its idea that PVRs' hard drives need defragmenting is ridiculous - name me a PVR that needs this - and I would say it runs on a carppy Windows filesystem! |
|
|
|
|
|
#19 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
I can't claim to know the technical details more than you here Tern, however, I do have a lot of experience on powerful PC's as I used to be an avid gamer.
I had a WD Raptor 10,000rpm hard drive in my pc and I could notice a difference from fragmentation. In fact game loading times went through the roof. Theoertically, according to what you have said that shouldn't have happened as with a drive as fast as the Raptor the chances of the latency exceeding the inter transfer time were zero. The rest of my PC was fast also so no obvious bottlenecks, in fact I had the fastest 3D mark Score in the World about 12 months ago for a machine running an 8800GT Graphics card. I think awo has a good point about file sizes. The average SD film is going to be many hundreds of megabytes. The average HD film is going to be in gegabytes. Thats bound to cause issues with unfragmented space as recording say a 1 hour programme into a slot previously occupied by a film is going to leave a free space area less than film sized. Get this happening across a drive and when the drive seeks out free space over overwriting "deleted" files, its bound to have to space film info in several seperated blocks that could in theory have gegabytes of info between them. Even if it was using NTFS, there would still be no need for fragentation to be a problem simply because the box stores so few files (comparatively) that the allocation block size can be vast. In FAT and NTFS systems block size is a tradeoff between wasted space and tendency to fragmentation. If you have vast numbers of small files this is a serious concern as increasing the block size will reduce fragmentation at the expense of wasted space. (The mean space wastage will be 1/2 the allocation block size per file). A PVR is unusual in that it has to deal with a minute number of vast files and so the tradeoff is not that important. Even if you had an allocation block size of 20MB and filled the disk with 320 1/2 hour SD programmes you would only waste 1% of your disk and fragmentation would not be an issue. |
|
|
|
|
|
#20 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
As anyone with a Linux system knows, the time taken to delete a file is proportional to its size. Fire up your Pentium 4 or faster processor PC (remember how slower the CPU in the HDR runs) running Linux. Create a 3Gb, or 4Gb or even 7Gb (an hour of HD recording, say) file, then delete it - time how long it takes... and tell me who's stupid!
I know you worship Humax and find it unbelievable that anyone would criticise them but for most of us, even though we can very much admire what they have done with this box can, at the same time, see that certain features have not been well thought out and this has led to an interface that is rather clunky in places. You also need to realise that even the best systems engineers do stupid things at times. Most of us on a daily basis! Occasionaly one of our stupid decisions gets out into the wild and has to be corrected at a later stage. Or sometimes you have to go with a 'stupid' feature because it yields a workable product and the customer would rather have that now and wait for a more refined version. Just try and stay relaxed about it. The fact that one can identify a feature as less than optimum doesn't mean one thinks it was programmed by chimps. |
|
|
|
|
|
#21 |
|
Forum Member
Join Date: Dec 2008
Posts: 2,494
|
Quote:
Absolutely, this is on my wishlist, as part of a smart set 'auto-delete' options: http://foxsat-hdr.wikispaces.com/Bug...ues+and+Wishes
But some people are so ignorant and arrogant - to call the engineers stupid, when they know so little, is out of order! This thread, and its idea that PVRs' hard drives need defragmenting is ridiculous - name me a PVR that needs this - and I would say it runs on a carppy Windows filesystem! ...and if you read the link to the Linux file system posted earlier then you'll have noted that the system breaks down into fragmentation when the hard drive is more than 80% full. Thats hardly difficult to achieve on a 320GB drive. I had mine 96% full of files I wanted to keep permanently within 3 weeks of buying the box in November. I actually have a 1TB WD PVR drive in now but since hitting around 35% full I seem to be noticing a slow down in box response (playback and recording are perfectly ok just commands). My remote has always been immediate in response (albeit sometimes from angles it didn't get picked up). Now theres a 1 or 2 second delay between pressing the button and the cursor responding. Similarly when changing channels, if you change quickly in the EPG it easy to overshoot your target channel as the channel indicator lags behind the down / up button presses so you press quickly, it moves, you stop when you think you're on the right channel and a second later after you've stopped it goes right past to next channel. |
|
|
|
|
|
#22 |
|
Forum Member
Join Date: Nov 2006
Posts: 107
|
Quote:
I actually have a 1TB WD PVR drive in now but since hitting around 35% full I seem to be noticing a slow down in box response (playback and recording are perfectly ok just commands). I'm not sure why this should be the case - even with a 1TB drive the number of media files is tiny and the only time the box needs to display them all is in the 'media' view. |
|
|
|
|
|
#23 |
|
Forum Member
Join Date: Sep 2006
Location: S Yorks
Posts: 367
|
Has anybody tried a second (universal) remote to see if it is the signal strength rather than the box causing problems?
|
|
|
|
|
|
#24 |
|
Inactive Member
Join Date: Dec 2008
Posts: 2,324
|
Quote:
Has anybody tried a second (universal) remote to see if it is the signal strength rather than the box causing problems?
![]() It seems a little more responsive to a Harmony but it is clear that there is something in the way the box is designed that stops it working if the remote is not pointed in the general direction of the box. Sadly, RC technology seems to be going backwards. The first RC I had was for a Sony TV around 1980 and it would work perfectly if you pointed it anywhere in the room. Now we have devices that are painfully critical as to from which direction they will receive the signal. |
|
|
|
|
|
#25 |
|
Forum Member
Join Date: Dec 2008
Location: Southampton
Posts: 41
|
Quote:
I had been wondering about this - certainly on Tivo the trade off with larger drives was a slow down of the user interface.
I'm not sure why this should be the case - even with a 1TB drive the number of media files is tiny and the only time the box needs to display them all is in the 'media' view. The issue of fragmentation is interesting, but I believe it to be a red herring as the reason the majority of PVR's (including the old faithful Tivo) use a Linux kernel is because fragmentation is significantly less of an issue with Linux. My Tivo never performed any worse when the disk was full, and that was a series one (about 10 years old now I think), so the technology was significantly lower spec. I think this remote lag issue is something completely different & probably software based. Regards to all Nick |
|
|
|
![]() |
| Thread Tools | Search this Thread |
|
All times are GMT. The time now is 16:11.



