Re: Rsync is too slow

[Rupert Gallagher]

‐‐‐ Original Message ‐‐‐
On Thursday 30 July 2020 22:37, Chris Cappuccio  wrote:

> Rupert Gallagher [r...@protonmail.com] wrote:
>
> > No, I am not using USB.
>
> your dmesg didn't make it to the list because you are attaching a text file
> and attachments are not allowed on misc.
>
> please put it inline with the message.


OK


OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17125511168 (16332MB)
avail mem = 16593870848 (15825MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f0c3000 (34 entries)
bios0: vendor American Megatrends Inc. version "1.2" date 11/05/2019
bios0: Supermicro A2SDi-4C-HLN4F
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT APIC BDAT HPET UEFI SSDT SSDT 
SSDT DMAR SPCR HEST BERT ERST EINJ WSMT
acpi0: wakeup devices XHC1(S4) OBL1(S4) LAN1(S4) PEX0(S4) LAN2(S4) LAN3(S4) 
PEX1(S4) PEX6(S4) PEX7(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 4 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 1104.90 MHz, 06-5f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: cannot disable silicon debug
cpu0: smt 0, core 2, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 12 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 1100.10 MHz, 06-5f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: cannot disable silicon debug
cpu1: smt 0, core 6, package 0
cpu2 at mainbus0: apid 16 (application processor)
cpu2: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 1100.10 MHz, 06-5f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 2MB 64b/line 16-way L2 cache
cpu2: cannot disable silicon debug
cpu2: smt 0, core 8, package 0
cpu3 at mainbus0: apid 24 (application processor)
cpu3: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 1100.10 MHz, 06-5f-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 2MB 64b/line 16-way L2 cache
cpu3: cannot disable silicon debug
cpu3: smt 0, core 12, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 6 (VRP0)
acpiprt2 at acpi0: bus 2 (PEX0)
acpiprt3 at acpi0: bus 1 (VRP2)
acpiprt4 at acpi0: bus 7 (VRP1)
acpiprt5 at acpi0: bus -1 (PEX1)
acpiprt6 at acpi0: bus 3 (PEX6)
acpiprt7 at acpi0: bus 4 (PEX7)
acpiprt8 at acpi0: bus 5 (BR28)
acpicpu0 at acpi0: C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu1 at acpi0: C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu2 at acpi0: C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu3 at acpi0: C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0003" at acpi0 not configured
acpicmos0 at acpi0
"IPI0001" at acpi0 not configured
"PNP0C33" at acpi0 not configured
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 1104 MHz: speeds: 2200, 2100, 2000, 1900, 1800, 1700, 
1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
pci0 at 

Re: Rsync is too slow

[Rupert Gallagher]

‐‐‐ Original Message ‐‐‐
On Thursday 30 July 2020 22:36, Chris Cappuccio  wrote:

> Rupert Gallagher [r...@protonmail.com] wrote:
>
> > No, I am not using USB.
>
> rsync between disks should be very fast.

Right.

> you are going from the sata to the nvme ?

No. It is SATA to SATA, using a M14TQC with a Mini-SAS HD to 4 SATA cable:

https://www.supermicro.com/en/products/accessories/mobilerack/CSE-M14TQC.php

> it might be interesting to try using cp between filesystems, or tar
>
> such as: cp -r /usr/bin /mnt/usr/bin
> or: tar cf - -C /usr/bin . | tar xpf - -C /mnt/usr/bin
>
> also what speeds are you getting on the destination filesystem?
>
> dd count=1 bs=1G if=/dev/zero of=/mnt/test conv=fsync
>
> might give you some rough idea of what 1G write costs.
>
> here's 1G write on my Samsung 845DC Pro which is one of my all-time favorite
> SATA SSDs for reliability
>
> dd count=1 bs=1G if=/dev/zero of=test conv=fsync
>
> =
>
> 1+0 records in
> 1+0 records out
> 1073741824 bytes transferred in 2.906 secs (369450372 bytes/sec)
>
> here's the same for a Crucial M500
>
> dd count=1 bs=1G if=/dev/zero of=test conv=fsync
>
> =
>
> 1+0 records in
> 1+0 records out
> 1073741824 bytes transferred in 4.356 secs (246484472 bytes/sec)
>
> it's not clear to me how much the buffer cache affects this but i'm hoping
> here that conv=fsync helps. in a wierd twist, tests like this with conv=fsync
> run consistently faster than without, so my understanding isn't that great.

Yours are NVMe. I have an SSD on a SATA bus.

This is my result:

>doas dd count=1 bs=1G if=/dev/zero of=/archive2/test conv=fsync
1+0 records in
1+0 records out
1073741824 bytes transferred in 8.118 secs (132261121 bytes/sec)

>grep archive2 /etc/fstab
[label].a /archive2 ffs rw,nodev,nosuid,softdep,noatime 1 2

However, 1G is not enough to go past the cache in ram.

This is what I do:

write test
doas /bin/dd if=/dev/zero of=$testfile bs=$(( $bs * 1024 )) count=$count 
conv=sync

read test
doas /bin/dd if=$testfile of=/dev/null bs=$(( $bs * 1024 )) conv=sync

where

$testfile = /archive2/test for example
$bs=$(( stat -f "%k" /dev/sd1a )) where sd1a is the device of /archive2

count=$(( $ram / ( $bs * 1024 ) )); # ram expressed in blocks
count=$(( $count + 1 )); # exceed ram by 1 block

This is the speed test on WDS400T1R0A (WD RED SSD 4TB)

Free disk space: 3151013175296 bytes
RAM: 17125511168 bytes
fs block size  : 8192 bytes
Size of test file  : 17129537536 bytes = 2042 block(s) of 8192K
Test file  : /archive2/disk-speed-test.raw

Writing speed  : 182 MB/s
Reading speed  : 109 MB/s

The product brief of WD RED SSD says "560MB/s read" and "530MB/s write".

By comparison, this is the speed test on the ST2000NX0403 (Seagate Exos 2TB)

Writing speed  : 117 MB/s
Reading speed  : 99 MB/s

The product brief of the Exos says "136MB/s" max transfer.

Both the exos and the wd red have hardware bytes/sector of 512.

This is how I prepared both, with details for the wd red ssd only:

> fdisk -iy -g sd1

>echo "/  1G-*  100%" >/tmp/my_disk_label
>disklabel -w -A -T /tmp/my_disk_label sd1

> disklabel -hn sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: WDC  WDS400T1R0A
duid: b8d30be7c118b250
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 59967
total sectors: 7814037168 # total bytes: 3.6T
boundstart: 64
boundend: 7814037105
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a: 3.6T   64  4.2BSD   8192 65536 1
  c: 3.6T0  unused

> newfs -O2 sd1a
/dev/rsd1a: 3815447.8MB in 7814036928 sectors of 512 bytes
1168 cylinder groups of 3266.88MB, 52270 blocks, 104704 inodes each
super-block backups (for fsck -b #) at:
[omissis]

> dumpfs /dev/sd1a | head -19

magic   19540119 (FFS2) timeWed Jul 29 18:41:40 2020
superblock location 65536   id  [ 5f21a6c4 bb9dec49 ]
ncg 1168size488377308   blocks  484536905
bsize   65536   shift   16  mask0x
fsize   8192shift   13  mask0xe000
frag8   shift   3   fsbtodb 4
minfree 5%  optim   timesymlinklen 120
maxbsize 0  maxbpg  8192maxcontig 1 contigsumsize 0
nbfree  60567111ndir1   nifree  122294269   nffree  16
bpg 52270   fpg 418160  ipg 104704
nindir  8192inopb   256 maxfilesize 36033195603132415
sbsize  8192cgsize  65536   csaddr  3304cssize  24576
sblkno  16  cblkno  24  iblkno  32  dblkno  3304
cgrotor 0   fmod0   ronly   0   clean   1
avgfpdir 64 avgfilesize 16384
flags   none
fsmnt
volname swuid   0

Finally, this is how I use rsync:

#!/bin/sh
from="$1";
to="$2";
if [[ "$from" == "" || "$to" == "" ]]; then
   echo "usage: copy /from /to":
   

Re: Logging in/out on console while logged in in X removes hardware acceleration

[Mihai Popescu]

| Well then, I guess I just stop switching around between different login
sessions

What about avoiding Ctrl+Alt+F1 (and ... F5 wich is X) and use ... +F2,
+F3, etc.?
You could still miss some settings, I am not sure.

I wonder if /etc/fbtab is able to support multiple tty entries and manage
them each.

Re: wireguard multiple interfaces

[Sonic]

On Fri, Jul 31, 2020 at 3:15 PM  wrote:
> Use multiple interfaces, one per site to connect with. Overhead isnt really 
> present, its just routing and hashes at that point.
> (I’ve had no issues doing site to sites in this fashion, has been working 
> great for months)

I was picturing 3 wgx interfaces, one per vlan, on all systems. The
"server" (the "client" sites need access to the "server" but not to
each other) would be the only box that would have multiple peers
listed for each wgx interface. I thought this might simplify the
setup, but not really sure. Would make it easy to see the traffic
generated per vlan through the vpn.

Re: wireguard multiple interfaces

[obsdml]

Use multiple interfaces, one per site to connect with. Overhead isnt really 
present, its just routing and hashes at that point.
(I’ve had no issues doing site to sites in this fashion, has been working great 
for months)



> On Jul 31, 2020, at 10:43 AM, Sonic  wrote:
> 
> The need is for site-to-site vpns (multiple client sites to one server
> site), 3 vlans each.
>> From a management point of view it might be better to use 3 wireguard
> interfaces on all of the routers (wg0, wg1, wg2). But I'm not sure if
> that adds overhead, and if so how much.
> Basically, is it better to use just one tunnel (wg0) or 3?
> 
> Thanks for any insights.
> 
> Chris

wireguard multiple interfaces

[Sonic]

The need is for site-to-site vpns (multiple client sites to one server
site), 3 vlans each.
>From a management point of view it might be better to use 3 wireguard
interfaces on all of the routers (wg0, wg1, wg2). But I'm not sure if
that adds overhead, and if so how much.
Basically, is it better to use just one tunnel (wg0) or 3?

Thanks for any insights.

Chris

Re: Logging in/out on console while logged in in X removes hardware acceleration

[Nils Reuße]

Hi Theo,

thank you for your reply.  Well then, I guess I just stop switching 
around between different login sessions ;)


Nils


Am 31.07.2020 um 16:08 schrieb Theo de Raadt:

I'm not sure what can be done about it.

/etc/fbtab's first role is to give access to subsystems, but it's
second more important role is to *take them away* later.

Unfortunately there is nothing "keeping state" about previous access
conditions, as well it is quite unclear if reverting to previous access
conditions would be a safe choice.


=?UTF-8?Q?Nils_Reu=c3=9fe?=  wrote:


Dear all,

logging in and out changes the owner of the /dev/drm0 file, so that one
loses hardware acceleration in X when additionally logging in and out on
a console.  Here's what I do:

1) Boot Openbsd and log into X with xenodm.  Ownership of /dev/drm0:

  $ ls -l /dev/drm0
  crw---  1 nils  wheel   87,   0 Jul 31 13:07 /dev/drm0

2) Switch to a console (e.g. CTRL-ALT-F1) and log in with the same user.
   The file is now owned by my user-group:

  $ ls -l /dev/drm0
  crw---  1 nils  nils   87,   0 Jul 31 13:07 /dev/drm0

