240GB drive for iMod - Please say this will work!
Apr 9, 2009 at 3:03 AM Post #136 of 195
Quote:

Originally Posted by dazzer1975 /img/forum/go_quote.gif
slightly off topic but is related so I will ask here:

If I wanted to replace the logic board in a 5th gen 60gb ipod, with the understanding that I will be getting the 240gb drive in the near future, which logic board should I go for? The 30/60gb version for 5th gen or the 5.5 80gb version logic board?

Apparently the 5th gen 60gb and the 5.5 gen 80 gig logic boards are not interchangable, so am a little confused as to the best way forward for my ipod surgery.

edit: nm solved it, the 60/80 gig version is part number: 820-1975-A while the 30gb version is: 820-1763-A

For anyone else doing this, then I'd suggest getting part number 820-1975-A so it has the added memory over the 30gig version and would come in useful for the database searching etc.



^ incorrect they are totally interchangeable. there is no difference between a 5g 30 and a 5.5g 30gb logic board. there is however a difference between the 30 and 60/80gb versions; they have more memory onboard to handle larger drives. if however you use a 30gb logic board with a larger drive it will be a little sluggish

the main difference between the 5G and 5.5G is a brighter screen
 
Apr 9, 2009 at 8:26 AM Post #137 of 195
Quote:

Originally Posted by qusp /img/forum/go_quote.gif
^ incorrect they are totally interchangeable. there is no difference between a 5g 30 and a 5.5g 30gb logic board. there is however a difference between the 30 and 60/80gb versions; they have more memory onboard to handle larger drives. if however you use a 30gb logic board with a larger drive it will be a little sluggish

the main difference between the 5G and 5.5G is a brighter screen



I guess you missed the edit even though you included it in the quote?
 
Apr 9, 2009 at 9:32 AM Post #138 of 195
Quote:

Originally Posted by qusp /img/forum/go_quote.gif
if however you use a 30gb logic board with a larger drive it will be a little sluggish


so this means i gotta source a 60/80gb 5/5.5g if i wanna stick a much larger drive in my current 30gb, otherwise it gonna be slow??

any reason why it gonna be slower
 
Apr 9, 2009 at 5:23 PM Post #141 of 195
Especially with a drive that large, defragmenting is never a bad idea.
 
Apr 10, 2009 at 4:24 AM Post #142 of 195
Quote:

Originally Posted by dazzer1975 /img/forum/go_quote.gif
I guess you missed the edit even though you included it in the quote?


LOL I think you mustve edited it while I was doing something else and then I quoted it hehe. man we arent having good time with quotes are we; besides wasnt meant to be any kind of slight; just a correction.

Quote:

so this means i gotta source a 60/80gb 5/5.5g if i wanna stick a much larger drive in my current 30gb, otherwise it gonna be slow??

any reason why it gonna be slower


did you actually read my post?? its got less memory on the logic board, so like the equivalent of not having enough ram on your computer. =and compounded by the fact that with a drive that large, you are likely to have many, many files.

so I wouldnt do it; why waste that much money on a HD and have it perform like a dog. plus your battery life will be shorter for 2 reasons: the drive may chew more energy, ahh no strike that steve said its more efficient. but the next is the amount of times it has to read from the disk will increase as it wont have as much memory to store files asthey play. the drive will become fragmented faster too. it'll work, but I think its worth the extra $$$ to get a new logic board. be careful though; many ebay sellers sell boards as 80gb versions and they arent. also ones that say 30,60-,80 are usually 30, even rapid repair have supplied me with a 30gb board twice when I have asked specifically for a 60-80 and even when I ordered my 120 they supplied a 30gb board.

the mopdel number is the best way to get the right one as most dodgies wont even know that. also makes installing rockbox a PITA as it will instal the 30gb version, which only has battery sizes up to 600 or something. so you would have to do a manual install or compile your own build
 
Apr 10, 2009 at 11:36 AM Post #143 of 195
Quote:

Originally Posted by qusp /img/forum/go_quote.gif
LOL I think you mustve edited it while I was doing something else and then I quoted it hehe. man we arent having good time with quotes are we; besides wasnt meant to be any kind of slight; just a correction.


lol yer its me, ive been using forums since 1998 and I still dont know how to use them properly lmao
redface.gif
tongue.gif
 
Apr 10, 2009 at 10:06 PM Post #144 of 195
Well it could only become fragmented when you are writing files to it, not reading. I just wanted to clarify this. I wonder how performance would be effected for those using folder navigation in rockbox. Logically that would not be nearly as slow as using a database.
 
