i'm trying set traffic shaping with tc and tbf qdisk on my wireless interface, to limit download bandwidth.
By now I successfully wrote wondershaper, which use HTB. I'd like to use classless shaping, and read that the right qdisk for this job is TBF.
But when I try to set it, had no effect: download keeps going fast.
I tried different ways to do it, but it never worked:
tc qdisc add dev wlan0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1mbit minburst 1540
tc qdisc add dev wlan0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev wlan0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps
tc qdisc add dev wlan0 root tbf rate 10Mbit burst 10kb latency 5ms
tc qdisc add dev wlan0 root tbf rate 220kbit latency 50ms burst 1540
Could anyone give me any advice on how to do it, or where I'm doing wrong??
You need to distinguish the packet direction. The two directions are:
egress: This is about packets leaving your system. In case your system produces packets faster than the medium can handle, your system queues packets. When queuing happens, you can control the order of the queue (scheduling), you can delay sending of packets (shaping) and you can drop packets (dropping).
ingress: This is about packets arriving at your system. You have no control about when packets arrive. All you can do is decide whether you want to process them or not. This is called "policing".
Since your use case is downloading, we are talking about ingress. The token bucket filter is a queuing algorithm, so it does not apply here. The only way to influence a download is to drop packets (or simulate dropping by using ECN). You can find more information about policing in LARTC.
Related
I heard a UDP payload of 508 bytes will be safe from fragments. I heard the real MTU is 1500 but people should use a payload of 1400 because headers will eat the rest of the bytes, I heard many packets will be fragmented so using around 64K is fine. But I want to forget about all of these and programmatically detect what's gets me good latency and throughput from my local machine to my server.
I was thinking about implementing something like a sliding window that TCP has. I'll send a few UDP packets then more and more until packets are lost. I'm not exactly sure how to tell if a packet was delayed VS lost and I'm not sure how to slide by down without going to far back. Is there an algorithm typically used for this? If I know the average hop between my machine and server or the average ping is there a way to estimate the maximum delay time of a packet?
I'm currently working a network protocol which includes a client-to-client system with auto-discovering of clients on the current local network.
Right now, I'm periodically broadsting over 255.255.255.255 and if a client doesn't emit for 30 seconds I consider it dead (then offline). The goal is to keep an up-to-date list of clients runing. It's working well using UDP, but UDP does not ensure that the packets have been sucessfully delivered. So when it comes to the WiFi parts of the network, I sometimes have "false postivives" of dead clients. Currently I've reduced the time between 2 broadcasts to solve the issue (still not working well), but I don't find this clean.
Is there anything I can do to keep a list of "online" clients without this risk of "false positives" ?
To minimize the false positives, due to dropped packets you should alter a little bit the logic of your heartbeat protocol.
Rather than relying on a single packet broadcast per N seconds, you can send a burst 3 or more packets immediately one after the other every N seconds. This is an approach that ping and traceroute tools follow. With this method you decrease significantly the probability of a lost announcement from a peer.
Furthermore, you can specify a certain number of lost announcements that your application can afford. Also, in order to minimize the possibility of packet loss using wireless network, try to minimize as much as possible the size of the broadcast UDP packet.
You can turn this over, so you will broadcast "ServerIsUp" message
and every client than can register on server. When client is going offline it will unregister, otherwise you can consider it alive.
Would sending lots a small packets by UDP take more resources (cpu, compression by zlib, etc...). I read here that sending one big packet of ~65kBYTEs by UDP would probably fail so I'm thought that sending lots of smaller packets would succeed more often, but then comes the computational overhead of using more processing power (or at least thats what I'm assuming). The question is basically this; what is the best scenario for sending the maximum successful packets and keeping computation down to a minimum? Is there a specific size that works most of the time? I'm using Erlang for a server and Enet for the client (written in c++). Using Zlib compression also and I send the same packets to every client (broadcasting is the term I guess).
The maximum size of UDP payload that, most of the time, will not cause ip fragmentation is
MTU size of the host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)
1500 MTU - 20 IP hdr - 8 UDP hdr = 1472 bytes
#EJP talked about 534 bytes but I would fix it to 508. This is the number of bytes that FOR SURE will not cause fragmentation, because the minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)
By the way i'd try to go with 1472 bytes because 1500 is a standard-enough value.
Use 1492 instead of 1500 for calculation if you're passing through a PPPoE connection.
Would sending lots a small packets by UDP take more resources ?
Yes, it would, definitely! I just did an experiment with a streaming app. The app sends 2000 frames of data each second, precisely timed. The data payload for each frame is 24 bytes. I used UDP with sendto() to send this data to a listener app on another node.
What I found was interesting. This level of activity took my sending CPU to its knees! I went from having about 64% free CPU time, to having about 5%! That was disastrous for my application, so I had to fix that. I decided to experiment with variations.
First, I simply commented out the sendto() call, to see what the packet assembly overhead looked like. About a 1% hit on CPU time. Not bad. OK... must be the sendto() call!
Then, I did a quick fakeout test... I called the sendto() API only once in every 10 iterations, but I padded the data record to 10 times its previous length, to simulate the effect of assembling a collection of smaller records into a larger one, sent less often. The results were quite satisfactory: 7% CPU hit, as compared to 59% previously. It would seem that, at least on my *NIX-like system, the operation of sending a packet is costly just in the overhead of making the call.
Just in case anyone doubts whether the test was working properly, I verified all the results with Wireshark observation of the actual UDP transmissions to confirm all was working as it should.
Conclusion: it uses MUCH less CPU time to send larger packets less often, then the same amount of data in the form of smaller packets sent more frequently. Admittedly, I do not know what happens if UDP starts fragging your overly-large UDP datagram... I mean, I don't know how much CPU overhead this adds. I will try to find out (I'd like to know myself) and update this answer.
534 bytes. That is required to be transmitted without fragmentation. It can still be lost altogether of course. The overheads due to retransmission of lost packets and the network overheads themselves are several orders of magnitude more significant than any CPU cost.
You're probably using the wrong protocol. UDP is almost always a poor choice for data you care about transmitting. You wind up layering sequencing, retry, and integrity logic atop it, and then you have TCP.
I am developing an application that sends data per UDP using AsyncUDPSocket class to another client on Mac and Windows. It is very important that packets arrive instantly.
The problem is that every approx. 1000 packets I get a delay for about 2 seconds when receiving Packets. A delay of 100-200 ms would be OK, but 2 seconds produce bad user experience.
I have the UDP communication in a separate Thread, so it is little affected by user interaction with UI and such. I have already tried sending Packets faster, slower, different Packet sizes: the delay stays there. Tried using TCP instead of UDP - same result :(
It does not seem to happen on Windows Cliets.
Maybe there is some system buffer in MacOS that needs to be flushed every time it hast N packets or N bytes of data???
Has anyone an idea how can I prevent the delay from happening?
There are a lot of things that can slow down a network program temporarily, it's hard to know where to start. Have you tried this on multiple networks? Both wireless and ethernet networks? What kind of switch do you have? Does this happen on different OS X computers, or just on one? Can you reproduce the delay with a simpler command line program? Are you using garbage collection? (Grasping at straws here...)
Just out of curiosity, I tested the roundtrip time on UDP echo packets sent from my Mac to another computer on the same LAN. Out of over 60,000 UDP packets with a 1,000 byte payload, none of them took longer than 32 ms, the mean round trip was 0.6 ms, and the sample deviation was 0.21.
(I'm also curious what you need such low latency for.)
I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.
I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here:
http://www.remu.fr/sound-delta/netsend~/
To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.
The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.
I'm curious - what happens to UDP broadcast packets in the router?
If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.
What's stopping me from sending audio up to the bandwidth limit of the WiFi?
any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!
thanks
Nick
Your problem is caused by the access point's rate control algorithm. With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
The simplest solution is to not use multicast when you have a small number of WiFi receivers.
Are all parties connected via WiFi or is the sender using a
wired connection to the Access Point? Broadcast data will
be transmitted as unicast data from a station to an access
point and the access point will then retransmit the data
as broadcast/multicast traffic so it will use twice the
on-air bandwidth compared to when the sender sits on the
wired side of the AP.
When sending a unicast frame the AP will wait for an ACK
from the receiving station and it will retransmit the
frame until the ACK arrives (or it times out). Broadcast/multicast
frames are not ACKed and therefore not retransmitted.
If you have a busy/noisy radio environment this will
cause the likelyhood of dropped packets to increase,
potentially a lot, for multicast traffic compared to unicast
traffic. In an audio application this could certainly be audible.
Also, IIRC, broadcast/multicast traffic does not use the
RTS/CTS procedure for reserving the media which exarbates
the dropped packets problem.
It could actually be the case that multiple unicast streams
work better than a single multicast stream under less-than-ideal
radio conditions given that the aggregated bandwidth is
high enough.
If you can I would suggest that you use wireshark to sniff
the WiFi traffic and take a look at the destination address
in the 802.11 header. Then you can verify if the packets
are actually broadcast or not over the air.
Your design is failing due to a common misconception with WiFi speeds. With 802.11n the number 300mb/s is the link speed, not the actual bandwidth available for user data or even the IP layer. The effective bandwidth is closer to 40mb/s best case, have a look at the FAQ on SmallNetBuilder.com that discusses this in further detail.
http://www.smallnetbuilder.com/wireless/wireless-basics/31083-smallnetbuilders-wireless-faq-the-essentials
I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.
Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.
Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.