Hello All I’m currently experiencing some strange behaviour with network latency. We’ve got 2 boxes, both running eCos connected via Ethernet, and every so often we get a lag in message delivery from a user pressing a H/W switch on one box, which sends a msg via TCP to the other. Roughly 2 or 3 seconds. I’ve gone back to the nc_master / slave tests and monitored the throughput when connecting a PC to one of the boxes running eCos. Initially everything looked fine until I insert a switch between the PC and eCos box. With any switch between the PC / eCos box, there is poor performance when doing an RX test (PC -> eCos box), which shows lots of out of order delivery / delayed ACK / fast rexmit, and the throughout graph looks like a saw tooth. But hey, the PC’s running faster than the eCos box, so maybe this is to be expected. So I’ve gone back to the eCos -> eCos scenario and extern’d some of the netstack stats and I find there is a direct correlation between the following stats increasing and the delivery delay: cyg_tcpstat.tcps_delack cyg_tcpstat.tcps_rexmttimeo cyg_tcpstat.tcps_rcvoopack Everything will be nice and stable, with consistent message delivery times, then suddenly one of the three above fires and I get 2 -> 4 second delay of message delivery. I’m wondering if the switches I’m placing between the units are causing some sort of flow control issue ? Does anyone know if in the PHY drivers when performing the auto negotiation configures any flow control with a switch, and if this is likely to be the cause? I’m also playing with TCP_NODELAY which seems to influence the behaviour, but doesn’t completely fix the issue. Any help would be appreciated. Andy.
-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
