Hi, I have a 25 mb up/25 mb down Internet Leased Line from Service Provider delivered directly from their MUX Port at their BTS. The problem is that I never get 25 mbps tcp upload speed. TCP download speed is perfectly 25 mbps. Also checked with UDP upload and download that is also 25 mbps. But when ever TCP Upload takes place the speed varies between 10 and 18 giving an average of 16 mbps max. I have already talked with the provider and they are very casual and just showed UDP upload using WAN Killer software.. I need something strong to prove them. Please guide me a proper troubleshooting process.. My link is delivered via 1 Gbps full duplex ethernet port both set at auto negotiation at MUX end and Laptop end. asked 06 Aug '16, 05:26  srijit92 showing 5 of 6 show 1 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
The transmission speed (regardless whether upload or download) does not depend only on the bandwidth of your connection to the ISP's POP but also on the available bandwidth on the path between the POP and the remote endpoint of the connection, as well as on the ability of the remote endpoint of the connection to process the incoming or outgoing data. You haven't given any information about the remote endpoint and its position in the network so it is hard to say whether it is some artificial limitation imposed by your ISP or something beyond their responsibility that reduces your TCP upload speed.
Another point is how you measure. Applications tend to indicate "netto" bitrates, i.e. without taking into account the overhead (IP and TCP headers of the packets) and eventual retransmissions.
So you may capture an upload of a single file and use Wireshark's statistics tools to find out what is the brutto bitrate on the session, see the number of retransmissions etc.
You (we) should compare two sybchrobised traces: The first one should be taken as close as possible to the client and the second trace should be taken as close as possible to wan interface.
@sindy - I have upload the file to a server having more than 200 mbps uplink and enough free bandwidth was there for link testing.. The testing mechanism was first a simple speedtest, then ftp upload, iperf. Al results were almost same that is 25 mbps download but very unstable upload giving average of 16 mbps and not going between 5 to 18 mbps..
Also checked when I am downloading a file while upload is in progress then download is also falling drastically to 8 to 10 mb and total of up+down is between 25 to 30 mbps at all time..
I am confused why UDP is always fine but it breaks in TCP and that too in upload. In a simple 150 mb file upload to several server there are average 500+ re transmissions as seen from wireshark.
Link for PCAP - http://www.filedropper.com/wiresharkpcapng23a7996d-d285-4da2-816b-b1d2d743bde620160808080235a04252 http://www.filedropper.com/zz_1
From my point of view is your not much worth, if you want to say something about bandwith usage. There are a lot of "packet not captured" messages inside and in combination with "ACKED unseen packet" it seems that you didn´t capture every packet.
And also I can´t see any packet with IP.SRC= 104.211.104.104
How do you want me to capture it? I captured the previous one after starting the uload and ending before its completion your ip.src shows only 1 packet
Before answering your last question: as the device from which you upload has a private IP address, I suppose there is a NATting router between that device and the uplink channel. It is possible that this router is the bottleneck, as processing NAT on TCP needs more resources than processing NAT on UDP.
To answer your question:
Please capture without any capture filter. You are interested in upload speed, but to understand what is happening, we need to see the reverse direction as well. If even without any capture filter there are still "previous packet not captured" messages, the possible reasons are the following:
you are capturing using another machine than the one which uploads the file, and the capturing machine is too slow so it drops some packets
you are capturing on the machine which uploads the file but it is too slow so it drops some packets (which could also explain why it doesn't make use of the bandwidth)
you are capturing on the machine which uploads the file but its network card performs "TCP offloading" which causes some frames to bypass WinPcap/NPcap. Check the settings of your network card driver and disable any "TCP offloading" or "chimney" feature.
In any case, start capturing before starting the upload (so that the session establishment phase is captured as some information is only available in the initial packets) and stop capturing when the upload finishes.
After saving the capture, apply a display filter
ip.addr == 104.211.104.104and then useFile->Export Specified Packets->Displayedto save only the tcp session of interest into a new file you would then publish.It would be also good if you could simultaneously capture at the server itself and publish both captures. This could at least tell something about the behaviour of the NAT device.