Re: Bufferbloat, FQ-CoDel, and performance
hi i have the same issue , but only in the kernel pppoe interface. interface re3 -> vlan 7 -> pppoe0 ~ 4>ifconfig re3 hwfeatures re3: flags=8843 rdomain 40 mtu 1518 hwfeatures=8037 hardmtu 9194 lladdr 4c:02:89:0d:cb:78 index 4 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.1.250 netmask 0xff00 broadcast 192.168.1.255 on my cable vlan5 is the queue working interface aggr0 -> vlan5 the parent interfaces for the aggr are also re. the speed are messured by the network test on my xbox , pppoe speed drops upload from 30 mbit to 9 mbit. Holger Am 23.02.21 um 22:04 schrieb Stuart Henderson: On 2021-02-23, Stuart Henderson wrote: On 2021-02-23, Steven Shockley wrote: I have OpenBSD 6.8 running on a Dell R210-II acting as a firewall/router. To combat bufferbloat I tried implementing FQ-CoDel queueing. The WAN bandwidth is advertised as 940 Mbit/sec down and 840 Mbit/sec up. Flow queues are broken in 6.8 on interfaces with hw checksum offloading. Fix is in -current or sys/net/pf.c r1.1096 Oops, on interfaces *without* hw checksum offloading, like this: $ ifconfig em0 hwfeatures em0: flags=8843 mtu 1500 hwfeatures=10 hardmtu 9216 ..
OpenBSD: Failing to link custom libpng to custom libz, any thoughts how fix?
Hi, I am trying to make a custom build of libpng in my home directory, using a libz build that I made in my home directory also. Both are latest version, libpng 1.6.37 same as OpenBSD's port https://cvsweb.openbsd.org/ports/graphics/png/Makefile?rev=1.125=text/x-cvsweb-markup and libz the latest one they published. For zlib it's 1.2.11 from http://zlib.net/ from 2017, OpenBSD does not have a port but base bundles a 2009 version. Since 2009, significantly an export "inflateReset2" has been added. I'll start with the detail problem, and discuss the reproduction at the bottom: This has brought me to the bizarre issue that the libpng build plainly refuses to link to my custom libz file /home/myuser/lib/libz.so.1 . Instead, it insists with linking to the OS' global /usr/lib/libz.so.5.0 . /home/myuser/lib/ contains libz.so , libz.a, libz.so.1 and libz.so.1.2.11 . I have reduced the issue to the libpng build step where it produces libpng.so: /usr/local/bin/egcc -shared -fPIC -DPIC -o .libs/libpng.so.16.37 .libs/png.o .libs/pngerror.o .libs/pngget.o .libs/pngmem.o .libs/pngpread.o .libs/pngread.o .libs/pngrio.o .libs/pngrtran.o .libs/pngrutil.o .libs/pngset.o .libs/pngtrans.o .libs/pngwio.o .libs/pngwrite.o .libs/pngwtran.o .libs/pngwutil.o -L/home/myuser/lib -lm -lz -Og -g -fstack-protector-all [with or without: -Wl,--version-script=libpng.vers] [with or without: -Wl,-t] When provided with "-Wl,-t", LD run by GCC prints out: "/usr/lib/crtbeginS.o .libs/png.o .libs/pngerror.o .libs/pngget.o .libs/pngmem.o .libs/pngpread.o .libs/pngread.o .libs/pngrio.o .libs/pngrtran.o .libs/pngrutil.o .libs/pngset.o .libs/pngtrans.o .libs/pngwio.o .libs/pngwrite.o .libs/pngwtran.o .libs/pngwutil.o /usr/lib/libm.so.10.1 /usr/lib/libz.so.5.0 /usr/lib/crtendS.o" which shows that already at link time it picks the OS global one (that is /usr/lib/libz.so.5.0). What appears is that GCC ignores the "-L" search path given to it. "readelf -d .libs/libpng.so.16.37" shows: "Dynamic section at offset 0x40050 contains 25 entries: Tag Type Name/Value 0x001d (RUNPATH) Library runpath: [/home/myuser/lib] 0x0001 (NEEDED) Shared library: [libm.so.10.1] 0x0001 (NEEDED) Shared library: [libz.so.5.0]" Again providing receipt that the wrong LibZ is linked. "objdump -p .libs/libpng.so.16.37" shows the same: ".libs/libpng.so.16.37: file format elf64-x86-64 Program Header: ... Dynamic Section: RUNPATH /home/myuser/lib NEEDED libm.so.10.1 NEEDED libz.so.5.0" The way I got to this issue, was that the libpng "make" would crash with: "ld: error: undefined symbol: inflateReset2 >>> referenced by pngfix.c:2184 (contrib/tools/pngfix.c:2184) >>> contrib/tools/pngfix.o:(zlib_reset) collect2: error: ld returned 1 exit status" This turned out to be that the libpng build process' linking of its "pngfix" accessory tool, would crash because inflateReset2 was not found in the OS' libz (but it is in my custom one). "ldd" showed that libpng.so.17.37 already linked to the OS provided one as discussed above. Whole console interaction leading to the crash below. This whole experience makes me suspicious that maybe for instance "libz" is a reserved filename where only the OS' installation is accepted, but that would make no sense at all? Any thoughts for how to successfully make GCC link, please let me know, Thanks, Bob $ CC=/usr/local/bin/egcc \ > CXX=/usr/local/bin/eg++ \ > LD_LIBRARY_PATH=/home/myuser/lib \ > LDFLAGS="-L/home/myuser/lib -lz " \ > LIBS="-L/home/myuser/lib -I/home/myuser/include -lz " \ > CFLAGS="-Og -g -fstack-protector-all -fpic \ > -I/home/myuser/include -L/home/myuser/lib -lz" \ > CPPFLAGS="-Og -g -fstack-protector-all -fpic \ > -I/home/myuser/include -L/home/myuser/lib -lz " \ > ./configure \ > --prefix=/home/myuser \ > --enable-hardware-optimizations=no \ > --with-pic=yes \ > --enable-unversioned-links \ > --with-zlib-prefix=/home/myuser/lib checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... /usr/local/bin/egcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/local/bin/egcc accepts -g... yes checking for /usr/local/bin/egcc option to accept ISO C89... none needed checking whether /usr/local/bin/egcc understands -c and -o
Re: Bufferbloat, FQ-CoDel, and performance
I just tried tcpbench and UDP is OK, only TCP is slow unless I add a "min" value to the queue On 2/23/21, Jean-Pierre de Villiers wrote: > Have you tried running the same test over UDP? This is done via the > tcpbench's > "-u" option. > > Regards, > Jean-Pierre > > On 21/02/23 11:10am, Horia Racoviceanu wrote: >> I noticed this effect as well. I'm not sure if it's the right thing to >> do, but if a "min" value is added to the hfsc queue, fq_codel will use >> the full link bandwith e.g. >> >> queue outq on em0 bandwidth 9M min 1M max 9M flows 1024 qlimit 1024 \ >> default >> >> On 2/23/21, Todd C. Miller wrote: >> > On Tue, 23 Feb 2021 11:29:00 +0100, Stefan Sperling wrote: >> > >> >> I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 >> >> up). >> >> In this case the VDSL modem presents an Ethernet switch, so there is >> >> no >> >> pppoe or vlan involved in the box that runs pf. >> >> >> >> As soon as I enable this example given in pf.conf(5): >> >> >> >>queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ >> >> default >> >> >> >> I see only about 2 or 3 Mbit/s max upload during tcpbench. >> >> Which is indeed quite a hit compared to 10M. >> > >> > That's odd. I haven't had any problems with a VDSL connection with >> > 100 down / 11 up. My config is very similar to yours: >> > >> > queue outq on em2 flows 1024 bandwidth 10M max 10M qlimit 1024 default >> > >> > where em2 the underlying interface used by pppoe0. Without queueing >> > I have major problems when utilizing the upstream bandwidth, probably >> > due to dropped ACKs. >> > >> > - todd >> > >> > >> >
Re: amdgpu unstable atm
On Fri, Feb 19, 2021 at 06:26:40AM +0900, rgc wrote: > On Fri, Feb 12, 2021 at 07:02:41PM +0900, rgc wrote: > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #323: Tue Feb 9 10:19:03 MST > > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #328: Wed Feb 10 18:08:26 MST > > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > #323 was used over the weekend (2 days) no issues > > > > #328 is running now. playing with vowpal_wabbit (a one-off compile) > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #334: Sun Feb 14 11:49:39 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #338: Tue Feb 16 10:01:46 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ran 334 until yesterday, did a 500Gb dd of the other drive. no hiccups. > > now running 338. installed 2 nights ago. running a vmm, spyder3, firefox-esr > no > issues. until the morning. i had it powered on overnight, xautolock-ed. > when the machine woke up display was "shimering/flickering". rather than > 'reboot', i did a 'zzz' and woke it up again. shimer/flicker was gone. > first time i got this shimer/flicker on any laptop that i use. > > today i didnt hibernate or suspend but this shimer/flicker has not occured > again > after unlocking xautolock. shimer/flicker happened again once on 338. zzz and wake-up again seems to restore things back to normal. updated to the following in the last few days and haven't encountered shimer/flicker or the original issue (X crash) kern.version=OpenBSD 6.9-beta (GENERIC.MP) #344: Fri Feb 19 10:01:51 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP kern.version=OpenBSD 6.9-beta (GENERIC.MP) #350: Sun Feb 21 11:04:59 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP ~ rgc
Windows Host
I installed OpenBSD on Vbox and when I remove the installation media and restart this is what returns. All my other BSD vms are working from this method except for OpenBSD Using drive 0, partition 3, No O/S - Anybody can help me fix this, has this happened to anybody else before. No solution found on reddit and other means.
Re: Bufferbloat, FQ-CoDel, and performance
On 2021-02-23, Stuart Henderson wrote: > On 2021-02-23, Steven Shockley wrote: >> I have OpenBSD 6.8 running on a Dell R210-II acting as a >> firewall/router. To combat bufferbloat I tried implementing FQ-CoDel >> queueing. The WAN bandwidth is advertised as 940 Mbit/sec down and 840 >> Mbit/sec up. > > Flow queues are broken in 6.8 on interfaces with hw checksum offloading. > Fix is in -current or sys/net/pf.c r1.1096 > > > Oops, on interfaces *without* hw checksum offloading, like this: $ ifconfig em0 hwfeatures em0: flags=8843 mtu 1500 hwfeatures=10 hardmtu 9216 ..
Re: Bufferbloat, FQ-CoDel, and performance
On 2021-02-23, Steven Shockley wrote: > I have OpenBSD 6.8 running on a Dell R210-II acting as a > firewall/router. To combat bufferbloat I tried implementing FQ-CoDel > queueing. The WAN bandwidth is advertised as 940 Mbit/sec down and 840 > Mbit/sec up. Flow queues are broken in 6.8 on interfaces with hw checksum offloading. Fix is in -current or sys/net/pf.c r1.1096
Re: Bufferbloat, FQ-CoDel, and performance
I noticed this effect as well. I'm not sure if it's the right thing to do, but if a "min" value is added to the hfsc queue, fq_codel will use the full link bandwith e.g. queue outq on em0 bandwidth 9M min 1M max 9M flows 1024 qlimit 1024 \ default On 2/23/21, Todd C. Miller wrote: > On Tue, 23 Feb 2021 11:29:00 +0100, Stefan Sperling wrote: > >> I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 >> up). >> In this case the VDSL modem presents an Ethernet switch, so there is no >> pppoe or vlan involved in the box that runs pf. >> >> As soon as I enable this example given in pf.conf(5): >> >> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ >> default >> >> I see only about 2 or 3 Mbit/s max upload during tcpbench. >> Which is indeed quite a hit compared to 10M. > > That's odd. I haven't had any problems with a VDSL connection with > 100 down / 11 up. My config is very similar to yours: > > queue outq on em2 flows 1024 bandwidth 10M max 10M qlimit 1024 default > > where em2 the underlying interface used by pppoe0. Without queueing > I have major problems when utilizing the upstream bandwidth, probably > due to dropped ACKs. > > - todd > >
Re: Bufferbloat, FQ-CoDel, and performance
Have you tried running the same test over UDP? This is done via the tcpbench's "-u" option. Regards, Jean-Pierre On 21/02/23 11:10am, Horia Racoviceanu wrote: > I noticed this effect as well. I'm not sure if it's the right thing to > do, but if a "min" value is added to the hfsc queue, fq_codel will use > the full link bandwith e.g. > > queue outq on em0 bandwidth 9M min 1M max 9M flows 1024 qlimit 1024 \ > default > > On 2/23/21, Todd C. Miller wrote: > > On Tue, 23 Feb 2021 11:29:00 +0100, Stefan Sperling wrote: > > > >> I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 > >> up). > >> In this case the VDSL modem presents an Ethernet switch, so there is no > >> pppoe or vlan involved in the box that runs pf. > >> > >> As soon as I enable this example given in pf.conf(5): > >> > >> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ > >> default > >> > >> I see only about 2 or 3 Mbit/s max upload during tcpbench. > >> Which is indeed quite a hit compared to 10M. > > > > That's odd. I haven't had any problems with a VDSL connection with > > 100 down / 11 up. My config is very similar to yours: > > > > queue outq on em2 flows 1024 bandwidth 10M max 10M qlimit 1024 default > > > > where em2 the underlying interface used by pppoe0. Without queueing > > I have major problems when utilizing the upstream bandwidth, probably > > due to dropped ACKs. > > > > - todd > > > > >
Re: Windows Host
> 23. feb. 2021 kl. 18:11 skrev Brandon Helsley : > > > I installed OpenBSD on Vbox and when I remove the installation media and > restart this is what returns. All my other BSD vms are working from this > method except for OpenBSD > > Using drive 0, partition 3, > No O/S > - > Anybody can help me fix this, has this happened to anybody else before. No > solution found on reddit and other means. > Yes, we’ve seen this before. The message pops up when the boot loader is unable to find a kernel, for whatever reason. It would be helpful to get a bit more context such as what hardware is involved or likely what options you set up for the VM’s storage. It’s been a while since I had to work around something like this myself, but the scenario back then involved old hardware with firmware that did not easily or at all see beyond a certain number of cylinders and so needed the kernel to be within that range. I suspect trying again with different configuration options given to the VM pre-install is what you need to do. All the best, Peter N. M. Hansteen — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Re: Bufferbloat, FQ-CoDel, and performance
On Tue, 23 Feb 2021 11:29:00 +0100, Stefan Sperling wrote: > I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 up). > In this case the VDSL modem presents an Ethernet switch, so there is no > pppoe or vlan involved in the box that runs pf. > > As soon as I enable this example given in pf.conf(5): > >queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ > default > > I see only about 2 or 3 Mbit/s max upload during tcpbench. > Which is indeed quite a hit compared to 10M. That's odd. I haven't had any problems with a VDSL connection with 100 down / 11 up. My config is very similar to yours: queue outq on em2 flows 1024 bandwidth 10M max 10M qlimit 1024 default where em2 the underlying interface used by pppoe0. Without queueing I have major problems when utilizing the upstream bandwidth, probably due to dropped ACKs. - todd
Re: Bufferbloat, FQ-CoDel, and performance
On Mon, Feb 22, 2021 at 08:51:32PM -0500, Steven Shockley wrote: > I have OpenBSD 6.8 running on a Dell R210-II acting as a firewall/router. > To combat bufferbloat I tried implementing FQ-CoDel queueing. The WAN > bandwidth is advertised as 940 Mbit/sec down and 840 Mbit/sec up. > > I've tried adding one or the other of these lines to my pf.conf: > > queue outq on $ext_if flows 1024 bandwidth 1024M max 1024M qlimit 1024 > default > or > queue outq on $ext_if flows 1024 qlimit 1024 default > > In both cases, upload speeds drop from ~800 Mbit/sec to < 100 Mbit/sec. > Changing the 1024M to other values makes little or no difference. To be > fair, bufferbloat does improve, but that's quite a hit. I'm measuring using > the dslreports.com speed test via wired ethernet through a Cisco 3750x. > > One possible complexity is that the internal interface is tagged VLANs, but > if it were an MTU issue I'd expect it to affect performance across the > board. > > Any suggestions? I'm happy to post dmesg/pf.conf/diagrams if they'd help. > Thanks. I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 up). In this case the VDSL modem presents an Ethernet switch, so there is no pppoe or vlan involved in the box that runs pf. As soon as I enable this example given in pf.conf(5): queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ default I see only about 2 or 3 Mbit/s max upload during tcpbench. Which is indeed quite a hit compared to 10M. Without the queue tcpbench goes up to 9 Mbit/s. It varies a lot between 5 and 9, which I thought might be a reason for my issue with queueing enabled. Currently, I am simply running this setup without any queueing.
