I'm a new NS-3 user. I'm trying to find and verify the throughput of TCP wireless network. When experimenting with the "ht-wifi-network.cc"(http://www.nsnam.org/doxygen-release/ht-wifi-network_8cc_source.html) in the example file, I used the default settings,which is a UDP flow, and then tried TCP flow. Then I noticed 2 things:
Throughput is very low comparing with datarate, UDP is 22.78 / 65 and TCP is 11.73 / 65. Is this how the result should be like? Because I was expecting at least 30 Mbps out of 65 Mbps.
UDP throughput is almost twice of the TCP throughput. But I expected that TCP throughput would be higher.
Can somebody help and explain why? Thanks!
Related
Is WSASendTo() somehow faster than sendto() on Windows?
Is UDP sendto() faster with a non-blocking socket (if there is space in the send buffer)?
Similar to this question :
Faster WinSock sendto()
From my profiling, the send is network bound with blocking socket, i.e. for example with 100 mbit network both send about 38461 datagrams of size 256 bytes/s which is the network speed allowable, I was wondering if anyone has any preference over the 2 speed wise.
sending from localhost to itself on 127.0.0.1 it seems to handle about 250 k send / s which should be about 64 mbyte/s on a 3 ghz pc
it seems 2 times faster blocking, i.e. without FIONBIO set, i.e. with non blocking set it seems to drop to 32 mbyte/s if I retry on EWOULDBLOCK
I don't need to do any heavy duty UDP broadcasting, only wondering the most efficient way if anyone has any deep set "feelings" ?
Also could there be some sort of transmission moderation taking place on network card drivers could there be a maximum datagrams sendable on a gigabit card say would it tolerate for example 100k sends/s or moderate somehow ?
Here's a network performance issue. On my board there's a Gbit ethernet phy, the Tx speed is much poorer than Rx speed when I test network bandwidth with iperf. After comparing the package which is captured by Wireshark, can find that the board always send out Ethernet frame in 1514 bytes, while it can receive in larger Ethernet frame, which is up to 64k.
This is why Tx performance poor than Rx performance.
iperf send data in 128k per send, in kernel it always segment it into 1514 bytes and send to the network driver.
I traced the sku-len when send data, log as bellow. I guess there's some feature in kernel can send large Ethernet frame, but which is it?
I tried to change mtu to 8000 by ifconfig eth0 mtu 8000 command, but no improvement.
[ 128.449334] TCP: Gang tcp_sendmsg 1176 msg->msg_iter.count=31216,size_goal=65160,copy=11640,max=65160
[ 128.449377] TCP: Gang tcp_transmit_skb skb->len=46336
[ 128.449406] Gang ip_output skb-len=46388
[ 128.449416] Gang ip_finish_output2 skb->len=46388
[ 128.449422] Gang sch_direct_xmit skb->len=46402
[ 128.449499] Gang dev_hard_start_xmit skb->len=1514
[ 128.449503] Gang dwmac_xmit skb->len=1514
[ 128.449522] Gang dev_hard_start_xmit skb->len=1514 <>
[ 128.449528] Gang dwmac_xmit skb->len=1514
What you're seeing (TX 1500 and RX 65K) is most likely due to TCP LRO and LSO - Large Receive Offload and Large Send Offload. Rather than having the OS segment or reassemble the packets, this function is passed off to the NIC to reduce the load on the CPU and improve overall performance.
You can use ethtool to verify if either are set, or enable/disable the offload function.
By use ethtool -k eth0, find that tx-tcp-segmentation is off(fixed).
To enable it, need turn on NETIF_F_TSO in mac driver.
But unluckily, my driver crashes after enable this feature. It is another problem.
Thank you Jeff S
Have 2 Apache IBM HTTP servers with the following settings
ThreadLimit 150
ServerLimit 8
MaxClients 1200
ThreadsPerChild 150
The server has 8 core and 24 Gig Ram (Linux box) I'm looking at increasing the maxclient values. What all are the things I should be considering ?
Also when I do ss -s
Transport Total IP IPv6
1243 - -
RAW 0 0 0
UDP 20 15 5
TCP 836 803 33
INET 856 818 38
FRAG 0 0 0
Does the TCP Total value (836) correspond to the Maxclients setting.?
Thanks
There is no real correspondence. MaxClients is the maximum number of concurrent threads Apache will use. If Apache only ever handled static files, the share of open sockets on Apache's port would be roughly capped by MaxClients.
But backend connections and connection pooling mean you could have far more open sockets than threads (maxclients).
1200 is pretty modest, 2000-3000 is still reasonable.
You can chart the usage via mod_mpmstats.
In theory, max tcp speed is min{rwnd,cwnd} / RTT, where cwnd is congestion window size and rwnd is the receive window size. Assuming cwnd is big enough, it would then just be rwnd/RTT.
Now, if the max window size is 65Kbytes I get (using these calculations from some site):
RTT 10 ms => TCP throughput = 52428000 bps = 52Mbps
RTT 20 ms => TCP throughput = 26214000 bps = 26Mbps
RTT 50 ms => TCP throughput = 10485600 bps = 10Mbps
RTT 100 ms => TCP throughput = 5242800 bps = 5.2Mbps
RTT 150 ms => TCP throughput = 3495200 bps = 4.3Mbps
RTT 200 ms => TCP throughput = 2621400 bps = 2.5Mbps
RTT 300 ms => TCP throughput = 1747600 bps = 1.7Mbps
RTT 500 ms => TCP throughput = 1048560 bps = 1Mbps
How accurate is this? Since I can download from a website (not torrent, direct download) at 5Mbps while having more than 200ms RTT, so I'm above the theoretical max, why does this happen? Do browsers use more than 1 tcp connection for downloads?
Also, I would like to know where exactly rwnd/RTT actually comes from, since rwnd bytes can (and will surely be) be more than 1 TCP segment size, meaning you would be sending way more than 1 segment per RTT start, meaning 1 RTT won't be enough to send and receive ACKs from all the segments sent, so rwnd/RTT actually is pretty far away from the real throughput.
The max window size is not 65Kbytes. The max window size is 65,535 window size units, which may or may not be bytes.
I'm not quite sure I follow your last question. What does the segment size have to do with anything? You can send whatever data you're sending using as many segments as you need.
Do I understand you correctly that you wonder how you can receive "faster that possible"?
The formula you state is correct. The window(s) and the RTT determine your bandwidth (there are other factors, but in most cases these are the important ones).
But I'm wondering about your numbers.
Ad 1) Are you sure about the RTT? This seems pretty high for regular downloads, unless the are transcontinental. Check the RTT by using ping (e.g. ping simtel.net, replace the host name with the host name in question). You can use a more accurate ping utility like my hrping (http://www.cfos.de/ping) (for Windows).
Ad 2) Are you sure about the Window size? 64k is pretty low today, all modern OSes try to negotiate more than that through RFC 1323 Window Scaling (http://en.wikipedia.org/wiki/TCP_window_scale_option). You can use SG TCP/IP Analyzer (http://www.speedguide.net/analyzer.php) to check your RWIN. Another greate tool for checking your connection is Netalyzr (http://netalyzr.icsi.berkeley.edu).
I would be interested to see the measured figures.
I have a server application which send UDP packets at 200Mbps speed. The output ethernet interface is 1000Mbps. But UDP packets burst loss in a irregular interval. I noticed the field SndbufErrors in /proc/net/snmp increased as long as packet loss issue occurred. The packet loss not exists if UDP packets are sent to loopback interface.
There is not any error return by udp.send.
I have digged into Linux kernel, but I'm missing when I reach the route subsystem.
What does SndbufErrors mean? Why does the number increase?