3) Log out from the console.  Ownership changes back to root/wheel,
thereby disabling hardware acceleration in X:

  $ ls -l /dev/drm0
  crw---  1 root  wheel   87,   0 Jul 31 13:07 /dev/drm0

To regain hardware acceleration, I have to manually chown the file back
to my userid, or relogin with xenodm.  So I guess logging in chowns the
file with my user (even with my user group when logging in via console),
and logging out reassigns the file owner to root.

I guess not much can be done about this, or can it?

Nils

Re: Logging in/out on console while logged in in X removes hardware acceleration

[Theo de Raadt]

I'm not sure what can be done about it.

/etc/fbtab's first role is to give access to subsystems, but it's
second more important role is to *take them away* later.

Unfortunately there is nothing "keeping state" about previous access
conditions, as well it is quite unclear if reverting to previous access
conditions would be a safe choice.


=?UTF-8?Q?Nils_Reu=c3=9fe?=  wrote:

> Dear all,
> 
> logging in and out changes the owner of the /dev/drm0 file, so that one 
> loses hardware acceleration in X when additionally logging in and out on 
> a console.  Here's what I do:
> 
> 1) Boot Openbsd and log into X with xenodm.  Ownership of /dev/drm0:
> 
>  $ ls -l /dev/drm0
>  crw---  1 nils  wheel   87,   0 Jul 31 13:07 /dev/drm0
> 
> 2) Switch to a console (e.g. CTRL-ALT-F1) and log in with the same user. 
>   The file is now owned by my user-group:
> 
>  $ ls -l /dev/drm0
>  crw---  1 nils  nils   87,   0 Jul 31 13:07 /dev/drm0
> 
> 3) Log out from the console.  Ownership changes back to root/wheel, 
> thereby disabling hardware acceleration in X:
> 
>  $ ls -l /dev/drm0
>  crw---  1 root  wheel   87,   0 Jul 31 13:07 /dev/drm0
> 
> To regain hardware acceleration, I have to manually chown the file back 
> to my userid, or relogin with xenodm.  So I guess logging in chowns the 
> file with my user (even with my user group when logging in via console), 
> and logging out reassigns the file owner to root.
> 
> I guess not much can be done about this, or can it?
> 
> Nils
> 

