Calculating Hard Disk Capacity [closed] - disk

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Consider a disk with the following characteristics:
Number of surface 16
Number of sectors / cylinder 4096
Number of tracks per surface 2048
Number of bytes per sector 512
1) How many patters does the disk have ?
I got: number of surfaces / 2
= 8
2)How many sectors per tack ?
I got: Number tracks per cylinder = tracks per surface * surfaces
= 2048 * 16
= 32, 768
Number of sectors per track = number of tracks per cylinder / number of sectors per cylinder
= 32, 768 / 4096
= 8
3) What is the total size of this disk
I got : Total size = cylinders * surfaces * sectors per track * 512 bytes
= 32,768 * 16 * 8 * 512
= 2, 147, 483, 648 bytes
= 2, 097, 152 Mb
= 2, 048 Gb
The thing is, I dont know if this is right solution

Question2:
Number of surface 16 -> a cylinder consists of 16 tracks.
Number of sectors / cylinder == 4096
Then sectors per track = 4096/16 = 256
Question3:
16 * 2048 * 256 * 512 = 4294967296

You need to multiplier the number of cylinders, heads and sectors, so you'll get the number of blocks, multiplier it for 512 and you got the answer, I think that is it...

Related

Tag Size and Cache Bits Exercise

I am studying for my computer architecture exam that is due tomorrow and am stuck on a practice exercise regarding tag size and the total number of cache bits. Here is the question:
Question 8:
This question deals with main and cache memory only.
Address size: 32 bits
Block size: 128 items
Item size: 8 bits
Cache Layout: 6 way set associative
Cache Size: 192 KB (data only)
Write Policy: Write Back
Answer: The tag size is 17 bits. The total number of cache bits is 1602048.
I know that this a failry straight-forward exercise, but I seem to be lacking the proper formulas. I also know that the structure of a N set way associative is |TAG 25 bits|SET 2 bits|OFFSET 5 bits|. And that Tag size = AddrSize - Set - Offset (- item size if any) thus giving the answer of 17 bits tag size.
However, how do I calculate the total number of cache bits please?
cache size in bytes: 192*1024 = 196608
number of blocks: 196608 / 128 = 1536
number of sets: 1536 / 6 = 256
set number bits: log2(256) = 8
offset number bits: log2(128) = 7
tag size: 32-(8+7) = 17
metadata: valid+dirty = 2 bits
total tag + metadata: (17+2)*1536 = 29184 bits
total data: 1536*128*8 = 1572864 bits
total size: 29184 + 1572864 = 1,602,048
There could also be bits used for the replacement policy, but we can assume it's random to make the answer work.

Calculating the total data+overhead of a set associative cache

This is a question from a Computer Architecture exam and I don't understand how to get to the correct answer.
Here is the question:
This question deals with main and cache memory only.
Address size: 32 bits
Block size: 128 items
Item size: 8 bits
Cache Layout: 6 way set associative
Cache Size: 192 KB (data only)
Write policy: Write Back
What is the total number of cache bits?
In order to get the number of tag bits, I find that 7 bits of the address are used for byte offset (0-127) and 8 bits are used for the block number (0-250) (250 = 192000/128/6), therefore 17 bits of the address are left for the tag.
To find the total number of bits in the cache, I would take (valid bit + tag size + bits per block) * number of blocks per set * number of sets = (1 + 17 + 1024) * 250 * 6 = 1,536,000. This is not the correct answer though.
The correct answer is 1,602,048 total bits in the cache and part of the answer is that there are 17 tag bits. After trying to reverse engineer the answer, I found that 1,602,048 = 1043 * 256 * 6 but I don't know if that is relevant to the solution because I don't know why those numbers would be used.
I'd like if someone could explain what I did wrong in my calculation to get a different answer.

Why are kilo, mega and giga - bytes named after "bytes", if they all have 10 of more bits when bytes have 8 bits?

