What are the differences among absolute bandwidth, half-power bandwidth and null-null bandwidth in digital communication?
Related
As the image shows that, as the memory capacity increases the accessing time is also increasing.
Does it make sense that, accessing time is dependent on the memory capacity..???
No. The images show that technologies with lower cost in $ / GB are slower. Within a certain level (tier of the memory hierarchy), performance is not dependent on size. You can build systems with wider busses and so on to get more bandwidth out of a certain tier, but it's not inherently slower to have more.
Having more disks or larger disks doesn't make disk access slower, they're close to constant latency determined by the nature of the technology (rotating platter).
In fact, larger-capacity disks tend to have better bandwidth once they do seek to the right place, because more bits per second are flying under the read / write heads. And with multiple disks you can run RAID to utilize multiple disks in parallel.
Similarly for RAM, having multiple channels of RAM on a big many-core Xeon increases aggregate bandwidth. (But unfortunately hurts latency due to a more complicated interconnect vs. simpler quad-core "client" CPUs: Why is Skylake so much better than Broadwell-E for single-threaded memory throughput?) But that's a sort of secondary effect, and just using RAM with more bits per DIMM doesn't change latency or bandwidth, assuming you use the same number of DIMMs in the same system.
I'm a bit confused between about the difference between shared memory and distributed memory. Can you clarify?
Is shared memory for one processor and distributed for many (for network)?
Why do we need distributed memory, if we have shared memory?
Short answer
Shared memory and distributed memory are low-level programming abstractions that are used with certain types of parallel programming. Shared memory allows multiple processing elements to share the same location in memory (that is to see each others reads and writes) without any other special directives, while distributed memory requires explicit commands to transfer data from one processing element to another.
Detailed answer
There are two issues to consider regarding the terms shared memory and distributed memory. One is what do these mean as programming abstractions, and the other is what do they mean in terms of how the hardware is actually implemented.
In the past there were true shared memory cache-coherent multiprocessor systems. The systems communicated with each other and with shared main memory over a shared bus. This meant that any access from any processor to main memory would have equal latency. Today these types of systems are not manufactured. Instead there are various point-to-point links between processing elements and memory elements (this is the reason for non-uniform memory access, or NUMA). However, the idea of communicating directly through memory remains a useful programming abstraction. So in many systems this is handled by the hardware and the programmer does not need to insert any special directives. Some common programming techniques that use these abstractions are OpenMP and Pthreads.
Distributed memory has traditionally been associated with processors performing computation on local memory and then once it using explicit messages to transfer data with remote processors. This adds complexity for the programmer, but simplifies the hardware implementation because the system no longer has to maintain the illusion that all memory is actually shared. This type of programming has traditionally been used with supercomputers that have hundreds or thousands of processing elements. A commonly used technique is MPI.
However, supercomputers are not the only systems with distributed memory. Another example is GPGPU programming which is available for many desktop and laptop systems sold today. Both CUDA and OpenCL require the programmer to explicitly manage sharing between the CPU and the GPU (or other accelerator in the case of OpenCL). This is largely because when GPU programming started the GPU and CPU memory was separated by the PCI bus which has a very long latency compared to performing computation on the locally attached memory. So the programming models were developed assuming that the memory was separate (or distributed) and communication between the two processing elements (CPU and GPU) required explicit communication. Now that many systems have GPU and CPU elements on the same die there are proposals to allow GPGPU programming to have an interface that is more like shared memory.
In modern x86 terms, for example, all the CPUs in one physical computer share memory. e.g. 4-socket system with four 18-core CPUs. Each CPU has its own memory controllers, but they talk to each other so all the CPUs are part of one coherency domain. The system is NUMA shared memory, not distributed.
A room full of these machines form a distributed-memory cluster which communicates by sending messages over a network.
Practical considerations are one major reasons for distributed memory: it's impractical to have thousands or millions of CPU cores sharing the same memory with any kind of coherency semantics that make it worth calling it shared memory.
I notice looking at the documentation that the scope and AFG supports record lengths of up 16k points. Is there anyway this can be increased (I don't remember this number being quoted throughout the development period) and up to 125k points would be very useful for our applications.
16k samples is not a hard limit. Scope & AWG applications use 16k x 16-bit buffers per channel, resulting in 128kB, which accounts only for half of the total Zynq 7010 BRAM memory. There is also a possibility to use a partition of external 512MB DDR3 RAM memory for signal buffering purpose, shared with Linux OS, or simply to allocate the BRAM memory to a single channel+function combination in case your application does not use all 4 of them.
What's a common amount of memory for a Network Interface Card to have? In a scenario where a fast network connection is available and there is a slow (or busy) disk, will the NIC be smart enough to slow network transactions?
It's up to the protocol, not the NIC.
TCP will adapt. If you run a download over a gigabit lan on a 7200RPM hard drive (these typically have about a gigabit (120MB/s) of read speed and about 500Mbit (60MB/s) of write speed), the network connection will (by virtue of being unable to buffer TCP packets for long enough) drop a few packets, which will not be counted as received. They will not be ACK'd, and the sender will have to resend them. The TCP implementation on the sender's side will typically slow down to compensate for what it sees as a network bottleneck.
UDP offers no rate limiting and will send packets as fast as it can (if this is too fast, they just get dropped).
Different network cards have different amounts of memory.
High end ethernet cards will almost certainly have their own memory and microprocessors to offload work from the rest of the computer.
Low end ethernet cards may not have their own onboard memory or microprocessors, and will use the host system's resources to handle network traffic.
Infiniband cards on the other hand will tend to have their own onboard processors but no onboard memory, and will use direct memory access for all IO.
This NIC has a memory of 32MB with ECC protection. Here is another useful link for more information about NICs. That NIC seems pretty standard to me in terms of speed.
Is Couchbase a kind of storage that address GroupBy-based read and write of 4TB worth of data with low latency? If not, what size of data Couchbase is good for for low latency access ?
Couchbase can definitely handle 4TB of data. It will be fast to the degree you can keep your working set in RAM. So you can have disk greater than memory, but you want to have a really small # of cache-miss rates, which we let you monitor. If you see that % get too high, it is time to grow your cluster so that more ram becomes available.
4TB should be a few tens of nodes. At that scale, disk throughput starts to be the limiting factor (eg slow disks take too long to warm up lots of ram). So for really hot stuff, people use SSDs, but for the majority of apps EC2 is plenty fine.