This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I know this doesn't exactly fit the mold of this site, but this is a better place to ask than say Yahoo Answers. Can anyone help me with this?
Suppose you are instructed to populate a memory array of 64K words – where each word is 20 bits wide (let’s assume the extra 4 bits are for error correction) – out of 1K by 4 bit memory chips. How many such chips will you need?
Thanks!
I'll take a guess :-)
24bits/word, 65536 words = 1572864 bits.
1K x 4-bit memory means 4096 bits/chip, is that correct?
Then we have 1572864 bits / 4096 bits/chip = 384 chips.
5x 1Kx4 chips for 1K words, so 5*64 chips in total is 320
Related
I probably won't pursue this but I had this idea of generating a procedural universe in the most memory efficient way possible.
Like in the game Elite, you could use a random number generator based on a seed, and so each star system can be represented by a single seed number instead of lists of stats and other info. But if each star system is a 64 bit number, to make the milky way, 100 billion stars, that is 6.4 terabytes of memory. But if you use only 8-bits per star system, you'll only have 256 unique star systems in your game. So my other idea was to have each star system represented by 8 bits, but simply grab the next 7 star system's bytes in memory and use that combination to form a 64 bit number for the planet's seed. Obviously there would be 7 extra bytes at the end to account for the last star system in memory.
So is there any way to organize the values in these bytes such that every set of 8 bytes over the entire file covers all 64 bit values (hypothetically) with no repeats? Or is it impossible and I should just accept repeats? Or could I possibly use the address of the byte itself as part of the seed? So how would that work in C? Like if I have a file of 100 billion bytes, does that actually take up exactly 100 billion bytes in memory or is it more and how are the addresses for those bytes stored? And is accessing large files like that (like 100gb+) in a server client relationship practical? Thank you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
The goal is to determine metrics of an UDP protocol performance, specifically:
Minimal possible Theoretical RTT (round-trip time, ping)
Maximal possible Theoretical PPS of 1-byte-sized UDP Packets
Maximal possible Theoretical PPS of 64-byte-sized UDP Packets
Maximal and minimal possible theoretical jitter
This could and should be done without taking in account any slow software-caused issues(like 99% cpu usage by side process, inefficiently-written test program), or hardware (like busy channel, extremely long line, so on)
How should I go with estimating these best-possible parameters on a "real system"?
PS. I would offer a prototype, of what I call "a real system".
Consider 2 PCs, PC1 and PC2. They both are equipped with:
modern fast processors(read "some average typical socket-1151 i7 CPU"), so processing speed and single-coreness are not an issues.
some typical DDR4 #2400mhz..
average NICs (read typical Realteks/Intels/Atheroses, typically embedded in mobos), so there is no very special complicated circuitry.
a couple meters of ethernet 8 pair cable that connects their NICs, having established GBIT connection. So no internet, no traffic between them, other that generated by you.
no monitors
no any other I/O devices
single USB flash per PC, that booted their initramfs to the RAM, and used to mount and store program output after test program finishes
lightest possible software stack - There is probably busy box, running on top of latest Linux kernel, all libs are up-to-date. So virtually no software(read "busyware") runs on them.
And you run a server test program on PC1, and a client - on PC2. After program runs, USB stick is mounted and results are dumped to file, and system powers down then. So, I've described some ideal situation. I can't imagine more "sterile" conditions for such an experiment..
For the PPS calculations take the total size of the frames and divide it into the Throughput of the medium.
For IPv4:
Ethernet Preamble and start of frame and the interframe gap 7 + 1 + 12 = 20 bytes.(not counted in the 64 byte minimum frame size)
Ethernet II Header and FCS(CRC) 14 + 4 = 18 bytes.
IP Header 20 bytes.
UDP Header 8 bytes.
Total overhead 46 bytes(padded to min 64 if payload is less than ) + 20 bytes "more on the wire"
Payload(Data)
1 byte payload - becomes 18 based on 64 byte minimum + wire overhead. Totaling 84 bytes on the wire.
64 byte - 48 + 64 = 112 + 20 for the wire overhead = 132 bytes.
If the throughput of the medium is 125000000 bytes per second(1 Gb/s).
1-18 bytes of payload = 1.25e8 / 84 = max theoretical 1,488,095 PPS.
64 bytes payload = 1.25e8 / 132 = max theoretical 946,969 PPS.
These calculations assume a constant stream: The network send buffers are filled constantly. This is not an issue given your modern hardware description. If this were 40/100 Gig Ethernet CPU, bus speeds and memory would all be factors.
Ping RTT time:
To calculate the time it takes to transfer data through a medium divide the data transferred by the speed of the medium.
This is harder since the ping data payload could be any size 64 - MTU(~1500 bytes). ping typically uses the min frame size (64 bytes total frame size + 20 bytes wire overhead * 2 = 168 bytes) Network time(0.001344 ms) + Process response and reply time combined estimated between 0.35 and 0.9 ms. This value depends on too many internal CPU and OS factors, L1-3 caching, branch predictions, ring transitions (0 to 3 and 3 to 0) required, TCP/IP stack implemented, CRC calculations, interrupts processed, network card drivers, DMA, validation of data(skipped by most implementations)...
Max time should be < 1.25 ms based on anecdotal evidence.(My best eval was 0.6ms on older hardware(I would expect a consistent average of 0.7 ms or less on the hardware as described)).
Jitter:
The only inherent theoretical reason for network jitter is the asynchronous nature of transport which is resolved by the preamble. Max < (8 bytes)0.000512 ms. If sync is not established in this time the entire frame is lost. This is possibility that needs to be taken into account. Since UDP is best effort delivery.
As evidenced by the description of RTT: The possible variances in the CPU time in executing of identical code, as well as OS scheduling, and drivers makes this impossible to evaluate effectively.
If I had to estimate, I would design for a maximum of 1 ms jitter, with provisions for lost packets. It would be unwise to design a system intolerant of faults. Even for a "Perfect Scenario" as described faults will occur (a nearby lightening strike induces spurious voltages on the wire). UDP has no inherent method for tolerating lost packets.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm struggling with a coursework question. I'm stuck. My brain's hurting and I'm going around in circles.
The question is.
(a) Suppose a memory with 4-byte words and a capacity of 2^21-bit is
built using 2k x 8 RAM.
i. How many chips are needed?
My answer / idea here can't be correct.
Found a question that says how many chips to make 32k memory from 2k x 8 RAM? The answer is 16 chips. That makes sense 2 x 16 = 32
However, 2^21 bits?
4-byte words = 32 bits. This must be the number of bits per cell. The width of the memory?
If the entire memory holds 2^21 bits then does that mean that there will be 2^21 / 32 rows? = 65536 rows. I got to this through the thinking that I need 2^21 bits altogether. If there are 32 per row, I need 65536 rows to get to 2^21 (=2097152).
Even though I have got this far, I can't see how it helps me.
How many bits are stored on each 2k x 8 RAM?
ii. How many address lines are needed for the memory?
I have read that
"2k x 8 RAM is referred to as 2k x n memory. There are k address lines and therefore 2k addresses. Each of these addresses contains an n-bit word.
In this instance, 2k = 2048 = 211. You need 11 address lines."
I don't `100% understand the quote. I know that 2 address lines give four addresses. I know 3 address lines give 8 addresses. Do I need to work this out for 65536 rows?
iii. How many of these address lines are connected to the address inputs of the RAM chips?
????
iv. How many of these address lines will be used to select the appropriate RAM chip(s)?
I understand that some address lines are needed to select the chip whilst others are necessary for the cell in the chip. When I know the number of chips, can I work this out?
Many, many thanks for any help you can give me.
(a) Suppose a memory with 4-byte words and a capacity of 2^21-bit is built using 2k x 8 RAM.
"8 Ram" implies this RAM chip stores bytes, and thus this chip has the capacity to store 2kB, or 512 words == 2^9 words.
Now, to store 2²¹ bits == 2^18 bytes == 2^16 words == 2^7 chips worth of words == 128 chips.
That wasn't so hard, was it?
How many bits are stored on each 2k x 8 RAM?
2k * 8, exactly as your quoted book says.
ii. How many address lines are needed for the memory?
Well, you need 7 lines to select the chip, and 9 lines to select the word inside the chip. 7+9 = 16.
iii. How many of these address lines are connected to the address inputs of the RAM chips?
9, see ii.
iv.
7, see ii.
I have decided to reinvent the wheel for a millionth time and write my own memory pool. My only question is about page size boundaries.
Let's say GetSystemInfo() call tells me that the page size is 4096 bytes. Now, I want to preallocate a memory area of 1MB (could be smaller, or larger), and divide this area into 128 byte blocks. HeapAlloc()/VirtualAlloc() will have an overhead between 8 and 16 bytes I guess. Might be some more, I've read posts talking about 60 bytes.
Question is, do I need to pay attention to not to have one of my 128 byte blocks across page boundaries?
Do I simply allocate 1MB in one chunk and divide it into my block size?
Or should I allocate many blocks of, say, 4000 bytes (to take into account HeapAlloc() overhead), and sub-divide this 4000 bytes into 128 byte blocks (4000 / 128 = 31 blocks, 128 bytes each) and not use the remaining bytes at all (4000 - 31x128 = 32 bytes in this example)?
Having a block cross a page boundary isn't a huge deal. It just means that if you try to access that block and it's completely swapped out, you'll get two page faults instead of one. The more important thing to worry about is the alignment of the block.
If you're using your small block to hold a structure that contains native types longer than 1 byte, you'll want to align it, otherwise you face potentially abysmal performance that will outweigh any performance gains you may have made by pooling.
The Windows pooling function ExAllocatePool describes its behaviour as follows:
If NumberOfBytes is PAGE_SIZE or greater, a page-aligned buffer is
allocated. Memory allocations of PAGE_SIZE or less do not cross page
boundaries. Memory allocations of less than PAGE_SIZE are not
necessarily page-aligned but are aligned to 8-byte boundaries in
32-bit systems and to 16-byte boundaries in 64-bit systems.
That's probably a reasonable model to follow.
I'm generally of the idea that larger is better when it comes to a pool. Within reason, of course, and depending on how you are going to use it. I don't see anything wrong with allocating 1 MB at a time (I've made pools that grow in 100 MB chunks). You want it to be worthwhile to have the pool in the first place. That is, have enough data in the same contiguous region of memory that you can take full advantage of cache locality.
I've found out that if I used _align_malloc(), I wouldn't need to worry wether spreading my sub-block to two pages would make any difference or not. An answer by Freddie to another thread (How to Allocate memory from a new virtual page in C?) also helped. Thanks Harry Johnston, I just wanted to use it as a memory pool object.
From a 16MB DRAM, I have to calculate the maximum time it can take to read 8300 consecutive values. Here are the specifications that I have:
-the DRAM is structured as a table of 4096 x 4096 cell.
-it has a time cycle (Tc) of 65 ns.
-in page mode it has a time cycle (Tpm) of only 45 ns.
I thought it was simply done by calculating the number of cells in the DRAM and then calculating the percentage that 8300 represents from the total (4096 x 4096) and then taking that same percentage and multiplying it to the time access. Unfortunately it did not give me the right answer... Any help would be greatly appreciated! Thanks guys
There are many variables into account (e.g., Using open- or close-page mode, number of ranks), thus is memory dependent. In order for you to have a better understanding and re-state your question, please read this paper, which helped me to understand RAM better.
Power and Performance Trade-Offs in Contemporary DRAM System Designs for Multicore Processors
You can search for it in Google Scholar.
Thanks.