On Thu, Oct 20, 2016 at 2:22 AM, Richard Nyberg wrote:
>> For better performance, you can put the if_emx_load="YES" in
>> loader.conf. However, em0 will become emx0 after loading that module,
>> so make sure that your rc.conf and pf.conf are also updated ;)
>
> It turned
> For better performance, you can put the if_emx_load="YES" in
> loader.conf. However, em0 will become emx0 after loading that module,
> so make sure that your rc.conf and pf.conf are also updated ;)
It turned out hw.re.msi.enable="1" did not work so well. re0 simply
stopped doing anything after
On Wed, Oct 19, 2016 at 2:19 AM, Richard Nyberg wrote:
> Hi! Yes it's quite recent hardware.
>
> On 18 October 2016 at 04:20, Sepherosa Ziehau wrote:
>>
>> Heh, I'd say avoid re :).
>
> I might not have made the wisest choice there. :)
>
>> Try put the
Hi! Yes it's quite recent hardware.
On 18 October 2016 at 04:20, Sepherosa Ziehau wrote:
>
> Heh, I'd say avoid re :).
I might not have made the wisest choice there. :)
> Try put the following tunable:
> hw.re.msi.enable="1"
> to /boot/loader.conf. And reboot.
This also
On Tue, Oct 18, 2016 at 4:17 AM, Richard Nyberg 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:
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
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 wrote:
> That kinda sounds like an interrupt issue, in which case I suggest turning
That kinda sounds like an interrupt issue, in which case I suggest turning
polling on for both interfaces. ifconfig 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
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
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
On Sun, Oct 16, 2016 at 11:49 AM, Richard Nyberg 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
Thanks!
Here are some more datapoints.
Yeah the switch for the lan is a simple Netgear GS105. My previous df
gateway was connected in the same way, also with an internal em0,
Turning pf off does not help.
Switching cable and port between df and the switch does not help.
Pinging www.google.com
This is a problem that's going to require more data.
- If you turn pf off, does the problem go away?
- If you ping from the DragonFly machine to your desktop, do you get
the same results?
- If you ping for an extended period (ping -t), do you get more timeouts?
- Are you directly connected to the
Hi users!
I've just changed hardware for my gateway. It's now built on the asus
z170i pro gaming motherboard and runs df 4.6. Unfortunately it suffers
extreme latency on my lan and I don't know how to troubleshoot this.
Between other devices on the lan there's no problem. The gateway isn't
loaded
14 matches
Mail list logo