I get why we have the number 1024 instead of 1000 to use the suffix "kilo" in computing (computer uses base 2, so 2 ^ 10, blah blah blah). So I get the kilo part, but why is it called a kilo - "byte"? To make a kilo - "byte", we need to use bits with 10 digits from 0000000000 to 1111111111. That is not 8 digits, shouldn't it be called something else.
I.e. a kilobyte is not 1024 groupings of 8 bit binary digits, it is 1024 groups of 10 bit binary digits and a megabyte has even more than 10 binary digits - not 8. If asked how many bits are in 1 kilobytes, people calculate it as 1*1024*8. But that's wrong! It should be 1*1024*10.
I.e. a kilobyte is not 1024 groupings of 8 bit binary digits, it is
1024 groups of 10 bit binary digits
You are confusing the size of a byte with the size of the value needed to address those bytes.
On most systems a byte is 8 bits, which means 1000 bytes is exactly 1000*8 bits, and 2000 bytes is exactly 2000*8 bits (i.e. exactly the double, which makes sense).
To address or index those bytes you need 10 bits in the first example (2^10) and 11 bits in the second (2^11 up to 2048 bytes). It wouldn't make a lot of sense if the size of a byte was changing when there are more bytes in a data structure.
As for the 1000 (kilobyte) vs 1024 (kibibyte):
1 kB (kilobyte) = 10^3 = 1000
1 KiB (kibibyte) = 2^10 = 1024
A kilobyte used to be generally accepted as being 1024 bytes. However at some point hard disk manufacturers started to count 1 kB as 1000 bytes (kilo being 1000 which is actually correct):
1 GB = 1000^3 = 1000000000
1 GiB = 1024^3 = 1073741824
Windows still used 1 kB = 1024 bytes to show the hard disk size, i.e. it showed 954MB for 1GB of hard disk space. I remember a lot of customers complaining about that when checking, for example, the size of their 250GB drive which only showed 233GB in Windows.

calculating maximum volume size of fat 32 and HDFS

I am trying to calculate the max volume and file size for fat 32 and hdfs. for fat32 i have 4096 bytes sector size and 2^32 possible sectors . so 2^32 * 4096 = 1.759218604×10¹³ bytes or 17.6TB for the Volume size. But this should be 16TB according to the texts.
The same for HDFS: i have a block size (sector size) of 64mb and 63 bits to index the sectors and I do the same calculation : 2^63 * 64 = 590.29 YB . But this should equal 512 YB according to the texts . YB = Yota bytes = 10^12TB
I'm not sure where you got your "according to the texts" from. Max volume size for a FAT32 file system is 32 GB for Windows 2000 and 127.53 GB for Windows 98 (Reference)
You also need to be careful with your byte calculations. Make sure you know if the texts you are referring to are using 2^n or 10^n for their reporting. 1 Terabyte (TB) = 10^12 bytes and 1 Tibibyte (TiB) = 2^40 bytes. So, 2^32 * 2^12 (4096) = 2^44 = 16 * 2^40 = 16 TiB.
Similarly, 2^63 * 2^6 (64) = 2^69 = 2^9 * 2^60 = 512 EiB
Your calculation of 590.29 YB is not correct... it works out to EB not YB. 1 EB = 10^18 bytes and 1 YB = 10^24 bytes
It's also worth noting that a lot times TB is used as short hand for TiB.

Direct Table & Lookup Table

How to measure memory size of an image in direct coding 24-bit RGB color model & in 24-bit 256-entry loop-up table representation. For example: Given an image of resolution 800*600. how much spaces are required to save the image using direct coding and look-up table.
For a regular 24-bit RGB representation most probably you just have to multiply the number of pixel on number of bytes per pixel. 24 bits = 3 bytes, so the size is 800 * 600 * 3 bytes = 1440000 bytes ≈ 1.37 MiB. In some cases you may have rows of an image aligned on some boundary in memory, usually 4 or 8 or 32 bytes. But since 800 is divisible by 32, this will not change anything, still 1.37 MiB.
Now, for a look-up table, you have 1 byte per pixel, since you have only to address one entry in the table. This yields 800 * 600 * 1 = 480000 bytes ≈ 0.46 MiB. Plus the table itself: 256 colors, 24 bits (3 bytes) each - 256 * 3 = 768 bytes. Negligible comparing to the size of the image.

Resources