I am currently working with ATMEL's WINC1500 wifi module on their SAMD21 XPLained development kit.
I am trying to send around 20-40 TCP packets a second (the size doesn't seem to matter in my problem).
What is happening is that when the WINC1500 is in AP mode as a TCP server, once a socket connection is made and I start sending packets across. There are very noticeable stalls in the WINC1500 where the module seems to stop sending TCP packets for around .5 of a second. However receiving packets still run fine.
Because of the rate I am sending packets, the WINC1500 will eventually run out of memory to store my messages I am passing onto it and will returns a BUFFER FULL error and then after the .5 second stall all the messages will send at once (but those that returned the buffer error is lost).
To me it seems like it is a WINC1500 firmware issue, but was wondering if anyone with experience in this chip, or in WiFi/TCP packets in general that could shed some light on where the problem might be?
I have been in contact with Atmel support but it is slow.
Thank you
Related
I am chasing down a bug in my code that I think might have to do with a socket blocking on send. I'm working in C#, using the Socket class in blocking mode. I would love to be able to do some testing in my local environment to see what happens if the SendTo method blocks on send, but I am not sure if there is a way to do this on Windows.
What I am trying to do right now is to have two programs which I'm running locally. One sets up a UDP socket and then reads data very slowly (1 second delay between reads). The other program just sends a firehose of data to the first--one 63k datagram after another as fast as possible in an infinite loop. I was hoping that eventually some buffer somewhere would fill up and SendTo would block, but I am not having any luck.
Is my test fundamentally flawed, or is there some way to actually do this in Windows?
One other note: I am sending my packets on 127.0.0.1--do I actually need to have the packets routed out of my NIC for this to have any chance of working?
UDP is a datagram protocol for unreliable delivery. Your OS can just discard packets; there's no expectation of buffering. In fact, for applications like video streaming it's GOOD to discard packets, else you can end up with a lot of lag. UDP applications should detect lost packets themselves and adapt, e.g. by lowering the video resolution (or whatever makes sense for your type of application).
TCP is the reliable protocol. The OS will talk with the other OS to verify that all TCP data arrived. A slow reader also acknowledges the data slowly, which in turn slows down the sender. localhost simplifies this a bit, but for applications that doesn't really matter.
[edit]
Addressing your problem a bit more directly: since UDP doesn't care one iota about receiving data, you can just drop that receiver. That will loose 100% of the packets, but you were only wondering about the send part.
As for the buffering, you're right that localhost won't be effective. It's way too fast. The best approach might be to intentionally worsen your network connection. Perhaps your Ethernet can be forced to 100 Mbps? Perhaps an USB2 network adapter? UDP might be tolerant about losses, but if you run UDP over a VPN over TCP you suddenly get a bunch of slower software layers. Packets can now get lost after the VPN server, but any packets lost on the way to the VPN server need to be resent. And when that VPN connection runs over some bad WiFi, there's bound to be some packet loss.
I'm struggling to get an embedded platform with fairly standard IPV4 networking running. I have a working prototype which obtains an IP via DHCP without problem on a point to point connection (single cat5 cable) attached to a test laptop.
On my new hardware I get the link up but no DHCP request gets to the server (monitoring with wireshark). However what I do see, 100% repeatable, when those packets should be received, is a couple of ICMPv6 packets from the test laptop. This happens every time, there is no other activity on that link at any other time.
It seems to me that those packets are trying to tell me something, but what? Perhaps the DHCP request is going out but malformed for some reason?
(I can't post the actual packet from my phone, will make a copy and do so later.)
Seems to be something generated by the laptop when it sees the link comes up. Turned out to be unrelated to the issue I had (which was hardware related).
Details:
I am dealing with an issue interfacing to a Modbus over TCP/IP device. We are required to poll a section of the devices modbus registers 4-6 times a second. We have recorded the following times. In control tests, we have been able to communicate at the following speeds:
Control Device: once every 0.0015s with a standard deviation of 0.0001s.
Issue Device: once every 0.5200s with a standard deviation of 0.01s.
After weeks of troubleshooting and packet capture, we had narrowed down the issue to the fact that the device we are communicating with is not issuing, or responding to, TCP handshake packets. However communication is still possible as the query still proceeds exactly 0.3200s after the TCP request is issued and subsequently ignored. Additionally, the issue device Does not support UDP.
Photo of packet capture breakdown [1]: https://i.stack.imgur.com/lCEos.png
The first (top) packet is the control, and the second (bottom) packet is the issue
Question:
Ignoring the fact that the fundamental role of TCP is handshaking, is there a way to reduce, or mitigate entirely, TCP handshaking on an Intel NIC on a Windows 7 machine.
The issue is the requested buffer size from the PLC. We got in contact with the developer of the TCP/IP Modbus server software (same as the PLC manufacturer) and found that the default requested buffer size was 2GB which was too much for the Modbus device we were communicating with. We have a new version of the TCP/IP Modbus server that has a configurable buffer size, and are communicating at 10ms.
I am developing a logic core to perform data transfer between a FPGA and a PC over ethernet, using a LAN8710 PHY on my FPGA board.
I've achieved to transfer some UDP data packets from the FPGA to the PC. It's a simple core that complies with the PHY transfer requirements. It builds the UDP package and transfer it to the PC.
To check the reception on the PC, I am using Wireshark and as said above, I receive the packets correctly. I've checked the reception with a simple UDP receiver written by myself.
But, I've noticed that I only receive these packets when Wireshark is running on the PC. I mean, if Wireshark is ON, my application receives the packets too, and the counter of received packets of the following picture increases. (This picture is not mine, just one from the internet)
http://i.stack.imgur.com/wsChT.gif
If I close Wireshark, the PC stops receiving packets and the counter of received packets stops. My application stops receiving too.
Although novice on networking topics, I suspect that this issue is related to PC-side. Seems like Wireshark is "opening/closing" the ethernet communication channel, or something like that. Does anyone knows about this issue?
To build a functional core to transfer data between a PC and the FPGA, I've developed a core to transfer and receive UDP packets. Next step will be ARP implementation (to let the PC identify my FPGA board, as I understand). What protocols are necessary to perform full-duplex data transfer between this 2 devices?
Thank you very much in advance,
migue.
Check whether you are able to get appropriate receive interrupt at ethernet driver level on PC-side for a single transmitted packet by FPGA. If you do not get the receive interrupt, check on the transmit side(FPGA) for appropriate transmit interrupts for packet that is being transmitted. This should mostly help you in cornering the issue.
As far as i know, wireshark is just a packet analyzer/sniffer. However, if wireshark is suspected, one option could be to try with alternate packet sniffer to rule out if any such scenario is happening.
A handy tool for determining problems in network and also for determining the network statistics shall be netstat. netstat -sp udp shall list down the statistics only for UDP. There are many other parameters that can be used with netstat for diagnosis.
After many months I solved it, I post to help someone stucked in the same point.
Finally I figured out that Wireshark uses a tool to access the network link layer of the computer. This tool allows Wireshark to sniff all incoming and outgoing packets at a specified network device. To do this, the first step is to OPEN the network device, and that's why my program only worked if Wireshark was open.
Regards.
I wrote a program using tcpip sockets to send commands to a device and receive the data from the device. The data size would be around 200kB to 600KB. The computer is directly connected to the device using a 100MB network. I found that the sending packets always arrive at the computer at 100MB/s speed (I have debugging information on the unit and I also verified this using some network monitoring software), but the receiving time differs a lot from 40ms to 250ms, even if the size is the same (I have a receiving buffer about 700K and the receiving window of 8092 bytes and changing the window size does not change anything). The phenomena differs also on different computers, but on the same computer the problem is very stable. For example, receiving 300k bytes on computer a would be 40ms, but it may cost 200ms on another computer.
I have disabled firewall, antivirus, all other network protocol except the TCP/IP. Any experts on this can give me some hints?
I've found the answer to this question. The problem is due to the even/odd number of packets before the last fragment packet caused by the Nagle's algorithm.
see the link which is very informative:
http://www.stuartcheshire.org/papers/NagleDelayedAck/