Apr 11, 2009 at 6:06 AM Post #145 of 195
Quote:

Originally Posted by zeroibis /img/forum/go_quote.gif
Well it could only become fragmented when you are writing files to it, not reading. I just wanted to clarify this. I wonder how performance would be effected for those using folder navigation in rockbox. Logically that would not be nearly as slow as using a database.


well if an ipod was just a drive yes, but its not; its a OS and running off the drive too, not in memory like the original firmware. I would think rockbox would be writing files all the time. every time you play something it creates a playlist, not sure if the antiskip buffer is in ram or on disk with RB; although I guess most things it would write would be small enough to be stored in memory without spilling out onto scratch space. one good thing though is that because of the large size of this drive, you would be less likely to be needing to write to it from your PC often

either way, its not a great idea; I ran a 120 off a 30gb board for a while and it was pretty slow already, so I imagine the 240 would be worse.
 
Apr 11, 2009 at 9:51 PM Post #146 of 195
Assuming that the system works anything like a regular computer it would always write to ram first and then overflow into the paging file (or its equivalent) on the HDD. It is important to note however that a bigger HDD may also have a bigger cache and thus would help to offset its size. Also, because of increased areal density read and write performance would be increased. In fact I would bet heavily that if you took this drive and another and filled them with the same amount of data lets say 80GB the 240GB drive would out preform every time. Also, in theory because data is stored in higher density it would not require as many rotations to access said data and thus power would be saved. Although actual saving would vary from model to model depending on how it is built.

I would say that logically if your database ever gets too big and floods you ram that is one thing but, a larger and newer drive should almost always increase performance overall. When you look at benchmarks for high capacity desktop drives you can see how aerial density and larger cache sizes effect performance. Also note that drives tend to lose performance if less than 20% of their space is free (in desktops anyways) as a result a larger drive would be faster and would get less fragmented as fragmentation tends to increase with decreased % of free space. Fragmentation is more often than not related to the % of space used on a drive and not exactly the amount of data on the drive. A 80gb drive with 60gb on it should fragment more than a 240gb drive with 100gb.
 
Apr 12, 2009 at 5:07 AM Post #147 of 195
but rockbox ISNT running in memory. its running off the drive. and I have run the 120 off a 30gb board and its slower than the 30. I dont know why you are trying to give me a lesson in computing. i've been using a mac since nearly 30 yrs ago and 15 of that as a graphics professional. I do know how the memory architecture works on a computer. but this is a modified computer when you are running rockbox, its would be like running your OS off the HD the whole time, because its always running off disk none of the RB firmware is stored in the memory when you install RB, kyou install a break in the code that says to look for the OS on the HD unless the key command to load the apple firmware is realized. I do realize the HD itself probably has a larger cache (provided it has an onboard cache (likely) the facts are that the 30gb board is only 32mb and the 80gb is 64mb and by giving it 240gb of data to address I think its a stretch. for a larger HD to be faster because it has more space available for scratch/page swap it helps to actually have the OS running in RAM; a luxury RB doesnt have
 
Apr 12, 2009 at 5:36 AM Post #148 of 195
What I am saying is that the raw speed of the HDD should be faster and thus should deliver higher performance if the same amount of data was stored on each drive. This is simply because the read and write speed of the larger drive should be faster. Try benchmarking the read write speeds of these HDDs and the difference will be apparent. I am just pointing out that when filled with the same data as a smaller drive the larger one should be faster.

Also I wanted to note the following:

Disk Spindown:
Rockbox has a timer that makes it spin down the hard disk after it is idle for a certain amount of time. This setting controls the amount of time between the last user activity and the time that the disk spins down. This idle time is only affected by user activity, like navigating through the File Browser. When the hard disk spins up to fill the audio buffer, it automatically spins down afterwards.

Directory Cache:
Rockbox has the ability to cache the contents of your drive in RAM. The Directory Cache takes a small amount of memory away from Rockbox that would otherwise be used to buffer music, but it speeds up navigation in the file browser by eliminating the slight pause between the time a navigation button is pressed and the time Rockbox responds. Turning this setting on activates the directory cache, and turning it off deactivates the directory cache.

The description of disk spindown clearly shows that rockbox does not run on the HDD it just runs off the HDD. If it was running on the HDD it could never spin down because doing so would stop a program from running. This means that an execution would be running though the system ram and that the HDD is only used for file requests (just like a regular computer). (Running off of something and running on or in something are two different things)

The directory cache would logically get bogged down as you add more directories depending on the structure of its code.

