Actual throughput is lower than physical layer transmission rate
Decrease.
What is the relevance of the 11a MAC to this speed reduction?
Are you comparing the Transmission rate of 802.11 and Application throughput (For example, Iperf result)?
If yes,
First of all, the transmission rate is counting with the MAC layer of the packet including 802.11 headers. The length counting for a single data packet size is already different.
More important, 802.11 is a CSMA/CA protocol that depends on the airtime for transmitting the packets. Exact management packet (block ACK, RTS/CTS, ... )or time waiting (for example, SIFS / Contention Window, ...) are needed for this mechanism. This used up the airtime so that the actual throughput will be slightly lower than the transmission rate.
Related
Anyone know why 802.11 Acknowledgement Frames have no source MAC address? I don't see it when I capture the packets from TCPDUMP or Wireshark from Linux with a monitor-mode and promiscuous-mode driver. How does the Access Point distinguish ACK frames from different 802.11 clients if there is no source MAC addresses in the frame?
I can see from all the captures that the ACK comes immediately after the frame is sent (around 10 to 30 microseconds) but that alone can't be enough to distinguish the source can it? Maybe each frame has some kind of unique identifier and the ACK frame has this ID inside it? Maybe there is identifying information in the encrypted payload since the WLAN uses WPA-PSK mode?
No, there is nothing encripted in 802.11 MAC ACK frames.
802.11 is a contention based protocol. ie the medium is shared by different STA's and AP's who all are working in the same channel [frequency] in terms of time. Those who wants to transmit are competing for medium , winner who gets medium starts transmitting.
As per 802.11 spec. , once a frame is on air, the next "SIFS" period medium should be free. ie no one is allowed to transmit.
At the end of SIFS, the reciever of unicast frame should transmit ACK. This is the rule.
SIFS [Short Interframe space] in 802.11 is ~10 microseconds for OFDM based 802.11 implementations [802.11 G,A]. For 802.11b its ~20 microseconds if my memory is correct. Thats why you are seeing 10 or 30 microseconds in between TX and ACK
So, everyone knows who is transmitting the ACK and whom the ACK is to. So no need to include source address, its implecit.
Why Source address not included?
To reduce the frame size and so to same power.
Hope it helps. If you got more questions on this, please feel free
ACK frames, like all 802.11 management frames, have a DA (Destination Address) and SA (Source Address) in their MAC header (both not to be exactly confused with just "MAC address, see below), and that's all what's needed in this context.
TLD;DR: In 802.11 context, "MAC address", SA (Source addr), TA (Transmitter addr), DA (Destination addr), BSSID or whatnot all look alike a 6 byte "MAC address" that we're familiar with from other technologies, yet they should not be confused.
And now for the demolition of "MAC address" concept in 802.11 context.
802.11 Acknowledgement Frames are parts of 802.11 managements frames, and 802.11 is "a set of media access control (MAC) and physical layer (PHY) specifications" (source).
What this mean - and this is a very important concept to grasp when working with Wi-Fi - is that 802.11 in itself, including its management frames, have nothing to do with "traditional" (say 802.3, aka Ethernet) PHY (layer 1) nor MAC (layer 2) layers - they are a kind of their own.
802.3/Ethernet, to continue with this analogy - or rather counter example - have no such thing as ACK frames, beacons, probe request, RTS/CTS, auth/deauth, association etc, which are all types of 802.11 management frames. These are simply not needed with 802.3, for the most part because wired Ethernet is not a shared media (that's IEEE terminology), that may lead to unreliability/collision as is air with 802.11/Wi-Fi.
The important consequence of this is that you should not expect a priori to meet other, more familiar concept nor data from other layer 1/2 technologies. Forget this, once for all.
Sure, Wi-Fi looks like it carry on some MAC and IP and TCP and or UDP or whatnot, and they do most of the time, but regarding management frames such as ACK, that's a different world - its own world. As it is, 802.11 could perfectly be used - and maybe is used in some niche use cases - to carry other higher level protocols than TCP/IP. And its MAC concept, though looking familiar with its 6 bytes, should not be confused in its form nor use to the MAC of 802.3/Ethernet. To take another example, 802.15 aka Bluetooth also have a 6 bytes MAC, yet that is again another thing.
And to take the 802.11 a contrario example, 802.11 layer 1/2 beacon frames for instance carry some info about SSID, supported rates, Frequency-hopping (FH), parameter set etc etc that have no counterparts in other L1/2 technologies.
Now, embrace the complexity of what is/are "MAC addresses" in 802.11...
And this is why, to take an example in day to day use, pcap/tcpdump have such weird filters such as wlan ra, wlan ta, wlan addr1, wlan addr2, wlan addr3, wlan addr4 - and the like for wireshark capture and display filter.
Right George..!!
In MAC format NAV timer is updated like that, while data frames NAV is updated while transmitting , It updates for
DATA frame + SIFS + ACK + SIFS
So there is clear for this time, only one AP <---> station is talking, all are waiting to be clear NAV time period, so doesn't need to add Source address as it is wasting frame bytes.
I came across same question and saw this stackoverflow question on internet.
If you think about it, if stationA is waiting for ack from stationB, that means stationA has pretty much secured/locked medium for that long (see Jaydeep's answer) time i.e. (enough time for 2SIFS + 1ACK assuming no follow-up transmission between these 2 stations).
Hence no other station is sending any frame (i.e. ack here), leading no need to distinguish ack.
Its just StationA is waiting for ack from stationB in that time window.
I'm writing an iOS app for a device with a BLE module that advertises a few bytes of data on a consistent basis while it's connected. We are trying to estimate the power consumption of the BLE module so we can estimate the battery life for the device. I've scoured SO and Google looking for the appropriate way to estimate this, but I'm coming up empty. Is there a way to take the number of bytes that are being sent, multiplied by the frequency with which the data is sent and come up with a rough approximation of power consumption?
A typical BLE SoC (i.e. a all-in-one Application + Radio chip) typically consumes:
A few hundreds nA while in deep sleep,
2 to 10 µA while a RTC tracks time (needed between radio events while advertising or connected),
10 to 30 mA while CPU or Radio runs (computing data, TX, RX). RX and TX power consumption is roughly the same.
Life of a BLE peripheral basically consists of 3 main states:
Be idle (not advertising, not connected). Most people will tell your device is off. Unless it has a physical power switch, it still consumes a few hundred nanoamps though.
Advertise (before a connection takes place). Peripheral needs to be running approximatively 5 ms every 50 ms. This is the time when your device actually uses most power because advertising requires to send many packets, frequently. Average power consumption is in the 1-10 mA range.
Be connected. Here, consumption is application-dependant. If application is mostly idle, peripheral is required to wakeup periodically and must send a packet each time in order to keep the connection alive. Even if the peripheral has nothing useful to send, an empty packet is still sent. Side effect: that means low duty cycle applications basically transmit packets for free.
So to actually answer you question:
length of your payload is not a problem (as long as you keep your packets shorts): we're talking about transmitting during 1 µs more per bit, while the rest of the handling (waking up, receiving master packet, etc. kept us awake during at least 200 µs);
what you actually call "continuous" is the key point. Is it 5 Hz ? 200 Hz ? 3 kHz ?
Let's say we send data at a 5 Hz rate. Power estimate will be around 5 connection events every second, roughly 2 ms CPU + Radio per connection event, so 10 ms running every second. Average consumption: 200 µA (.01 * 20 mA + .99 * 5 µA)
This calculation does not take some parameters into account though:
You should add consumption from your sensors (Gyro/Accelerometers can eat a few mA),
You should consider on-board communication (i2c, SPI, etc),
If your design actually uses two chips (one for the application talking to a radio module), consumption will roughly double.
Say I have an InfiniBand or similar PCIe device and a fast Intel Core CPU and I want to send e.g. 8 bytes of user data over the IB link. Say also that there is no device driver or other kernel: we're keeping this simple and just writing directly to the hardware. Finally, say that the IB hardware has previously been configured properly for the context, so it's just waiting for something to do.
Q: How many CPU cycles will it take the local CPU to tell the hardware where the data is and that it should start sending it?
More info: I want to get an estimate of the cost of using PCIe communication services compared to CPU-local services (e.g. using a coprocessor). What I am expecting is that there will be a number of writes to registers on the PCIe bus, for example setting up an address and length of a packet, and possibly some reads and writes of status and/or control registers. I expect each of these will take several hundred CPU cycles each, so I would expect the overall setup would take order of 1000 to 2000 CPU cycles. Would I be right?
I am just looking for a ballpark answer...
Your ballpark number is correct.
If you want to send an 8 byte payload using an RDMA write, first you will write the request descriptor to the NIC using Programmed IO, and then the NIC will fetch the payload using a PCIe DMA read. I'd expect both the PIO and the DMA read to take between 200-500 nanoseconds, although the PIO should be faster.
You can get rid of the DMA read and save some latency by putting the payload inside the request descriptor.
when does Wireshark timestamp the packets? After fully receiving a frame? Or already at receiving the first bytes of a frame? I read the following description about Wireshark timestamps but this text only states: "While packets are captured, each packet is time stamped as it comes in".
Consider the following scenario and an accurate OS time:
sender ----> Wireshark ----> receiver
The sender starts the transmission of the frame at time x. The frame is fully received at the receiver at time y (y = transmission start x + frame length / link speed). Will the captured frame appear in the Wireshark with a timestamp close to x or will it be y?
Best regards,
Jonas
Well, Wireshark doesn't time stamp the packets itself; it relies on libpcap to do them and, on almost all operating systems, libpcap doesn't time stamp them itself, either, the OS's packet capture mechanism, as used by libpcap does. The main exception is Windows, where WinPcap has to provide its own capture mechanism in the kernel, atop NDIS, but the mechanism behaves very similarly to the mechanisms inside most UN*Xes, and will give similar behavior. (The other exception is HP-UX, where the OS's capture mechanism doesn't time-stamp packets at all, so libpcap does so; that gives answers that are somewhat similar to other OSes, but with a potentially even longer delay before the packets are time-stamped.)
If Wireshark (or any other packet sniffer!) is run on the sender, the packets will be "wrapped around" within the OS and handed to the capture mechanism; the time stamp could be applied before the sender starts transmitting the packet, but the time stamp will be closer to x than to y.
If Wireshark (or any other packet sniffer) is run on the receiver, the time stamp is applied at some time after the entire packet has been received; that could involve delays due to packet being queued up, interrupts being "batched", some amount of network-stack processing being done before the packet is time stamped, etc.. The time stamp will be closer to y than to x.
If Wireshark (or any other packet sniffer) is being run on some third machine, passively sniffing a network, the time stamp will probably be closer to y than to x, but there's a difference due to the receiver and the sniffer being separate machines that might see the packet at different times, have different code paths for receiving, etc..
On one end, you have TCP, which guarantees that packets arrive and that they arrive in order. It's also designed for the commodity Internet, with congestion control algorithms that "play nice" in traffic. On the other end of the spectrum, you have UDP, which doesn't guarantee arrival time and order of packets, and it allows you to send large data to a receiver. Somewhere in the middle, you have reliable UDP-based programs, such as UDT, that offer customized congestion control algorithms and reliability, but with greater speed and flexibility.
However, what I'm looking for is the capability to send large chunks of data over UDP (greater than the 64k datagram size of UDP), but without a concern for reliability of each individual datagram. The idea is that the large data is broken down into datagrams of a specified size (<= 64,000 bytes), probably with some header data stuck on the front and sent over the network. On the receiving side, these datagrams are read in and stored. If a datagram doesn't arrive, all of the datagrams associated with that transfer are simply thrown out by the client.
Most of the "reliable UDP" implementations try to maintain reliability of each datagram, but I'm only interested in the whole, and if I don't get the whole, it doesn't matter - throw it all away and wait for the next. I'd have to dig deeper, but it might be possible with custom congestion control algorithms in UDT. However, are there any protocols with this approach?
You could try ENet, whilst not specifically aimed at what you're trying to do it does have the concept of 'fragmented data blocks' whereby you send data larger than its MTU and it sends as a sequence of datagrams of its MTU with header details that relate one part of the sequence to the rest. The version I'm using only supports 'reliable' fragments (that is the ENet reliability layer will kick in to resend missing fragments) but I seem to remember seeing discussion on the mailing list about unreliable fragments which would likely to exactly what you want; i.e. deliver the whole payload if it all arrives and throw away the bits if it doesn't.
See http://enet.bespin.org/
Alternatively take a look at the answers to this question: What do you use when you need reliable UDP?