| Author |
Message |
Chris Briggs
Guest
|
 Posted:
Tue Nov 30, 2004 2:39 am Post subject:
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 |
|
| Back to top |
|
 |
Robert Redelmeier
Guest
|
| Posted:
Tue Nov 30, 2004 5:11 am Post subject:
Re: really long jam period |
|
|
Chris Briggs <chris@engim.com> wrote:
| Quote: | 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.
[snip]
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.
|
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 |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Tue Nov 30, 2004 4:01 pm Post subject:
Re: really long jam period |
|
|
Chris Briggs wrote:
| Quote: | 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.
|
(snip)
There is a system of flow control used on half duplex links,
I believe where a device uses a really long preamble. The
preamble should look like X'55' if you are looking at data,
so that could be it. It is used when the buffer is full,
to slow down the sending device, but it should stay on until
it is ready to accept the next frame.
Are you sure there are no 10 Mb/s links?
-- glen |
|
| Back to top |
|
|
Chris Briggs
Guest
|
| Posted:
Wed Dec 01, 2004 9:04 pm Post subject:
Re: really long jam period |
|
|
Robert Redelmeier <redelm@ev1.net.invalid> wrote in message news:<wUOqd.34823$bP2.7452@newssvr12.news.prodigy.com>...
| Quote: | 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.
|
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.
| Quote: | This could be a nice opportunity for some network diagnosis.
Just to a binary search from the switch if you can shed loads.
|
That'll be this afternoon's project.
Thanks.
-cb |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Wed Dec 01, 2004 9:16 pm Post subject:
Re: really long jam period |
|
|
Chris Briggs <chris@engim.com> wrote:
| Quote: | 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.
|
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.
| Quote: | 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.
|
Could well be. Sounds like a ~4 KB buffer.
-- Robert |
|
| Back to top |
|
|
Chris Briggs
Guest
|
| Posted:
Wed Dec 01, 2004 9:38 pm Post subject:
Re: really long jam period |
|
|
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<5qYqd.112963$V41.74343@attbi_s52>...
| Quote: | There is a system of flow control used on half duplex links,
I believe where a device uses a really long preamble. The
preamble should look like X'55' if you are looking at data,
so that could be it. It is used when the buffer is full,
to slow down the sending device, but it should stay on until
it is ready to accept the next frame.
|
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.
| Quote: | Are you sure there are no 10 Mb/s links?
|
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 |
|
| Back to top |
|
|
Chris Briggs
Guest
|
| Posted:
Thu Dec 02, 2004 3:23 am Post subject:
Re: really long jam period |
|
|
Robert Redelmeier <redelm@ev1.net.invalid> wrote in message news:<o7mrd.25396$fC4.20579@newssvr11.news.prodigy.com>...
| Quote: | Chris Briggs <chris@engim.com> wrote:
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.
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.
|
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 |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Thu Dec 02, 2004 2:17 pm Post subject:
Re: really long jam period |
|
|
Chris Briggs wrote:
(snip)
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in