I don't undertand how this question is worked out.
Consider a case with fixed partitioning without internal/external fragmentation. There are five memory partitions: 500Kb, 200Kb, 300Kb, 100Kb and 700Kb. We have 4 processes with arrival sequence {P2, P1, P4, P3} that require contiguous memory allocation with size as follows: P1:478, P2:245, P3:128, P4:314. Answer the following.
Fill in the table below with the allocated memory locations for each process, considering the fact that the memory addresses start from 0x0000:
I can't post the table. Here is an example:
PID BF FF NF WF
1 0x0000 0x0B00 0x0B00 0x0000
2 0x0700 0x0000 0x0000 0x0B00
3 0x0500 0x0500 0x0500 0x0700
4 0x0B00 FF FF FF
Related
I am streaming some data of fixed length. The data consists of some 64-bit ints as well as some 32-bit floats. Because the format of the data is fixed and known, I am just sending an array of bytes with a known endian-ness. The data can then be easily reconstructed at the other end.
However, my transport protocol will not allow any 0x00 bytes. Is there a way I can encode my data differently to avoid this? Losing some range in the data is fine (e.g. ints having a maximum of 2^60 is totally fine). Incresing the full size of the message is totally fine too, as long as the full length of data is fixed no matter what the values of the ints and floats are (e.g. if ints now take 9 bytes to store).
I don't know much about encoding formats, but I learned about CRCs a long time ago and I'm wondering if there's something like that, which will add some fixed length block to the end of the bytestream, but which will prevent the bytestream from containing any 0x00 bytes?
Let's take the case of 64-bit numbers:
Reduce your value range to 256 and use the last (or first) 7 bytes to encode that value.
For the 7 value bytes, replace all the 0x00 bytes with 0xff bytes. Record the positions of the bytes that have been flipped.
Use the remaining byte as a bit mask to encode the positions of the bytes that have been flipped. This will take up 7 bits of that remaining byte. The first (or last) bit of that byte needs to be always set to 1 to prevent the encoding byte to become 0x00 itself.
For example:
Take the 7 byte value b2 00 c3 d4 e5 ff 00.
Flip the 0x00 bytes to get b2 ff c3 d4 e5 ff ff. Bytes 2 and 7 have been flipped.
Create the bit mask 0100001 and prefix with a 1 bit to get a binary value of 10100001, or a hex value of 0xa1.
Your encoded 64-bit value will then be a1 b2 ff c3 d4 e5 ff ff.
The approach for 32-bit numbers is the same. Use 28 bits for the value, 3 bits to encode which bytes have been flipped, and the leftover bit always set to 1.
How can I find DRAM row buffer size programmatically or by using already existing tools in say a *nix system ?
As an example, with a Kingston DDR4, I executed the following commands (you might need to install some packages) :
sudo modprobe eeprom
decode-dimms
These commands, among many information, give me the characteristics of my DDR stick:
---=== Memory Characteristics ===---
Maximum module speed 2132 MHz (PC4-17000)
Size 16384 MB
Banks x Rows x Columns x Bits 16 x 16 x 10 x 64
SDRAM Device Width 8 bits
Ranks 2
Rank Mix Symmetrical
AA-RCD-RP-RAS (cycles) 14-14-14-35
Supported CAS Latencies 16T, 15T, 14T, 13T, 12T, 11T, 9T
Rows and columns are actually number of address bits (you can check the decode-dimms source at https://fossies.org/linux/i2c-tools/eeprom/decode-dimms, and understand what the code is doing when you look at the DDR4 SPD information: https://en.wikipedia.org/wiki/Serial_presence_detect#DDR4_SDRAM)
Thus, if we have 10 column bits, we have 1024 columns (2^10), where each column is composed of the module width (64 as per the data above, represented as "bits"). Since we can also see that the SDRAM device width is 8x, we can deduce that the DIMM locksteps 8 SDRAM chips (those black boxes you see in your DRAM stick) to get that total width of 64 bits.
The row buffer size in my DDR4 is, therefore, 64 bits * 1024 columns = 65536 bits wide (8192 Bytes). Row buffer sizes in DDR3 and DDR4 are mostly this length, but new architectures such as HMC and HBM have different sizes.
So, in one short commandline, to return in bits (just divide by 8 to get bytes):
decode-dimms | grep "Columns x Bits" | awk -F 'x' '{print (2^$(NF-1))*$NF}
PS: mind you, this handles a single DIMM. if you have multiple DIMMS decode-dimms might return information for multiple modules.
A computer has 1MB RAM and has a word size of 8 bits. Its has cache memory having 16 blocks with a block size of 32 bits. Show how the main memory address
1000 1111 1010 0101 1101 will be mapped to cache address, if
i) Direct cache mapping is used
ii) Associative cache mapping is used
iii)Two way Set associative cache mapping is used
Please enlighten me on how to solve this problem.I have looked all over and there is no detailed explanation on this.
32 bit is 4 bytes, you need 2 bits to address these 4 bytes (2^2) so you split off the 2 least significant bits from the address.
1000 1111 1010 0101 11-01
Direct mapped means it can go only into one place in the cache, there are 16 places in the cache so we must peel off the next least 4 bits (2^4=16) getting
1000 1111 1010 01-01 11-01
so 0111 (=7) is the line that gets filled.
If (Fully) Associative cache mapping is used it can go in any of the 16 positions.
Using two way Set associative cache mapping is alike direct mapped but where we split the cache in half (size=8=2^3), giving 2 possible position it can be stored in.
1000 1111 1010 010-1 11-01
so 111 is the index and any of the 2 possible positions can be used.
Read all about caches here.
Can someone help me understand this question:
A processor providing 64GB of addressable main memory such as the AMD FX8350
Which of the following is the correct maximun range of main memory locations for such a processor?
A.0x000 to 0x3FF
B.0x0 0000 TO 0x3F FFFF
C.0x000 0000 TO 0x3FF FFFF
D.0x0 0000 0000 TO 0x3F FFFF FFFF
E.0x0 000 000 000 TO 0x3F FFFF FFFF FFFF
I am afraid there is no simple answer to this question. The microprocessor will have different addressing modes and will map real memory into the virtual address space in pages, usually of 4k in size. So the virtual address space may not even be contiguous.
First of all there is no such thing as "Processor providing xx memory". A processor can specify how many bits of addresses it is able to operate on. Most common cases are 32 and 64 bit. Processors with 32 bit addressing, are able to access 2^32 locations = 4GB. Processors with 64 bit addressing, theoretically, is able to address 2^64 locations. However most of them, only support 48 bits of addressing providing 256 TB of addressable space.
Now in order to make use this capabilities, you need the support of the operating system as well, i. if you have a 64 bit processor and a 32 bit OS, you can only access 32 bit addresses.
I am doing motion detection on a fairly small video. 56 frames of 288x384xRGB. I keep two copies of it, so it should amount to about 40 Mb tops, including my other variables.
Now, this line gives me an out of memory error
output = uint8(zeros(this.videoHeight,2.*this.videoWidth,3,size(this.originalFrames,4)));
typing memory reports
>> memory
Maximum possible array: 202 MB (2.114e+08 bytes) *
Memory available for all arrays: 863 MB (9.045e+08 bytes) **
Memory used by MATLAB: 527 MB (5.526e+08 bytes)
Physical Memory (RAM): 3071 MB (3.220e+09 bytes)
* Limited by contiguous virtual address space available.
** Limited by virtual address space available.
>>
I'm new to MATLAB, but not totally new to programming. What am i not understanding?
EDIT
So i did som disp'ing:
disp(this.videoHeight)
disp(2.*this.videoWidth)
disp(size(this.originalFrames,4))
produces:
288
768
54
So, it is actually smaller than i suggested...
You should use
zeros(..., 'uint8')
rather than
uint8(zeros(...))
to avoid creating the array in double-precision first, and then copying it to a uint8 array.
I haven't looked in detail but I would be surprised if there weren't quite a bit of overhead imposed by Matlab. You're probably using a lot more memory than you might suspect.
Try dialing down the number of frames you process to see if that fixes the problem.