On Tue, Oct 18, 2016 at 4:17 AM, Richard Nyberg <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>> > <[email protected]> >>> > wrote: >>> >> >>> >> On Sun, Oct 16, 2016 at 11:49 AM, Richard Nyberg >>> >> <[email protected]> >>> >> 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