Re: Recommendations for USB Barcode Scanner and Thermal Receipt Printer

[ibsens]

So I would not need to deal with USB printers anymore, I got a thermal
printer with an ethernet port. I communicate with it by ESC/POS over
UDP to port 9100.

Logging in/out on console while logged in in X removes hardware acceleration

[Nils Reuße]

Dear all,

logging in and out changes the owner of the /dev/drm0 file, so that one 
loses hardware acceleration in X when additionally logging in and out on 
a console.  Here's what I do:


1) Boot Openbsd and log into X with xenodm.  Ownership of /dev/drm0:

$ ls -l /dev/drm0
crw---  1 nils  wheel   87,   0 Jul 31 13:07 /dev/drm0

2) Switch to a console (e.g. CTRL-ALT-F1) and log in with the same user. 
 The file is now owned by my user-group:


$ ls -l /dev/drm0
crw---  1 nils  nils   87,   0 Jul 31 13:07 /dev/drm0

3) Log out from the console.  Ownership changes back to root/wheel, 
thereby disabling hardware acceleration in X:


$ ls -l /dev/drm0
crw---  1 root  wheel   87,   0 Jul 31 13:07 /dev/drm0

To regain hardware acceleration, I have to manually chown the file back 
to my userid, or relogin with xenodm.  So I guess logging in chowns the 
file with my user (even with my user group when logging in via console), 
and logging out reassigns the file owner to root.


