I know that 8086 has a 20-bit address bus and 16-bit registers, so it need 2 registers to locate the obsolutely memory address. Why don't 8086 use 20-bit registers?
Several reasons.
it maintains some backward compatibility with the 8080. If you set all the segment registers to 0, I think it will run 8080 code.
the data bus is only 16 bits wide. The segmented architecture allows you to pull in a whole address in one memory read cycle. 20 bit addresses would require two.
Those are the two I can think of off the top of my head.
Related
In this Diagram found in Wikipedia, both ROM and Program Address Register are connected to a 8-bit bus, but I thought in 8051, Internal Rom uses 16-bit adrress.
So why is the Program Address Register connected to a 8-bit bus?
Since we are not the ones who designed this architecture, we can only guess or think of reasons. If you actually want to know why, you need to find the ones who made the decision.
The 8051 multiplexes the lower address byte and the data on P0, and the upper byte of the address can go through P2. Because both bytes can be transferred at different times, an 8-bit bus suffices.
This design decision could be made to reduce silicon needs, in terms of transistors and wires. Silicon area was expensive that time.
There might be a history in the issue, too. The 8051 series followed the MCS48 (8021, 8022, 8048, etc) that had fewer address bits.
Think about the time this controller was designed, and the target market. External RAM or memory-mapped peripherals might only need 8 bits of address, just because it was enough, or too costly to use more.
Another reason might be over-simplification in the diagrams, that additionally may base one on the other. The program address register might use two 8-bit busses, each connected to one port driver block. And some "wise" guy simply put them together.
The Adress bus is not only connected there, the first 8 bits are common for address and data bus in port 0 of the microcontroller (That's why you see AD0 for the pins in pin diagram for port0, A - Address, D - Data. But in port 2 you find A0, only address), basically, an optimization to reduce the number of hardware connections, the remaining 8 bits i.e most significant bits of the address bus is in port 2 of the microcontroller so totally 8 + 8 = 16 bits.
I have a solarflare nic with paired rx and tx queues (8 sets, 8 core machine real machine, not hyperthreading, running ubuntu) and each set shares an IRQ number. I have used smp_affinity to set which irqs are processed by which core. Does this ensure that the transmit (tx) interrupts are also handled by the same core. How will this work with xps?
For instance, lets say the irq# is 115, set to core 2 (via smp_affinity). Say the nic chooses tx-2 for outgoing tcp packets, which also happens to have 115 irq number. If I have an xps setting saying tx-2 should be accessible by cpu 4, then which one takes precedence - xps or smp_affinity?
Also is there a way to see/set which tx queue is being used for a particular app/tcp connection? I have an app that receives udp data, processes it and sends tcp packets, in a very latency sensitive environment. I wish to handle the tx interrupts on the outgoing on the same cpu (or one on the same numa node) as the app creating this traffic, however, I have no idea how to find which tx queue is being used by this app for this purpose. While the receive side has indirection tables to set up rules, I do not know if there is a way to set the tx-queue selection and therefore pin it to a set of dedicated cpus.
You can tell the application the preferred CPU by setting the cpu affinity (taskset) or numa node affinity, and you can also set the IRQ affinities (in /proc/irq/270/node, or by using the old intel script floating around 'set_irq_affinity.sh' which is on github). This won't completely guarantee which irq / cpu is being used, but it will give you a good head start on it. If all that fails, to improve latency you might want to enable packet steering in the rxqueue so you get the packets in quicker to the correct cpu (/sys/class/net//queues/rx-#/rps_cpus and tx-#/xps-cpus). There is also the irqbalance program and more....it is a broad subject and i am just learning much of it myself.
Pardon my limited knowledge in networks.
I am trying to setup two small programs as client and server, which join to a particular multicast group. The servers sends some arbitrary data to the group and the client receives the data as it listens to the group.
This of course is possible with UDP programs which I have already done. However I need to work with MAC addresses instead of IPs. And I have a few questions regarding this:
Is it possible to fix a range of MAC addresses for my multicast application ? As I understand, the least significant bit of the first octet in the MAC address signifies if it is multicast or not. So the multicast MAC should look like 01:*:*:*:*:* . So I guess, there should be some way to use a wide range of MAC addresses (except for those reserved).
Many places it is written as All multicast MAC addresses begin with: 0100.5e . Is it always true? AFAIK this prefix is fixed in the MAC address which leaves space for the rest of the IP address bits to be mapped here. But what if my application doesn't care about IP addresses and listens to multicast groups based on MAC addresses (if it is possible) ?.
Can't I keep the first octet as 01 and use a wide range for my multicast addressing ?
How to send packets to a multicast group and listen to a multicast group only based on MAC addresses and irrespective of IP ? i.e. the multicast group addresses are defined based on MACs.
I hope my questions made sense.
If you are not using IP (or UDP on top of that) then the default way of mapping IP addresses to mac addresses have probably no added value for you. These mappings are specified for example in:
http://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
rfc1112 https://www.rfc-editor.org/rfc/rfc1112 paragraph 6.4
If you insist on using layer2 and multicasting it will probably be sufficient to send out frames with the LSB of the first octet set (the multicast bit, ref: http://en.wikipedia.org/wiki/File:MAC-48_Address.svg ). And put your own mapping on top of that. But you should take into account that:
you probably need to force your NIC to pass the data, often NIC's filter out frames they are interested in hardware. And these filters are typically set when joining a group or e.g. when setting the ALLMULTI flag).
There is probably networking equipment in the middle and some pseudo-intelligent switches may refuse to forward data unless they have seen IGMP joins (ref igmp snooping).
And you code will obviously need to deal with raw layer 2 sockets to read out the data.
Considering the ease of just using UDP this may be a lot of work.
What is the behavior of an ethernet device in the packet ingress path?
If the sender is sending a larger-than-MTU frame, then:
1) does the receiver's device drop it directly in hardware,
2) or accept it and send it up for the kernel's IP stack to handle it?
3) when is ICMP frag-required sent?
4) does it make a difference if the ethernet device is say on a intermediate router vs a end host?
It is impossible to answer 1), 2) definitively for all devices and networking stacks. The Ethernet standard defines an MTU of 1500 bytes so that is all you can rely on and in general you should expect frames with larger MTUs to be dropped.
However in reality it is likely in an end host that if the network interface hardware doesn't drop the oversized frame (which is typically referred to as giant) then it will make it's way up the software stack and be processed. Even though the stack may not drop the oversized frame due to it being over the MTU it may still get dropped for other reasons, e.g. due to an internal queue exhaustion.
Although the maximum MTU of an Ethernet frame has remained constant the maximum size of an Ethernet frame has grown over time to encompass features like 802.1Q VLAN single and double tags. MPLS further increases the frame size to include label stacks. This means intermediate switches are usually tolerant of frames that exceed the interface MTU by some amount. One major vendor effectively tolerates a max MTU of 2000 bytes by default in their current switches. Older switches may be less tolerant.
To get a definitive answer you'll need to do some research into the specific hardware and software that you care about.
What is the maximum packet size for a TCP connection or how can I get the maximum packet size?
The absolute limitation on TCP packet size is 64K (65535 bytes), but in practicality this is far larger than the size of any packet you will see, because the lower layers (e.g. ethernet) have lower packet sizes.
The MTU (Maximum Transmission Unit) for Ethernet, for instance, is 1500 bytes. Some types of networks (like Token Ring) have larger MTUs, and some types have smaller MTUs, but the values are fixed for each physical technology.
This is an excellent question and I run in to this a lot at work actually. There are a lot of "technically correct" answers such as 65k and 1500. I've done a lot of work writing network interfaces and using 65k is silly, and 1500 can also get you in to big trouble. My work goes on a lot of different hardware / platforms / routers, and to be honest the place I start is 1400 bytes. If you NEED more than 1400 you can start to inch your way up, you can probably go to 1450 and sometimes to 1480'ish? If you need more than that then of course you need to split in to 2 packets, of which there are several obvious ways of doing..
The problem is that you're talking about creating a data packet and writing it out via TCP, but of course there's header data tacked on and so forth, so you have "baggage" that puts you to 1500 or beyond.. and also a lot of hardware has lower limits.
If you "push it" you can get some really weird things going on. Truncated data, obviously, or dropped data I've seen rarely. Corrupted data also rarely but certainly does happen.
At the application level, the application uses TCP as a stream oriented protocol. TCP in turn has segments and abstracts away the details of working with unreliable IP packets.
TCP deals with segments instead of packets. Each TCP segment has a sequence number which is contained inside a TCP header.
The actual data sent in a TCP segment is variable.
There is a value for getsockopt that is supported on some OS that you can use called TCP_MAXSEG which retrieves the maximum TCP segment size (MSS). It is not supported on all OS though.
I'm not sure exactly what you're trying to do but if you want to reduce the buffer size that's used you could also look into: SO_SNDBUF and SO_RCVBUF.
There're no packets in TCP API.
There're packets in underlying protocols often, like when TCP is done over IP, which you have no interest in, because they have nothing to do with the user except for very delicate performance optimizations which you are probably not interested in (according to the question's formulation).
If you ask what is a maximum number of bytes you can send() in one API call, then this is implementation and settings dependent. You would usually call send() for chunks of up to several kilobytes, and be always ready for the system to refuse to accept it totally or partially, in which case you will have to manually manage splitting into smaller chunks to feed your data into the TCP send() API.
According to http://en.wikipedia.org/wiki/Maximum_segment_size, the default largest size for a IPV4 packet on a network is 536 octets (bytes of size 8 bits). See RFC 879
Generally, this will be dependent on the interface the connection is using. You can probably use an ioctl() to get the MTU, and if it is ethernet, you can usually get the maximum packet size by subtracting the size of the hardware header from that, which is 14 for ethernet with no VLAN.
This is only the case if the MTU is at least that large across the network. TCP may use path MTU discovery to reduce your effective MTU.
The question is, why do you care?
If you are with Linux machines, "ifconfig eth0 mtu 9000 up" is the command to set the MTU for an interface. However, I have to say, big MTU has some downsides if the network transmission is not so stable, and it may use more kernel space memories.
One solution can be to set socket option TCP_MAXSEG (http://linux.die.net/man/7/tcp) to a value that is "safe" with underlying network (e.g. set to 1400 to be safe on ethernet) and then use a large buffer in send system call.
This way there can be less system calls which are expensive.
Kernel will split the data to match MSS.
This way you can avoid truncated data and your application doesn't have to worry about small buffers.
It seems most web sites out on the internet use 1460 bytes for the value of MTU. Sometimes it's 1452 and if you are on a VPN it will drop even more for the IPSec headers.
The default window size varies quite a bit up to a max of 65535 bytes. I use http://tcpcheck.com to look at my own source IP values and to check what other Internet vendors are using.
The packet size for a TCP setting in IP protocol(Ip4). For this field(TL), 16 bits are allocated, accordingly the max size of packet is 65535 bytes: IP protocol details