> > There won't be any indication in the driver since flow control
> > is managed in hardware. You'd need a wire capture to see that
> > bce(4) has stopped sending frames in response to receiving an
> > XOFF flow control frame or started sending frames in response
> > to receiving an XON flow cont
> > I do still see fixed setups in service provider handoffs - for example
> > this colo, Level3 and Hurricane. Also all our metro ethernet stuff
> > specifies a fixed configuration.
>
> Well one could also say that this sort of thing tends to result from
> the, "There is a knob, I MUST twist it!
On 07/11/2011 22:47, Charles Sprickman wrote:
> On Mon, 11 Jul 2011, Doug Barton wrote:
>
>> On 07/11/2011 21:09, Charles Sprickman wrote:
>>> I've had it hammered into my brain over the years that for servers it's
>>> always best to set link speed and duplex manually at both ends to remove
>>> an
On Mon, 11 Jul 2011, Doug Barton wrote:
On 07/11/2011 21:09, Charles Sprickman wrote:
I've had it hammered into my brain over the years that for servers it's
always best to set link speed and duplex manually at both ends to remove
any possible issues with link negotiation.
That hasn't been th
On 07/11/2011 21:09, Charles Sprickman wrote:
> I've had it hammered into my brain over the years that for servers it's
> always best to set link speed and duplex manually at both ends to remove
> any possible issues with link negotiation.
That hasn't been the right thing to do for at least 8 year
On Mon, 11 Jul 2011, David Christensen wrote:
I'm running 8.1 and at least on the bce hosts, it looks like flow
control
isn't supported, it was added on 4/30/2010:
http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=206268&r2=20
7411
In my 8.1 sources I still see this comment, which wa
> I'm running 8.1 and at least on the bce hosts, it looks like flow
> control
> isn't supported, it was added on 4/30/2010:
>
> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=206268&r2=20
> 7411
>
> In my 8.1 sources I still see this comment, which was removed in the
> above
> commit
On Fri, 8 Jul 2011, David Christensen wrote:
I was able to reproduce the drops in very large numbers on the internal
network today. I simply scp'd some large files from 1000/FD hosts to a
100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the
1000/FD hosts sending the files sho
> I was able to reproduce the drops in very large numbers on the internal
> network today. I simply scp'd some large files from 1000/FD hosts to a
> 100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the
> 1000/FD hosts sending the files showed massive amounts of drops on the
> sw
On Thu, 7 Jul 2011, YongHyeon PYUN wrote:
On Thu, Jul 07, 2011 at 02:00:26AM -0400, Charles Sprickman wrote:
More inline, including a bigger picture of what I'm seeing on some other
hosts, but I wanted to thank everyone for all the fascinating ethernet BER
info and the final explanation of what
> > Any thoughts on that? It's the only thing that differs between the
> two
> > switches.
> >
>
> This makes me think possibility of duplex mismatch between bce(4)
> and link partner. You should not use forced media configuration on
> 1000baseT link. If you used manual media configuration on bce
On Jul 6, 2011, at 5:50 PM, Kevin Oberman wrote:
[ ... ]
> Any modern Ethernet should be running full-duplex.
Sure. With a price point of ~$10 per port for unmanaged gigabit switches
nowadays, this is cheap enough that it's widely deployed even for SOHO and
small offices. Also, I don't believe
On Thu, Jul 07, 2011 at 02:00:26AM -0400, Charles Sprickman wrote:
> More inline, including a bigger picture of what I'm seeing on some other
> hosts, but I wanted to thank everyone for all the fascinating ethernet BER
> info and the final explanation of what the "IfHCInBadOctets" counter
> repr
Broadcom bce nics are trash. I see the same packet loss on linux as weel.
The best solution is add/replace with another brand.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
Kevin Oberman wrote:
> ... Years ago, when coaxial Ethernet the norm ...
Aha! Another old-timer who has been around long enough to remember
10Mb Ethernet! Maybe something in the following will ring a bell?
I have a (to me) very strange problem, for which I have a usable
workaround but no actu
More inline, including a bigger picture of what I'm seeing on some other
hosts, but I wanted to thank everyone for all the fascinating ethernet BER
info and the final explanation of what the "IfHCInBadOctets" counter
represents. Interesting stuff.
On Wed, 6 Jul 2011, YongHyeon PYUN wrote:
O
On Wed, Jul 6, 2011 at 1:04 PM, Chuck Swiger wrote:
> On Jul 6, 2011, at 12:27 PM, Kevin Oberman wrote:
>> 1 in 10**6? That is totally excessive.
>
> It's high for a switched LAN, but I'd imagine you remember collision rates on
> hubs, which might well exceed 1% of the packets when the network is
On Wed, Jul 06, 2011 at 02:47:24PM -0700, David Christensen wrote:
> > > > Data sheet says IfHCInBadOctets indicates number of octets received
> > > > on the interface, including framing characters for packets that
> > > > were dropped in the MAC for any reason.
> > >
> > > The IfHcInBadOctets coun
> > > Data sheet says IfHCInBadOctets indicates number of octets received
> > > on the interface, including framing characters for packets that
> > > were dropped in the MAC for any reason.
> >
> > The IfHcInBadOctets counter says the controller received X bytes
> > that were bad on the wire (colli
> You had 282 RX buffer shortages and these frames were dropped. This
> may explain why you see occasional packet loss. 'netstat -m' will
> show which size of cluster allocation were failed.
> However it seems you have 0 com_no_buffers which indicates
> controller was able to receive all packets de
On Wed, Jul 06, 2011 at 02:28:19PM -0700, David Christensen wrote:
> > You had 282 RX buffer shortages and these frames were dropped. This
> > may explain why you see occasional packet loss. 'netstat -m' will
> > show which size of cluster allocation were failed.
> > However it seems you have 0 com
On Mon, Jul 04, 2011 at 09:32:11PM -0400, Charles Sprickman wrote:
> Hello,
>
> We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510)
> and I'm seeing occasional packet loss on them (enough that it trips nagios
> now and then). Cabling seems fine as neither the switch nor t
On Jul 6, 2011, at 12:27 PM, Kevin Oberman wrote:
> 1 in 10**6? That is totally excessive.
It's high for a switched LAN, but I'd imagine you remember collision rates on
hubs, which might well exceed 1% of the packets when the network is under load.
> The Ethernet spec requires no worse than 10**
On Jul 5, 2011 4:49 PM, "Chuck Swiger" wrote:
>
> On Jul 4, 2011, at 6:32 PM, Charles Sprickman wrote:
> > We're running a few 8.1-R servers with Broadcom bce interfaces (Dell
R510) and I'm seeing occasional packet loss on them (enough that it trips
nagios now and then). Cabling seems fine as nei
On Jul 4, 2011, at 6:32 PM, Charles Sprickman wrote:
> We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510)
> and I'm seeing occasional packet loss on them (enough that it trips nagios
> now and then). Cabling seems fine as neither the switch nor the sysctl info
> for the
Just adding a bit more information inline:
On Mon, 4 Jul 2011, Charles Sprickman wrote:
Hello,
We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510)
and I'm seeing occasional packet loss on them (enough that it trips nagios
now and then). Cabling seems fine as neither t
Hello,
We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510)
and I'm seeing occasional packet loss on them (enough that it trips nagios
now and then). Cabling seems fine as neither the switch nor the sysctl
info for the device show any errors/collisions/etc, however there
27 matches
Mail list logo
