extreme network latency

[Matthew Dillon]

Our network dev Sephe might be able to work out why the NICs are
interfering with each other, but it depends how old they are.  If they are
old card(s) and/or it is an old motherboard, it might not be worth tracking
down.  Polling is a perfectly acceptable solution for older stuff.  If the
NICs are relatively recent, though, we would want to try to track down the
problem.

I think it is at least worth doing a verbose boot and posting the dmesg
output from it, and also posting the output from 'pciconf -lbcv' with both
NICs present.

-Matt

On Mon, Oct 17, 2016 at 1:17 PM, Richard Nyberg <rnyberg at murmeldjur.se>
wrote:

> Yes, that was it. Many thanks!
>
> Should I just use polling, which works fine, or is there something one
> can do about the interrupt issue?
>
> -Richard
>
> On 17 October 2016 at 22:05, Matthew Dillon <dillon at backplane.com> wrote:
> > That kinda sounds like an interrupt issue, in which case I suggest
> turning
> > polling on for both interfaces.  ifconfig <blah> polling ought to do
> it.  If
> > that fixes the problem, then it is definitely interrupt-related.
> >
> > -Matt
> >
> > On Mon, Oct 17, 2016 at 12:52 PM, Richard Nyberg <rnyberg at murmeldjur.se>
> > wrote:
> >>
> >> Thanks again for your suggestions.
> >>
> >> Actually it's much stranger than I thought. While troubleshooting I
> >> had this configuration:
> >>
> >> df (em0) -> switch <- desktop
> >>
> >> No other devices or network interfaces were connected. In this
> >> configuration there was no problem at all with latency. I then plugged
> >> in the cable with internet acces like below:
> >>
> >> internet <- (re0) df (em0) -> switch <- desktop
> >>
> >> In this configuration the latency problems immediately showed. The fun
> >> thing is that when I unplugged the re0 interface again the em0
> >> interface stopped responding at all, until I put the cable back to
> >> re0. Then em0 was back but with latency problems.
> >>
> >> Another data point is that while I downloaded a large file at speed
> >> from the internet via df to my desktop in the above configuration and
> >> pinged from the desktop to df at the same time, the latency problems
> >> were gone. Until the download was finished and they started again.
> >>
> >> -Richard
> >>
> >> On 16 October 2016 at 19:14, Matthew Dillon <dillon at backplane.com>
> wrote:
> >> > Look for a packet loop on the interface.  Use tcpdump on the interface
> >> > to
> >> > see if there are excess packets being generated from somewhere.  There
> >> > are
> >> > numerous things that can blow up a LAN.  The most common being that a
> >> > switch
> >> > port is wired to loop back into the LAN.
> >> >
> >> > -Matt
> >> >
> >> > On Sun, Oct 16, 2016 at 9:17 AM, Justin Sherrill
> >> > <justin at shiningsilence.com>
> >> > wrote:
> >> >>
> >> >> On Sun, Oct 16, 2016 at 11:49 AM, Richard Nyberg
> >> >> <rnyberg at murmeldjur.se>
> >> >> wrote:
> >> >> > Thanks!
> >> >> >
> >> >> > Here are some more datapoints.
> >> >>
> >> >> I think the only constant at this point is the internal interface on
> >> >> the DragonFly system.  If you hook the em0 interface that's currently
> >> >> internal on the DragonFly machine up to your Internet link (i.e.
> >> >> reverse which interface is internal or external), does it still
> >> >> perform badly?
> >> >>
> >> >> If it doesn't work well, then that interface is bad.  I'd be
> >> >> surprised, cause I've seen network ports go bad very rarely, but it's
> >> >> possible.  Plus, I don't have any other ideas.
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20161017/b48ae4ba/attachment-0001.html>