extreme network latency

[Sepherosa Ziehau]

On Tue, Oct 18, 2016 at 4:17 AM, 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?

Heh, I'd say avoid re :).

Try put the following tunable:
hw.re.msi.enable="1"
to /boot/loader.conf.  And reboot.

Output of pciconf -lvc would really be helpful.

Thanks,
sephe

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



-- 
Tomorrow Will Never Die