I guess not much can be done about this, or can it?

Nils

Re: Droping UDP traffic

[Ivo Chutkin]

Hello guys,

Thanks for suggestions.

Tweacking sysctl

net.inet.udp.recvspace=131072
net.inet.udp.sendspace=131072

solved the problem.

Test between routers that started to drop packets over 10Mbit, now run 
test at 100Mbit with less than 1% drops (over 50% before).


I run the folowing test:

APU 6.7 -->vlan-->Supermicro 6.7 (production)-->ospf over 
vlan-->supermicro 6.4 (production)-->APU 6.4


softnet on supermicro 6.4 is about 22% and increses to 27-30% during the 
test with 100Mbit.


On supermicro 6.7 it is about 2% and does not change during the tests.

Supermicro are identical sysytems as dmesg below, running 6.7 and 6.4.

To answer other questions, I do not do a lot filtering, just block ssh 
on external interfaces. There is no noticable increase in cpu and momory 
loads during the tests.


Routers run bgp and ospf but I do not think it is a problem.

After upgrading routers I will report back.

Thanks for your help.

Best regards,
Ivo



On 31.7.2020 г. 10:14 ч., Tom Smyth wrote:

Can you post your pf.conf...

If ur not using much filtering try pfctl -d  to diasble pf and repeat 
testing


Run top -S  to see if sofnet is at 100%






On Thursday, 30 July 2020, Ivo Chutkin > wrote:


Hello all,

I run small ISP. All routers and firewalls run OpenBSD.

Reticently, client started to complain that their Citrix based
systems started to drop connections.

After some research, they tested with iperf and clearly see droped
UDP packets between my routers.

After that, I made test lab, and the results are not very nice.

I tested with iperf between directly connected (via Juniper EX4200
switch) OpenBSD 6.7 amd64 MP, dmeseg of sender and server are below.

APU Sender--->Juniper EX4200 ---> Supermicro Server

iperf -c serverIP -u -t 60 -b 10M -p 5003 no drops

iperf -c serverIP -u -t 60 -b 20M -p 5003 average 2% drops

iperf -c serverIP -u -t 60 -b 30M -p 5003 avarage 15% drops

iperf -c serverIP -u -t 60 -b 40M -p 5003 avarage 20% drops

iperf -c serverIP -u -t 60 -b 50M -p 5003 between 25% drops


Also tested other lab with simmular results

APU Sender--->Juniper EX4200 ---> Supermicro Forwardig > TPlink
switch > Supermicro Server


Is this expected or know behavior?

Am I missing some tweaks?

Is the hardware not powerful enough?

Any ideas and suggestions are appreciated.

Thanks for your help,
Ivo


APU:
~ # dmesg
OpenBSD 6.7 (GENERIC.MP ) #5: Tue Jul 21 13:50:07
MDT 2020


r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 4246003712 (4049MB)
avail mem = 4104691712 (3914MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3)
UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz, 14-02-00
cpu0:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache,
512KB 64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully
associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.01 MHz, 14-02-00
cpu1:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache,
512KB 64b/line 16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully
associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGPB)
acpiprt2 at acpi0: bus -1 (HDMI)

