Re: Diagnosing terrible ixl performance

2018-04-19 Thread Julian Elischer

On 20/4/18 12:03 pm, Garrett Wollman wrote:

I'm commissioning a new NFS server with an Intel dual-40G XL710
interface, running 11.1.  I have a few other servers with this
adapter, although not running 40G, and they work fine so long as you
disable TSO.  This one ... not so much.  On the receive side, it gets
about 600 Mbit/s with lots of retransmits.  On the *sending* side,
though, it's not even able to sustain 10 Mbit/s -- but there's no
evidence of retransmissions, it's just sending really really slowly.
(Other machines with XL710 adapters are able to sustain full 10G.)
There is no evidence of any errors on either the adapter or the switch
it's connected to.

So far, I've tried:

- Using the latest Intel driver (no change)
- Using the latest Intel firmware (breaks the adapter)
- Disabling performance tweaks in loader.conf and sysctl.conf
- Changing congestion-control algorithms

replacing  card?  obvious but you don't list it...



Anyone have suggestions while I still have time to test this?  (My
plan B is to fall back to an X520 card that I have in my spares kit,
because I *know* those work great with no faffing about.)  Any
relevant MIBs to inspect?

The test I'm doing here is simple iperf over TCP, with MTU 9120.  It
takes about 10 seconds for the sending side to complete, but buffers
are severely constipated for 20 seconds after that (delaying all
traffic, including ssh connections).

I'm at the point of trying different switch ports just to eliminate
that as a possibility.

that is also a possibility, as well as swap cables with a good machine...



-GAWollman
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: Bad outbound performance with Intel 6205 [Taylor Peak] WiFi (IWN)

2018-04-19 Thread Hrant Dadivanyan
On 04/20/18 06:37, Kevin Oberman wrote:
> I am seeing poor performance on my WiFi that seems to have deteriorated
> since FreeBSD V11.0. I see an average of about 35 errors for every packet
> transmitted.
> wlan0  1500   a0:88:b4:c6:ad:28 14501195 0 0   367667
> 12886354 0
> 
> I have always seen lot of errors on transmission on this interface, but I
> have recently noticed that uploads were very slow. They seem to max out at
> about 20 Mbps (bits, not bytes). For "normal" traffic (as opposed to test
> traffic) it is often much worse, often topping out at around 2 or 3 Mbps.
> 
> No input errors at all and god download performance.
> 
> Are others seeing this? Any suggestions for troubleshooting? I don't see
> much in the way of statistics or diagnostic information on iwn. the man
> page gives me no clues.>

iwn0@pci0:3:0:0:class=0x028000 card=0xc2208086 chip=0x00858086
rev=0x96 hdr=0x00
vendor = 'Intel Corporation'
device = 'Centrino Advanced-N 6205 [Taylor Peak]'
class  = network

iwn0:  mem 0xf0c0-0xf0c01fff at
device 0.0 on pci2

NameMtu Network   Address  Ipkts Ierrs Idrop
IbytesOpkts Oerrs Obytes  Coll
wlan0  1500   84:3a:4b:cb:aa:c0  3914486 2 0
5523440357 7685 2087124 888555 0

The same 6205, I didn't notice bad upload performance though.

Numbers of Ipkts and Oerrs are close enough and Opkts is too small
compared to Ipkts, so I believe the driver misbehaves a bit and
erroneously shows number of output packets as Oerrs.
The Obytes also seems to be too small to be correct.

A few months ago the association with AP starts sometimes to stall with
no traffic in/out at all, reconfig in wpa_cli helps then. Looks like it
correlates with upgrade from 10-stable to 11, but I'm not so sure.

> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 


