Re: Degradation of TCP connection

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?

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?

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...!

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
    ... "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: 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: 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)