Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
On Mon, Oct 5, 2020 at 12:22 PM Scott Seekamp wrote: > > I had a similar speed drop on an Edge Router 4. I don’t know if it’s the same > situation on the Lite, but I believe it’s expected due to hardware > acceleration support (or lack of) and single core performance on the pf side. I read somewhere that this drop can happen even with the factory OS - the routing is handled by an ASIC (which is how they push near-gigabit forwarding speeds) but if you do any sort of filtering, it falls back to software routing. Since the ASIC is black box voodoo, OpenBSD will always use the CPU for routing. > > Scott > > > On Oct 4, 2020, at 17:24, Amarendra Godbole > > wrote: > > > > Sorry I forgot including "ifconfig" output: > > > > lo0: flags=8049 mtu 32768 > > index 5 priority 0 llprio 3 > > groups: lo > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet 127.0.0.1 netmask 0xff00 > > > > cnmac0: flags=808843 mtu > > 1500 > > lladdr a8:28:dc:cc:2e:6f > > index 1 priority 0 llprio 3 > > groups: egress > > media: Ethernet autoselect (1000baseT full-duplex,master) > > status: active > > inet 73.xx.xx.xx netmask 0xfe00 broadcast 73.xx.xx.255 > > > > cnmac1: flags=8b43 > > mtu 1500 > > lladdr 78:8a:20:46:a8:c1 > > index 2 priority 0 llprio 3 > > media: Ethernet autoselect (1000baseT full-duplex) > > status: active > > > > cnmac2: flags=8b43 > > mtu 1500 > > lladdr 78:8a:20:46:a8:c2 > > index 3 priority 0 llprio 3 > > media: Ethernet autoselect (none) > > status: no carrier > > enc0: flags=0<> > > index 4 priority 0 llprio 3 > > groups: enc > > status: active > > > > bridge0: flags=41 > > index 6 llprio 3 > > groups: bridge > > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp > > cnmac2 flags=7 > > port 3 ifpriority 0 ifcost 0 > > cnmac1 flags=7 > > port 2 ifpriority 0 ifcost 0 > > vether0 flags=7 > > port 7 ifpriority 0 ifcost 0 > > > > vether0: flags=8943 mtu 1500 > > lladdr fe:e1:ba:d0:c8:a9 > > index 7 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 > > > > pflog0: flags=141 mtu 33136 > > index 8 priority 0 llprio 3 > > groups: pflog > > > >> On Sun, Oct 4, 2020 at 2:22 PM Amarendra Godbole > >> wrote: > >> > >> Hi misc@ > >> > >> I recently introduced an OpenBSD firewall inline and noticed a > >> reduction in overall download speeds. I am trying to understand why > >> this may be so. The firewall is Ubiquiti ERL running 6.7 release. > >> Internet connection is Comcast xfinity via cable modem, plan 200 > >> Mbits/s down and 10 Mbits/s up. Details follow: > >> > >> 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem > >> (speed: ~210 Mbits/s down, 6 Mbits/s up) > >> 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity > >> cable modem (speed: ~90 MBits down, 6 Mbits/s up) > >> 3. config #3 (Line speed): MacBook wired to cable modem (~230 Mbits/s > >> down, ~8 Mbits/s up). > >> > >> Linksys is running latest OpenWrt, and speed tests were run on MacBook > >> connected wired to Linksys. It was difficult to try tcpbench since the > >> setup was cumbersome, and iperf3 public servers end up being busy more > >> often than not (and threads on misc@ indicated iperf3 wasn't as > >> reliable either). Test numbers come from speedtest.net and > >> speed.cloudflare.com. While I realize this speed test is hardly > >> accurate, I have tried to maintain the same configuration (no ERL and > >> inline ERL) to obtain relative numbers. > >> > >> I am trying to understand the reduction from 210 Mbits/s down to 90 > >> Mbits/s down between config #1 and config #2 above. The slowdown is > >> not noticeable to family, so this is more of my intellectual curiosity > >> than screams over a buffering video! :-) > >> > >> Relevant system information (dmesg, etc.) below. All sysctl values > >> attached as sysctl.txt I gathered it by reading similar threads on > >> misc@. If I missed anything, please let me know. Thanks in advance. > >> > >> -Amarendra > >> > >> > >> dmesg: > >> > >> Copyright (c) 1982, 1986, 1989, 1991, 1993 > >> The Regents of the University of California. All rights reserved. > >> Copyright (c) 1995-2020 OpenBSD. All rights reserved. > >> https://www.OpenBSD.org > >> OpenBSD 6.7 (GENERIC.MP) #134: Thu May 7 16:05:06 MDT 2020 > >>dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > >> real mem = 536870912 (512MB) > >> avail mem = 506740736 (483MB) > >> mainbus0 at root: board 20002 rev 2.18 > >> cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > >> cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > >> cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > >> cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > >> clock0 at mainbus0: int 5 > >> octcrypto0 at mainbus0 > >> iobus0 at mainbus0 > >> simplebus0 at iobus0: "soc" > >> octciu0 at simplebus0 > >>
Re: tmux rc script not stopping
On 2020-10-07, ben wrote: >>I think you might need a pexp variable, process grep expression to be used b >>y pgrep to determine if the service is running. > > I've tried using pexp, the result is the same; I can start the script and > receive the 'tmux(ok)' message, but upon running the '/etc/rc.d/tmux stop' > I receive no messages and the script silently exits. > > No messages implies a pexp mismatch. When you start a daemon from an rc.d script the original pexp is saved to /var/run/rc.d/$daemon so that if a package is updated while a daemon is running (which may result in the process title actually changing) it will still be possible to identify if the original daemon is running. So, if you have edited the script to add a pexp *after* starting it, you'll need to remove that /var/run file otherwise it will still use the old one or the default.
Re: cmake does not use -O2 for Release builds
On Tue, 6 Oct 2020 13:29:56 - (UTC)
Stuart Henderson wrote:
> On 2020-10-05, Julian Smith wrote:
> > It looks like OpenBSD's cmake port patches cmake to remove the use
> > of -O2 in Release and RelWithDebInfo builds -
> > /usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has:
> >
> > - string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os
> > -DNDEBUG")
> > - string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
> > - string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g
> > -DNDEBUG")
> > + string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -DNDEBUG")
> > + string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -DNDEBUG")
> > + string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -g
> > -DNDEBUG")
> >
> > Does anyone know why things are patched in this way?
> >
> >
> > [I think one can force optimisation with (for example):
> >
> > cmake -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG" ...
> > ]
> >
> >
> > Thanks,
> >
> > - Jules
> >
>
> It's setup to work with builds done from ports, which should not
> override whatever optimization level is set by either the user or the
> build infrastructure.
>
> The downside is that you need to add this yourself for builds from
> outside ports.
Thanks for the explanation.
Would it be worth documenting this in the cmake(1) manpage? If so, i'll
submit a patch.
It's quite confusing to have cmake not optimise by default for Release
or RelWithDeb builds - i built OpenSceneGraph-3.6 while working on
Flightgear and it took a rather long time to figure out why i was
getting such a reduced frame rate.
Thanks,
- Jules
--
http://op59.net
Re: tmux rc script not stopping
>I think you might need a pexp variable, process grep expression to be used b >y pgrep to determine if the service is running. I've tried using pexp, the result is the same; I can start the script and receive the 'tmux(ok)' message, but upon running the '/etc/rc.d/tmux stop' I receive no messages and the script silently exits.
Re: tmux rc script not stopping
> On Oct 7, 2020, at 2:35 PM, ben wrote:
>
> Hello, Misc;
>
> I'm attempting to write an rc script to start a tmux session:
>
>#!/bin/sh
>
>daemon="/usr/bin/tmux"
>daemon_flags=" new -d -s MAINTMUX -n SHELL"
>
>. /etc/rc.d/rc.subr
>
>rc_reload=NO
>
>rc_stop() {
>/usr/bin/tmux kill-session -t MAINTMUX
>}
>
>rc_cmd $1
>
> I am able to start it, however upon running the stop command I receive no
> output, and the tmux session I've created with the start command is still
> active.
>
> The man pages for rc.subr(8) state that rc_* functions are to be overwritten
> after sourcing rc.subr, which is what I'm doing.
>
> Am I missing something? Is there anything else I need to set prior to
> starting/stopping the rc script? Thank you in advance.
>
>
> Ben Raskin
>
I think you might need a pexp variable, process grep expression to be used by
pgrep to determine if the service is running.
tmux rc script not stopping
Hello, Misc;
I'm attempting to write an rc script to start a tmux session:
#!/bin/sh
daemon="/usr/bin/tmux"
daemon_flags=" new -d -s MAINTMUX -n SHELL"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_stop() {
/usr/bin/tmux kill-session -t MAINTMUX
}
rc_cmd $1
I am able to start it, however upon running the stop command I receive no
output, and the tmux session I've created with the start command is still
active.
The man pages for rc.subr(8) state that rc_* functions are to be overwritten
after sourcing rc.subr, which is what I'm doing.
Am I missing something? Is there anything else I need to set prior to
starting/stopping the rc script? Thank you in advance.
Ben Raskin
Re: OpenBSD on AWS EC2 Nitro
OK, looks like ENA (Elastic Network Adapter) is the main show stopper here, There is a glimpse of optimism here, FreeBSD port of ENA driver is already out there: https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena I'm trying to catch the AMD-specific crash logs from t3a-type instances to post them here. On 06.10.20 07:50, Kirill Peskov wrote: > Hi All! > > Not so long time ago I've got the challenge to fire up OpenBSD instance > in AWS. It was almost out-of-the-box successful with just a few manual > post-configs... However, with recently introduced "Nitro" hypervisor > (heavily streamlined KVM) old methods of hacking OpenBSD into the Amazon > Cloud seem not to be working, due to not yet fully known list of > reasons, but some of the key differences between "t2" and "t3" > generations are obvious, t3 has new components: > > Root disk: NVMe root disk > NIC: Elastic Network Adapter (Amazon ENA) > > In addition, AWS has a bit cheaper line of instances, AMD-based "t3a". > > So far, from the instance startup logs I can see that NVMe device is > detected by OpenBSD kernel, but looks like OS is unable to find root > partition on the drive. AMD instance crashes with kernel fault on very > early stage. > > Has anyone tried the same? Any success? > > > Cheers, > > Kirill smime.p7s Description: S/MIME Cryptographic Signature