Re: Recommendations for USB Barcode Scanner and Thermal Receipt Printer

[Stuart Henderson]

On 2020-07-29, Rubén Llorente  wrote:
> Thank you for the advice. I will search for those ones and see what I can 
> find.
>
> I still need to solve the printer issue. So far it looks like receipt 
> printers use very simple interfaces. Somebody engineered ppd files for Zjian 
> printers for Linux, but I don't know if the OpenBSD kernel would interface 
> with them. They are certainly not in the USB Product/Vendor database of the 
> kernel. Maybe they would show as Unknown Printers?

For standard device types, USB typically uses "class drivers", there are
specifications for e.g. mass storage, USB-attached SCSI, human interface
devices (mouse/keyboard/etc), etc, including printers. If the device
follows one of these it doesn't need a specific driver or information
about the particular device in the kernel (the kernel product/vendors
are used when the device doesn't use a class driver or needs some
special quirks, or as a fallback if the device doesn't report a
human-readable vendor/product name).

Really unless you can find someone with a particular device you'll need
to take a gamble, or buy something that you can return if incompatible.

ppd files can be used on OpenBSD.

Re: Droping UDP traffic

[Tom Smyth]

Can you post your pf.conf...

If ur not using much filtering try pfctl -d  to diasble pf and repeat
testing

Run top -S  to see if sofnet is at 100%






On Thursday, 30 July 2020, Ivo Chutkin  wrote:

> Hello all,
>
> I run small ISP. All routers and firewalls run OpenBSD.
>
> Reticently, client started to complain that their Citrix based systems
> started to drop connections.
>
> After some research, they tested with iperf and clearly see droped UDP
> packets between my routers.
>
> After that, I made test lab, and the results are not very nice.
>
> I tested with iperf between directly connected (via Juniper EX4200 switch)
> OpenBSD 6.7 amd64 MP, dmeseg of sender and server are below.
>
> APU Sender--->Juniper EX4200 ---> Supermicro Server
>
> iperf -c serverIP -u -t 60 -b 10M -p 5003 no drops
>
> iperf -c serverIP -u -t 60 -b 20M -p 5003 average 2% drops
>
> iperf -c serverIP -u -t 60 -b 30M -p 5003 avarage 15% drops
>
> iperf -c serverIP -u -t 60 -b 40M -p 5003 avarage 20% drops
>
> iperf -c serverIP -u -t 60 -b 50M -p 5003 between 25% drops
>
>
> Also tested other lab with simmular results
>
> APU Sender--->Juniper EX4200 ---> Supermicro Forwardig > TPlink switch
> > Supermicro Server
>
>
> Is this expected or know behavior?
>
> Am I missing some tweaks?
>
> Is the hardware not powerful enough?
>
> Any ideas and suggestions are appreciated.
>
> Thanks for your help,
> Ivo
>
>
> APU:
> ~ # dmesg
> OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020
>
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> real mem = 4246003712 (4049MB)
> avail mem = 4104691712 (3914MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
> bios0: vendor coreboot version "4.0" date 09/08/2014
> bios0: PC Engines APU
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
> PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
> UOH3(S3) UOH4(S3) UOH5(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD G-T40E Processor, 1000.14 MHz, 14-02-00
> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
> V,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,
> CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,
> CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD G-T40E Processor, 1000.01 MHz, 14-02-00
> cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
> V,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,
> CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,
> CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu1: 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGPB)
> acpiprt2 at acpi0: bus -1 (HDMI)
> acpiprt3 at acpi0: bus 1 (PBR4)
> acpiprt4 at acpi0: bus 2 (PBR5)
> acpiprt5 at acpi0: bus 3 (PBR6)
> acpiprt6 at acpi0: bus -1 (PBR7)
> acpiprt7 at acpi0: bus 5 (PE20)
> acpiprt8 at acpi0: bus -1 (PE21)
> acpiprt9 at acpi0: bus -1 (PE22)
> acpiprt10 at acpi0: bus -1 (PE23)
> acpiprt11 at acpi0: bus 4 (PIBR)
> acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> cpu0: 1000 MHz: speeds: 1000 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00
> ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
> (0x2c00), msi, address 00:0d:b9:3d:ea:fc
> rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
> ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi
> pci2 at ppb1 bus 2
> re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
> (0x2c00), msi, address 00:0d:b9:3d:ea:fd
> rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
> ppb2 at pci0 dev 6 function 0 "AMD 14h