really long jam period

I've got a situation where I'm seeing a series of jam fragments lasting a total of about 50 ms. I haven't checked the spec but it seems to me that this is a *really* long time.

Here's the setup: I'm working on an embedded system. My device has a 10/100 port and it's connected to a 10/100 dual-speed hub (Netgear DS516). A second port on the hub is connected to a Linux box. A third port is connected to a switch that's connected to a larger test network. Everything is conecting at 100 Mbps.

When my device powers up, it loads an image from the Linux box. Typically, part-way through loading the image, it sees an excessive number of collisions (16) trying to transmit a frame and gives up. When I look at the MII bus between the MAC and PHY using a logic analyzer, I see a long series of jam fragments, each one lasting about

121 us, with about 930 ns between them, for a total of about 50 ms. Between jam fragments, my device tries to transmit its frame, but everytime it starts there's another jam fragment starting at the same time. My device backs off and retries 15 times over a span of about 18 ms, but every time it gets hammered by a jam fragment.

I'm assuming these are jam fragments. Every nibble on the MII bus is 5 while data is valid.

In addition to the Netgear, I've also seen this, with just a slight variation, using a D-Link EFAH16W. The variation is that some of the jam fragments have a pattern of 0x43 but most have 0x55, whereas with the Netgear all of the fragments have 0x55 as the pattern.

If I disconnect the switch from the hub so that my device and the Linux box are the only devices connected, then everything works beautifully and I get no collisions or errors or jamming at all. It's only when I have the switch (with lots of other devices behind it) connected to my hub that problems occur. There isn't a lot of traffic coming from the switch though, mostly ARP requests and other broadcasts.

Can anyone explain why I see this long period of jam fragments? Collisions shouldn't normally cause jamming for this long, right? Could it be flow control?

Any advice is appreciated. I can provide more info if needed. Thanks.

-cb

Reply to
Chris Briggs
Loading thread data ...

[snip]

Not really sure.

What is the nature of the traffic from your device? If it's sending broadcasts, the switch will pass them out to your wild network. It could trigger a malfunctioning device, split-pair cable or software into the packet storm. That 121us jam sounds like a full 1518 byte frame.

This could be a nice opportunity for some network diagnosis. Just to a binary search from the switch if you can shed loads.

-- Robert

Reply to
Robert Redelmeier

There are some broadcasts involved. The protocol looks like this:

DevA: broadcast "hello" frame (64 Bytes) DevB: unicast "ack" frame (64B) DevA: broadcast "load" frame (64B) DevB: unicast "image" frame (1KB) DevA: broadcast "ack" frame (64B) Then repeat image/ack sequence for about 500 exchanges.

I don't see the jams until about 68 frames into the image/ack sequence, which may be a hint that it takes that long for the problematic downstream device to get saturated.

That'll be this afternoon's project.

Thanks.

-cb

Reply to
Chris Briggs

That certainly sounds like it. At this point I'm 99.99% sure it's a flow control issue. I just have to track down the throttling device.

I am absolutely sure there are none connected to the hub that the device and Linux box are on. There is one 10 Mbps hub connected to the switch (not the 100 Mbps hub my devices are connected to). I'm also fairly sure there are some 10 Mbps devices at some point downstream. I'll try pruning these one at a time to see how it goes.

Thanks.

-cb

Reply to
Chris Briggs

You're absolutely right. About an hour ago we double-checked this in our spec and found they should be unicasts. We fixed that and the problem went away.

Thanks.

-cb

Reply to
Chris Briggs

Why so many broadcasts from DevA? Once it has an "ACK", and certainly once it is requesting "LOAD", they should be unicasts, especially the image acks. Imagine if your network has multiple Bs serving multiple As.

Could well be. Sounds like a ~4 KB buffer.

-- Robert

Reply to
Robert Redelmeier

(snip)

There are different ways of building switches, which can have an effect on problems like this. Some have one buffer pool for all ports. Frames come in, are stored in the buffer and scheduled to be sent out. Others have a separate buffer pool for each output port.

With a single buffer, a data stream going out a 10Mb/s port could fill the buffers, reducing the ability to pass traffic between 100Mb/s ports. Having separate buffers for each port reduces the amount of space available for a fast data stream involving only two ports.

Also, broadcast packets will be required to go out all ports, including any 10Mb/s ports.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.