I would also like to point out how data moves in virtually all electronic computers. The real reason that you have ram or cache is to improve the efficiency of the cpu by preventing wasted clock cycles. The following is a list in order of latency from lowest to highest of where data is stored. The data that the cpu requires next is loaded into its L1 cache, if the cpu has one data that it might need is loaded into l2 cache. Data that needs to be constantly accessed or streamed for a process to the cpu is stored in ram. Data that is coming from or going to the HDD that has maxed out the bandwidth is stored in disk cache. If the drive is advanced enough heavily accessed files may be partially stored there.

Based off of this and the data given by Rockbox it appears that lag should only occur when the cache file created by rockbox becomes too large. This is thus a programing problem with Rockbox and not necessarily a hardware problem. The program should be designed to more effectively partition the available ram based on user demands. I do not know how the current cache system is programed but it is possible that it could be over caching and thus could be slimmed down when ram usage gets to high. For example, I do not know how deep directory wise it attempts to cache. Even if it only goes one layer down it could still be improved by having some sort of system for noting what directories are accessed most often and prioritize the caching of them when ram is limited.

So lets say you have 100 directories but there is only ram space for 80 to be cached thus the system caches the 80 most accessed ones in hopes that the users will use those. Therefore the system will only be slow 20% of the time amusing all 100 directories are accessed exactly the same amount verses the 90-100% of the time it could be slow as a result of flooding the ram.
 
Apr 12, 2009 at 10:55 AM Post #149 of 195
But surely the bottom line is that when spending a small fortune to upgrade your hdd threefold in terms of storage space, the likelyhood of storing the same amount of data as previously is negligible so ultimately, while all very well theoretically, is a moot point regarding real life application?
 
Apr 12, 2009 at 4:48 PM Post #150 of 195
In theory yes, but I wanted to point out that I believe the problem is caused by the ineffectiveness of rockbox cache programing inefficiently utilizing available memory. I am saying that the cache system should be more dynamic, also I believe that such a system would improve performance on all devices instead of just taking the performance hit like the current system works. To verify this theory I found the following config option:

Max Entries in File Browser:
This setting controls the limit on the number of files that you can put in any particular directory in the file browser. You can configure the size to be between 50 and 10,000 files in steps of 50. The default is 400. Higher values will shorten the music buffer, so you should increase this setting only if you have directories with a large number of files.

Clearly this is the extent of the current cache control architecture. It as I stated above will try to cache the number of directories that the user selects from this list. However instead of limiting the cache to this value it instead limited the physical number of directories. Therefore I believe that this option should be changed to control the number of directories cached instead of the number of directories allowed. Such a programing change would be easier to implement than my previously suggested dynamic memory system. It would also still offer the same minimum level of performance increase because by limiting the cached directories you will always have some that are not cached and take longer to lode, however these will be a fraction of the overall list.

The system could be improved further by offering the ability to paginate lists that are longer than X. This way if a user can only cache 1000 directories in one folder but the folder contains 2000 directories the user will be prompted with page 2 after the 1000th entry. This way the system always is able to cache what it is outputting and thus never laggs. Also by making X configurable as a separate option the user could have control over the percentage of cached files per page and thus the total % odds of experiencing lag. Thus, if the user wished to be able to view more files per page than cache allowed they could do so at the expense of performance.

All I am trying to point out is that any performance loss with a larger drive is the result of the shortcomings of the cache architecture of rockbox and not the drive itself. Therefore with time the performance of larger drives should improve as programmers adjust the code to be more efficient for a larger range of products and configurations.

Update
I did some more research and found that eventually extra ram (in ipods) achieves diminishing returns. The reason for this is that unlike a traditional computer that has a memory buss that supports read and write the ipod can apparently only read or write. In other words it can not access data at the same time that it enters data into the ram. Therefore there should always be a delay when every a large amount of data is concerned. I do wonder how this effects current playlists that exceed available ram. To better understand how the memory is being accessed I will play around with my 4g and track HDD access during flac playback.

Another though I had was that even though the buss is limited to half duplex(i think that is what it is called) you would still benefit from additional ram. Depending on how the buss actually reads and writes to the ram.

Regardless I question if it is possible to upgrade to 3rd party ram by removing the current chip and replacing with a new one. In order to do this it would require that the frimware is not stored on the same chip as the ram. Does anyone have the model number for the ram chips in ipods. I could try to look up the specs and find out more. I am hoping that it may be possible to unsolder the current ram and replace it with a larger capacity chip. Even for people that do not have large drives such a mod could dramatically improve battery life.
 

Users who are viewing this thread

Back
Top