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.
On 16 October 2016 at 19:14, Matthew Dillon <dil...@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.
> On Sun, Oct 16, 2016 at 9:17 AM, Justin Sherrill <jus...@shiningsilence.com>
>> On Sun, Oct 16, 2016 at 11:49 AM, Richard Nyberg <rnyb...@murmeldjur.se>
>> > 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.