-- 
Hrant Dadivanyan (aka Ran d'Adi)hrant(at)dadivanyan.net
/* "Feci quod potui, faciant meliora potentes." */   ran(at)psg.com



signature.asc
Description: OpenPGP digital signature


Diagnosing terrible ixl performance

2018-04-19 Thread Garrett Wollman
I'm commissioning a new NFS server with an Intel dual-40G XL710
interface, running 11.1.  I have a few other servers with this
adapter, although not running 40G, and they work fine so long as you
disable TSO.  This one ... not so much.  On the receive side, it gets
about 600 Mbit/s with lots of retransmits.  On the *sending* side,
though, it's not even able to sustain 10 Mbit/s -- but there's no
evidence of retransmissions, it's just sending really really slowly.
(Other machines with XL710 adapters are able to sustain full 10G.)
There is no evidence of any errors on either the adapter or the switch
it's connected to.

So far, I've tried:

- Using the latest Intel driver (no change)
- Using the latest Intel firmware (breaks the adapter)
- Disabling performance tweaks in loader.conf and sysctl.conf
- Changing congestion-control algorithms

Anyone have suggestions while I still have time to test this?  (My
plan B is to fall back to an X520 card that I have in my spares kit,
because I *know* those work great with no faffing about.)  Any
relevant MIBs to inspect?

The test I'm doing here is simple iperf over TCP, with MTU 9120.  It
takes about 10 seconds for the sending side to complete, but buffers
are severely constipated for 20 seconds after that (delaying all
traffic, including ssh connections).

I'm at the point of trying different switch ports just to eliminate
that as a possibility.

-GAWollman
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Bad outbound performance with Intel 6205 [Taylor Peak] WiFi (IWN)

2018-04-19 Thread Kevin Oberman
I am seeing poor performance on my WiFi that seems to have deteriorated
since FreeBSD V11.0. I see an average of about 35 errors for every packet
transmitted.
wlan0  1500   a0:88:b4:c6:ad:28 14501195 0 0   367667
12886354 0

I have always seen lot of errors on transmission on this interface, but I
have recently noticed that uploads were very slow. They seem to max out at
about 20 Mbps (bits, not bytes). For "normal" traffic (as opposed to test
traffic) it is often much worse, often topping out at around 2 or 3 Mbps.

No input errors at all and god download performance.

Are others seeing this? Any suggestions for troubleshooting? I don't see
much in the way of statistics or diagnostic information on iwn. the man
page gives me no clues.

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: max devices in tun

2018-04-19 Thread Akilan Elango
I'm using FreeBSD 11.1 current in a qemu instance. Today I tried it it
said no space left on device. So I can say that it happened for some
other number. (not 32768) Actually I tried other numbers too. and
today it also created a character special device in /dev/tun for some
huge number which wasn't shown in ifconfig. Sorry for any lack of
info. I'll try to gather more from the bash history if I can.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 218579] Wake on Lan doesn't work for bge NIC driver

2018-04-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

--- Comment #9 from Cy Schubert  ---
(In reply to Koen Martens from comment #8)
That bug has been fixed in the latest patch I posted here. No worries about
drawing too much current when powered off any more.

I've been using it and previous versions of this patch on my laptop (only
machine I have with bge) for about a year.

I suppose I should submit the patch in phabricator for review prior to commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


[Bug 218579] Wake on Lan doesn't work for bge NIC driver

2018-04-19 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579

--- Comment #8 from Koen Martens  ---
(In reply to Cy Schubert from comment #6)
Hi, thanks for the reply (and the reworked patch). I guess the patch won't go
upstream because of the reasons mentioned (ie. potential to blow up boards that
can't support enough power when the system is powered down)?

I'm also surprised it did work for me. I actually woke up the machine with
wake-on-lan to ssh into it and upgrade it to 11.1-RELEASE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: svn commit: r332645 - head/sbin/ifconfig

2018-04-19 Thread Alexey Dokuchaev
On Tue, Apr 17, 2018 at 12:54:59PM +, Andrew Gallatin wrote:
> New Revision: 332645
> URL: https://svnweb.freebsd.org/changeset/base/332645
> 
> Log:
>   Make lagg creation more fault tolerant
>   
>   - Warn, don't exit, when SIOCSLAGGPORT returns an error.
>   
>   When we exit with an error during lagg creation, a single
>   failed NIC (which no longer attaches) can prevent lagg
>   creation and other configuration, such as adding an IPv4
>   address, and thus leave a machine unreachable.

Hey Andrew,

Since you're on lagg(4) a bit, could you perhaps have a look at this
thread from last year on -net@:

https://lists.freebsd.org/pipermail/freebsd-net/2017-June/048284.html

I've been asked by several people that were using WiFi-CopperNet failover
which worked fine in FreeBSD 10.x but was broken since then.  I'm not
an src committer nor a network stack expert in this area nor I'm using
lagg(4), but perhaps you could expedite on handling this or at least point
us to a more appropriate channel (due to lack of interest on -net@).

./danfe
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: max devices in tun

2018-04-19 Thread Eugene Grosbein
19.04.2018 7:29, Akilan Elango wrote:

> Hey guys,
> I was fiddling around with the /dev/tun to write a TUN interface
> for my app. I wanted to check what is the max amount of interfaces
> that can be made. Turned out it was 32768 [0 - 32768). But when I
> created (ifconfig tun32768 create), a weird device appeared as shown
> in this figure : https://imgur.com/a/0ypbwgg.
> 
> Is this expected? and I'm unable to delete the device too from ifconfig.

You should tell what FreeBSD version do you use.
It does not do so for my 11.1/i386:

# ifconfig tun32768 create
ifconfig: SIOCIFCREATE2: No space left on device

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"