Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
Hello, Scott Seekamp : > 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. The last time I logged on an ubiquiti switch (not a router) on SSH, I was wondering why there was no bridge/switch interface showing up on the interface list. It looks like there is an userland process controlling the switching, probably communicating to a dedicated chip, maybe a dedicated ASIC. As far as I remember, an strace on it did show some ioctl() to some custom /dev/... device. So it looks like a comparison between hardware accelerated routing vs in-kernel routing off the CPU. -- Josuah
Re: man tar
On Sun, Oct 04, 2020 at 03:05:48PM +, Roderick wrote: > > We read there: > > " > -f archive > > Filename where the archive is stored. Defaults to /dev/rst0. If set to > hyphen (?-?) standard output is used. See also the TAPE environment > variable. > > "" > > Well, hyphen (?-?) may also mean stdin as expected, but it seems not > to be mentioned/insinuated on the man page. > > Rod. i just updated the manual to reflect this. thanks, jmc
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
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. 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 >> octsmi0 at simplebus0 >> octpip0 at simplebus0 >> octgmx0 at octpip0 interface 0 >> cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0 >> atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 >> cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1 >> atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 >> cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2 >> atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 >> com0 at simplebus0: ns16550a, 64 byte fifo >> com0: console >> dwctwo0 at iobus0 base 0x118006800 irq 56 >> usb0 at dwctwo0: USB revision 2.0 >> uhub0 at usb0 configuration 1 interfac
Re: Understanding download speed reduction by introducing an inline Ubiquity ERL device
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 > octsmi0 at simplebus0 > octpip0 at simplebus0 > octgmx0 at octpip0 interface 0 > cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0 > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1 > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2 > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > dwctwo0 at iobus0 base 0x118006800 irq 56 > usb0 at dwctwo0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > 2.00/1.00 addr 1 > octrng0 at iobus0 base 0x14000 irq 0 > /dev/ksyms: Symbol table not valid. > umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash > Drive" rev 2.10/11.00 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > serial.21c40cd1719080003000 > sd0: 30526MB, 512 bytes/sector, 62517248 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0
Understanding download speed reduction by introducing an inline Ubiquity ERL device
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 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: RGMII, address 78:8a:20:46:a8:c0 atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: RGMII, address 78:8a:20:46:a8:c1 atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: RGMII, address 78:8a:20:46:a8:c2 atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 /dev/ksyms: Symbol table not valid. umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash Drive" rev 2.10/11.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable serial.21c40cd1719080003000 sd0: 30526MB, 512 bytes/sector, 62517248 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets boot device: sd0 root on sd0a (2124441bc835a462.a) swap on sd0b dump on sd0b WARNING: No TOD clock, believing file system. WARNING: CHECK AND RESET THE DATE! pftcl -s: match in all scrub (no-df random-id max-mss 1440) block drop in quick on ! cnmac0 inet from xx.xx.xx.xx/23 to any block drop in quick inet from xx.xx.xx.xx to any block drop all pass out quick on egress inet from (vether0:network) to any flags S/SA nat-to (egress) round-robin pass out quick inet all flags S/SA pass in on vether0 inet all flags S/SA pass in on cnmac1 inet all flags S/SA pass in on cnmac2 inet all flags S/SA pfctl -si: Status: Enabled for 3 days 18:14:11 Debug: err Interface Stats for egressIPv4 IPv6 Bytes In 645378677790 Bytes Out 70051403810 Packets In Passed560243700 Blocked 430500 Packets Out Passed222710610 Blocked 00 State Table Total Rate current entries 847 half-open tcp 23 searches 158989755 489.4/s inserts 10953073.4/s removals 10944603.4/s Counters match134
Re: man tar
On 04/10/2020 16:05, Roderick wrote:
We read there:
"
-f archive
Filename where the archive is stored. Defaults to /dev/rst0. If set to
hyphen (‘-’) standard output is used. See also the TAPE environment
variable.
""
Well, hyphen (‘-’) may also mean stdin as expected, but it seems not
to be mentioned/insinuated on the man page.
Interesting.
Recent versions of tar(1) on {Free,Net}BSD stipulate:
-f file, --file file
Read the archive from or write the archive to the specified file. The
filename can be - for standard input or standard output. The default
varies by system; on FreeBSD, the default is /dev/sa0; on Linux, the
default is /dev/st0.
I assume it's stdin when compressing and stdout when expanding. Or maybe
vice versa?
--
Ottavio Caruso
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Re: man tar
On Sun, 4 Oct 2020, Ottavio Caruso wrote:
Recent versions of tar(1) on {Free,Net}BSD stipulate: [...]
As far as I know it was always so, as it is also in OpenBSD. But
that is a very interesting issue on history of the tar command.
I see only a documentation problem.
Rod.
Re: Case of the missing softraid
On 2020-10-03, tera torn wrote: > I've been a happy user of OpenBSD softraid RAID 1 mirroring, and I'm > attemtping to migrate data off of a degraded RAID 1 mirror. > > I've booted before from the 6.7 install USB (amd64) and this degraded > chunk was detected and the volume was brought up and my data was there. > > I'm not sure what's happened but now when I boot the same media I'm > unable to detect the softraid volume. I would guess that it most likely got too far into the installer and overwrote the partition table information. What was on the disk - one big single partition for softraid, or was it more complex? > Is there a way to debug this? > Can the chunk be manually mounted as an ffs volume? it should still > contain a normal ffs filesystem somewhere right? Show us current fdisk/disklabel output to eyeball first before you make any changes. If it used the default partition start position and the entire disk was used to create one big softraid partition (with other partitions inside that), then creating a new disklabel with the same configuration should be easy enough. I'm not sure you can get bioctl/softraid to forcibly assemble a new softraid device on a single disk but if the partition is setup in the disklabel and has the correct filesystem type (RAID) it should assemble at boot. If that doesn't help, maybe scan_ffs might be able to find the filesystem inside the softraid; then it should be fairly straightforward to construct a new disklabel allowing it to be mounted. Unfortunately scan_ffs only supports FFS not FFS2 so if it was a newly created or large filesystem that might not be able to help.
Re: Case of the missing softraid
On 2020-10-03 17:45, tera torn wrote: > Hello, > > I've been a happy user of OpenBSD softraid RAID 1 mirroring, and I'm > attemtping to migrate data off of a degraded RAID 1 mirror. > > I've booted before from the 6.7 install USB (amd64) and this degraded > chunk was detected and the volume was brought up and my data was > there. > > I'm not sure what's happened but now when I boot the same media I'm > unable to detect the softraid volume. > > softraid0 is listed by the kernel, but no additional sd device is > configured for the softraid volume. That is always shown, whether softraid is used on the system or not. > Is there a way to debug this? or detect or correct disk corruption so > that this chunk is properly recognized again? The dmesg will give some clues as to what is going on. Hopefully, for Some Reason, the drive just isn't showing up to the machine, the dmesg will show that. Next step, if it is in the dmesg, see if you can get an fdisk and disklabel out of it...does that look sane? > Can the chunk be manually mounted as an ffs volume? it should still > contain a normal ffs filesystem somewhere right? kinda. But rebuilding that would probably be more work than fixing the real problem. > Looking for any way to recover the data in this chunk! Any help > greatly appreciated. I think you need to start with figuring out WHY the volume vanished. Let's hope it's an electrical or mechanical problem. Nick.
man tar
We read there: " -f archive Filename where the archive is stored. Defaults to /dev/rst0. If set to hyphen (‘-’) standard output is used. See also the TAPE environment variable. "" Well, hyphen (‘-’) may also mean stdin as expected, but it seems not to be mentioned/insinuated on the man page. Rod.
