Re: Degradation of TCP connection

On Aug 6, 6:49 pm, justin.pear...@xxxxxxxxx wrote:
Bill,

Thanks again for your swift and knowledgeable responses. I've
downloaded pcattcp from here

http://www.pcausa.com/Utilities/ttcpdown1.htm

and tried it out. It appears as though I can blast my target with
zillions of packets and it continues, on the surface, to chug along
happily. The Windows machine receives all the frames it expects in a
timely manner, and running ifconfig() on the target does indeed show
the huge number of dropped Rx packets, as we expected. Does this mean
that none of the exceptions you mentioned, e.g.

- exception in tNetTask (or possibly ipnetd using the new IPNET stack
in 6.5)
- exception in interrupt context (buggy interrupt service routine?)
- RX stall (possibly due to mishandled RX overrun in the driver)
- TX stall (possibly due to incorrectly implemented TX cleanup
handling, or mishandled TX underrun)
- RX and TX stall (possibly due to interrupts getting masked off and
not re-enabled, or driver state getting hosed due to a race
condition)
- sluggish response on target shell (possibly due to driver doing too
much work in interrupt context, or making excessive use of intLock()/
intUnlock())

are occurring?

All but the last one: you didn't say if the shell became slow to
respond while ttcp was blasting the target with traffic.

Also, I've got a tool called Colasoft Capsa Packet Builder, which lets
you construct and edit packets, then send them out. If we're thinking
that the driver or network stack might barf if it gets crummy packets,
I could maybe construct some malformed packets with this program and
ship them out on the network. Do you think this would be a fruitful
approach?

I would hold off on this for now. I always tell people I can only
handle one catastrophe at a time. You have one failure scenario
involving your LabView app: focus on that problem rather than trying
too hard to provoke others.

You mentioned some of the causes of being unable to receive packets:

- The RX state in the driver may have fallen out of sync with the chip
- The receiver encountered an error from which the driver couldn't
recover
- RX interrupts have stopped firing
- _all_ interrupts for that port have stopped firing (if TX interrupts
have also stopped, the driver may still be able to send packets onto
the wire for a short time)

Can you please suggest some ways I can test for these cases? My
knowledge of this level of detail of driver/OS architecture is pretty
sparse...!

I wouldn't worry about this just yet. What you really want to do is to
wait for the LabView app to fail again and collect some more data like
I suggested previously. Once you have that data, _then_ you can decide
what to look at next. (This is why I asked if you'd tried to ping the
target once the LabView app stopped working; by using Wireshark you
analyzed the network, but you didn't really do anything to analyze the
target. All you really know about the target is "it stops working."
You need to know more.)

-Bill

Lastly, thanks for the heads up with muxShow(). The second NIC didn't
show up, and I remember one of my coworkers mentioning having to
enable it in the BSP.

Thanks again for your time and attention,
Justin

.

Relevant Pages

  • Re: Degradation of TCP connection
    ... and running ifconfigon the target does indeed show ... the huge number of dropped Rx packets, ... RX stall (possibly due to mishandled RX overrun in the driver) ... RX interrupts have stopped firing ...
    (comp.os.vxworks)
  • Re: Degradation of TCP connection
    ... "Each of our boards will have an ethernet driver specific ... once you get a target into a failed state, ... when the VxWorks box stops ACKing packets sent from the Windows box. ...
    (comp.os.vxworks)
  • Re: bge dropping packets issue
    ... Moreover it seems the Linux driver ... device interrupts normally occur every 150 usec ... For timeouts instead of device polls, at least on old systems it was ... With an rx ring size of just 256 and small packets ...
    (freebsd-net)
  • Re: High resolution timer on kernel mode
    ... The problem I have is that this driver is ... interrupts then do your work in the interrupt handler ... ... timer all of the time ... ... So for me if the packets are coming in very slowly ... ...
    (microsoft.public.development.device.drivers)
  • Re: CE 6.0 Networking Problems
    ... If you're running KITL over Ethernet, when you're running KITL, the hardware ... version of the driver and also with KITL when running a RAM image from PB. ... But perhaps something is still not quite right with the interrupts. ... Also, if I'm pinging from my PC, and then go to my target and ping my ...
    (microsoft.public.windowsce.embedded)