AMD Ryzen 7 1700, Gigabyte AB350-GA, Gigabyte AMD RADEON R5 230
Automatically detects the right resolution. 1440x900 59.90*+ ( For debian an extra manual step to install nofree drivers is required ) Sound works for youtube after executing # mixerctl outputs.master=256,256 dmesg for those who are interested OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17112383488 (16319MB) avail mem = 16586743808 (15818MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeb3b0 (57 entries) bios0: vendor American Megatrends Inc. version "F6" date 04/07/2017 bios0: Gigabyte Technology Co., Ltd. AB350-Gaming 3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT FIDT SSDT SRAT CRAT CDIT SSDT MCFG HPET SSDT UEFI IVRS SSDT SSDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) PTXH(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.86 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TOPEXT,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: TSC frequency 2994864300 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz 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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TOPEXT,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 1700 Eight-Core Processor, 2994.37 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TOPEXT,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TOPEXT,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Ryzen 7 1700 Eight-Core Processor, 2994.37 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TOPEXT,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA cpu4: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cac
Re: Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after upgrade
On 2017-10-31 16:57, Berry Wendermouth wrote: > I will check again with the VPS provider that the interface of the > virtual machine is set to the correct value (virtio). These are the current VM interface settings (anonymized): vif = [ 'vifname=some-name, model=virtio-net, rate=100Mb/s, bridge=xenbr0.781, mac=00:x:x:x:x:x, ip=x.x.x.x x:x:0:0:0:0:3:7' ] So it seems OpenBSD 6.2 finds another way to set the network device, that is `xnf` instead of `vio`. Any thoughts on that?
Re: Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after upgrade
On 2017-10-31 16:00, Chris Cappuccio wrote: > You went from emulated Realtek ethernet to xnf. Can you try other > network interfaces? How would I do this, isn't the interface auto detected by the kernel? So in the 6.1/i386 setup, the default interface was Realtek. We had speed problems with this interface and so we had the VPS provider change the interface of the virtual machine to Virtio, something like this: vif = [ 'vifname=name, model=virto, rate=100Mb/s, bridge=xenbr0.781, mac=00:50:00:00:00:00, ip=x.x.x.x x:x:0:0:0:0:3:7' ] This is also documented here [1][2]. After this change downloading via the external interface on the server worked very well. Now on 6.2 with the `xnf` interface, downloading directly on server also works fine. The problem only occours when download is requested from a VPN client. I will check again with the VPS provider that the interface of the virtual machine is set to the correct value (virtio). Thank you for your feedback. [1] http://xenbits.xen.org/docs/4.3-testing/misc/xl-network-configuration.html [2] https://wiki.xen.org/wiki/Virtio_On_Xen
Re: Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after upgrade
> Per your request on #openbsd, I do a short reply, to let you reply to it > again... Thank you very much Kirill. > Have you tried to "download" from one of the clients, but without using > the VPN? You could use tcpbench or iperf in server mode on one of your > clients and do a port redirect from your WAN interface on the server to > a port which tcpbench or iperf is listening to. That way you can get > more clues regarding whether the issue is with OpenVPN or your network. The server can reach any client in subnet 10.8.0.0 only via VPN. However I noticed that I had a mistake in the iperf test 2 because I got confused with the direction data is send. As "man iperf" states: "To perform an iperf test the user must establish both a server (to discard traffic) and a client (to generate traffic)." Hence by default data is send from iperf client to server. This means in test case 2 data was send from VPN client 10.8.0.4 to VPN server 10.8.0.1, essentially testing upload speed. I conducted another test pushing data from external network to VPN client. === Case 4: WAN ==> Server = via VPN => Client * From some external node, send data to client via server via VPN tunnel * Testresults: # iperf -s -p 5002 Server listening on TCP port 5002 TCP window size: 85.3 KByte (default) [ 4] local 10.8.0.99 port 5002 connected with 85.x.x.x port 54230 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.8 sec 5.38 MBytes 4.19 Mbits/sec → iperf -c 109.x.x.x -p 5002 Client connecting to nohost.xyz, TCP port 5002 TCP window size: 45.0 KByte (default) [ 3] local 192.168.178.26 port 54230 connected with 109.x.x.x port 5002 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.5 sec 5.38 MBytes 4.27 Mbits/sec Compare this to the following: === Case 5: Client <= VPN = Server <= WAN * From client (10.8.0.99) download external file from WAN via VPN tunnel * Testresult: # curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 100M0 481690 0 4985 0 5:50:34 0:00:09 5:50:25 5055 So while pushing data from external network to vpn client works fine, downloading (requesting a download) from WAN on the client is very slow. Doesn't this imply that the VPN connection is "healthy" and that the problem is rather routing/firewall related? Cheers, Berry
Re: Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after upgrade
You went from emulated Realtek ethernet to xnf. Can you try other network interfaces? Berry Wendermouth [bayb...@riseup.net] wrote: > Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after > upgrade > > > Dear OpenBSD Community, > > we are operating an OpenVPN server on OpenBSD. A few days ago we > upgraded to OpenBSD 6.2 > and we are now seeing very slow speeds (<10KB/s) when trying to download > via > the VPN tunnel from the internet (WAN). We did not have this problem > before. > > >From the documented test cases below (Specifically case 2) it does not > look like it is a VPN performance problem (e.g. mtu/encryption > performance related). > We can also exclude bandwidth trottleing by the VPS provider and the > ISP. > > * Did something essential change in `pf`? [4] > * Or is the problem related to OpenBSD's Xen drivers? > > Could someone help us track down the bottleneck? > > Any help and hints are very much appreciated. > > Thank you kindly > > Berry > > PS: for a better viewing experience you may compile this email body with > `asciidoc` > > == Environment > > === Server > * OpenBSD 6.2 / amd64 (-release) + syspatch > * OpenVPN 2.4.4 > * On Virtual Private Server / Xen version "4.9.0" by Xen Project [0] > * Detected CPU: Intel(R) Xeon(R) CPU E5-2620 > * Detected network device: xnf0 > * Firewall configuration: /etc/pf.conf [1] > * System Message Buffer [2] > > === Clients > * OpenBSD 6.2 with OpenVPN 2.4.4 > * GNU/Linux Gentoo with OpenVPN 2.4.4 > * LinesageOS 14.1 with OpenVPN for Android 0.6.73 > > == Detailed Problem Description / Test Results > > Please note: the following documented tests used one and the same client > / network connection: > > * GNU/Linux Gentoo with OpenVPN 2.4.4 > * Connected to router via wifi on internet connection with max 50Mbit/s > download > > To rule out problems with the client local network settings tests with > other client setups on other networks were also performed and showed > identical > results. For brevity they are not documented here. > > === Case 1: Server <==> WAN (ok) > * When on the server, downloading a file from WAN > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 10Mbit/s > * Testresult: > > > $ curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 100 100M 100 100M0 0 9309k 0 0:00:11 0:00:11 --:--:-- > 10.9M > > > === Case 2: Client <= VPN => Server (ok) > * When on the client, downloading a file from server via VPN tunnel > * Scenario: standard download test with `iperf` > * Average Download Speed: ~ 15Mbit/s > * Testresult: > > > # iperf -s > > > --- > Server listening on TCP port 5001 > TCP window size: 16.0 KByte (default) > --- > [ 4] local 10.8.0.1 port 5001 connected with 10.8.0.4 port 34998 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.2 sec 18.5 MBytes 15.2 Mbits/sec > > > # iperf -c 10.8.0.1 > --- > Client connecting to 10.8.0.1, TCP port 5001 > TCP window size: 45.0 KByte (default) > --- > [ 3] local 10.8.0.4 port 34998 connected with 10.8.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 18.5 MBytes 15.5 Mbits/sec > > > === Case 3a: Client <= VPN => Server <==> WAN (broken) > * When on the client, downloading a file from WAN via VPN tunnel > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 5KB/s > * Testresult: > > > curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 0 100M0 149k0 0 5102 0 5:42:32 0:00:30 5:42:02 > 4933 > > > === Case 3b: Client <==> WAN (ok) > * When on the client, downloading a file from WAN directly > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 1100KB/s > * Testresult: > > > curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 100 100M 100 100M0 0 1113k 0 0:01:32 0:01:32 --:--:-- > 1196k > > > == Previous working system > Before the upgrade to OpenBSD 6.2 we had a working system with the > following setup: > > * OpenBSD 6.1 / i386 > * OpenVPN 2.4.1 > * firewall settings were the same [8] > > The fact that we had installed i386 instead o
Re: CUPS and AVAHI (bloatware)
Ingo Schwarze wrote: […] > > > but it's so damn frustrating when I need to look > > up some of the differences. > > On a build slave, i guess you do have the disk space to simply > install all the -doc packages for the packages you are using? > Sure, it's one additional step at install time, but certainly > better than lacking documentation in such a role. > > > And it's a pretty eccentric Linux distro, > > with quite a lot of peculiarities. > > I hope you don't count the use of mandoc among those. :-D Hi Ingo, That's cool… I didn't realize at a time, so I guess mandoc does its job in Alpine Linux as brilliantly as in OpenBSD. Congrats! In regards to installing -doc packages in Alpine, it wasn't such a big deal once I realized the problem. Disk space is not an issue on that build slave either. I think in retrospect the biggest frustration was realizing where the missing doc files are. I don't remember encountering that on other OS'es / distros, for good reason. BTW, great little distro, I enjoyed Alpine quite a lot. And trying to be security-conscious, I believe immunity through diversity is a thing in the software world as well. The more diverse the kernels, C, TLS libs etc., the better (hurray to standards!). I wonder if Alpine will survive in current form the 2017 "privatization" of the (GPL!) grsec patch, though. I, for one, have decided to completely switch to OpenBSD as a direct consequence of it (from Hardened Gentoo). So far, enjoying contributing to a more diverse world! ;-] pgpItQrJzMuD3.pgp Description: OpenPGP digital signature
Re: Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after upgrade
Hi Per your request on #openbsd, I do a short reply, to let you reply to it again... * Berry Wendermouth [2017-10-30 10:48]: > Xen based VPS / OpenBSD 6.2 / OpenVPN 2.4.4 => Slow download speed after > upgrade > > > Dear OpenBSD Community, > > we are operating an OpenVPN server on OpenBSD. A few days ago we > upgraded to OpenBSD 6.2 > and we are now seeing very slow speeds (<10KB/s) when trying to download > via > the VPN tunnel from the internet (WAN). We did not have this problem > before. > > From the documented test cases below (Specifically case 2) it does not > look like it is a VPN performance problem (e.g. mtu/encryption > performance related). > We can also exclude bandwidth trottleing by the VPS provider and the > ISP. > > * Did something essential change in `pf`? [4] > * Or is the problem related to OpenBSD's Xen drivers? > > Could someone help us track down the bottleneck? > > Any help and hints are very much appreciated. Have you tried to "download" from one of the clients, but without using the VPN? You could use tcpbench or iperf in server mode on one of your clients and do a port redirect from your WAN interface on the server to a port which tcpbench or iperf is listening to. That way you can get more clues regarding whether the issue is with OpenVPN or your network. > Thank you kindly > > Berry > > PS: for a better viewing experience you may compile this email body with > `asciidoc` > > == Environment > > === Server > * OpenBSD 6.2 / amd64 (-release) + syspatch > * OpenVPN 2.4.4 > * On Virtual Private Server / Xen version "4.9.0" by Xen Project [0] > * Detected CPU: Intel(R) Xeon(R) CPU E5-2620 > * Detected network device: xnf0 > * Firewall configuration: /etc/pf.conf [1] > * System Message Buffer [2] > > === Clients > * OpenBSD 6.2 with OpenVPN 2.4.4 > * GNU/Linux Gentoo with OpenVPN 2.4.4 > * LinesageOS 14.1 with OpenVPN for Android 0.6.73 > > == Detailed Problem Description / Test Results > > Please note: the following documented tests used one and the same client > / network connection: > > * GNU/Linux Gentoo with OpenVPN 2.4.4 > * Connected to router via wifi on internet connection with max 50Mbit/s > download > > To rule out problems with the client local network settings tests with > other client setups on other networks were also performed and showed > identical > results. For brevity they are not documented here. > > === Case 1: Server <==> WAN (ok) > * When on the server, downloading a file from WAN > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 10Mbit/s > * Testresult: > > > $ curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 100 100M 100 100M0 0 9309k 0 0:00:11 0:00:11 --:--:-- > 10.9M > > > === Case 2: Client <= VPN => Server (ok) > * When on the client, downloading a file from server via VPN tunnel > * Scenario: standard download test with `iperf` > * Average Download Speed: ~ 15Mbit/s > * Testresult: > > > # iperf -s > > > --- > Server listening on TCP port 5001 > TCP window size: 16.0 KByte (default) > --- > [ 4] local 10.8.0.1 port 5001 connected with 10.8.0.4 port 34998 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.2 sec 18.5 MBytes 15.2 Mbits/sec > > > # iperf -c 10.8.0.1 > --- > Client connecting to 10.8.0.1, TCP port 5001 > TCP window size: 45.0 KByte (default) > --- > [ 3] local 10.8.0.4 port 34998 connected with 10.8.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 18.5 MBytes 15.5 Mbits/sec > > > === Case 3a: Client <= VPN => Server <==> WAN (broken) > * When on the client, downloading a file from WAN via VPN tunnel > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 5KB/s > * Testresult: > > > curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 0 100M0 149k0 0 5102 0 5:42:32 0:00:30 5:42:02 > 4933 > > > === Case 3b: Client <==> WAN (ok) > * When on the client, downloading a file from WAN directly > * Scenario: downloaded 100MB file from > http://fra36-speedtest-1.tele2.net/ with curl > * Average Download Speed: ~ 1100KB/s > * Testresult: > > > curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Sp
Re: CUPS and AVAHI (bloatware)
Hi Dumitru, Dumitru Moldovan wrote on Tue, Oct 31, 2017 at 10:58:25AM +0200: > On 30.10.2017 00:32, Ingo Schwarze wrote: >> Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +: >>> man/info pages, pdf/html docs - in -doc; >> Over my dead body. Software without documentation is completely >> useless, almost a crime. Docs must always be available, even on >> a tiny server. The sysadmin logs into the server, needs a brief >> look at the docs to fix stuff -- and is slowed down because the >> docs aren't there, and a web search turns up the wrong version, >> and a wild goose chase ensues? No way. > So true! I am that sysadmin and have such a system as a build slave > among many others (~30 combinations of OS / distro / arch). I > understand why it is built with docs separated in dedicated packages > (it's Alpine Linux, That's actually an interesting distro. :) > designed originally for embedded stuff, where disk space really > counts), Right. When you design an operating system for a specific purpose, some decisions might actually make sense that would be very bad decisions in a general purpose system like OpenBSD or Debian. > but it's so damn frustrating when I need to look > up some of the differences. On a build slave, i guess you do have the disk space to simply install all the -doc packages for the packages you are using? Sure, it's one additional step at install time, but certainly better than lacking documentation in such a role. > And it's a pretty eccentric Linux distro, > with quite a lot of peculiarities. I hope you don't count the use of mandoc among those. :-D Yours, Ingo
Disk/file IO speed Re: OT: Upload and Download to/from an OpenBSD host
> On Mon, Oct 30, 2017 at 09:23:51PM +0200, Mihai Popescu wrote: .. > Back in a former life, I often had to transfer terabytes of information > between hosts in my network. The goal was to reduce the overhead of the > transfer so that more of the data would get transferred. I had been > using netcat/nc and pushing data through the connection as fast as I > could. This worked great, provided I could verify that things were being > transferred without errors. Any connection problems and I'd be screwed. .. > Essentially, he's compressing files and then sending them over to fit > more data down the pipe. I also learned of this other program called .. > Check those out, and I'm very curious if anyone else on the list has > more OpenBSD-centric techniques! For file transfers today, I presume speed is limited not by the networking subsystem or even by compression speed, but instead by the block device/file IO subsystem, which has a cap last time I checked of around 120MB/sec system-wide. (Faster for retrieval from the buffer cache, however that boost drops very quickly.) A SATA SSD gives you ~~450MB/sec, and an M.2 NVME SSD gives you ~~900MB/sec, sequential and random. You get multipliers of that in a RAID. You get some of this performance in OpenBSD today if you make your accesses to /dev/rsd* only, and of 16KB-aligned 16KB multiples, that makes OpenBSD yield ~600MB/sec or so, however this access mode has tons of limitations, for instance /dev/rsd* doesn't support mmap(). My best understanding of OpenBSD's block device/file IO subsystem is that it has a "biglock" and that all underlying disk/file access is serialized / totally synchronous, with no support for or use of multiqueuing or any other parallellization. Implementing asynchronous logics is tedious and from a security perspective I would understand the charm of keeping an implementation that is cemented to be synchronous only. Is this what's going on? All this leads me to the perception that of all areas in OpenBSD, disk/file IO is the weakest/the one with the least strengths, compared to many other areas where obviously OpenBSD is the very best. (Way lower priority topics, however related, are unified buffer cache https://marc.info/?t=14322826671&r=1&w=2 and the buffer cache 4GB limit https://marc.info/?t=14553871052&r=1&w=2 , https://marc.info/?l=openbsd-tech&m=147905745617957&w=2 , https://marc.info/?t=14682443664&r=1&w=2 , https://unix.stackexchange.com/questions/61459/does-sysctl-kern-bufcachepercent-not-work-in-openbsd-5-2-above-1-7gb .) Is there any interest among developers to speed up the disk/file IO? What would it actually involve? What's needed from the community, donations? Would directed donations be welcome? Thank you very much and sorry for the buzz.
Re: OT: Upload and Download to/from an OpenBSD host
Hi Mihai On Mon, 30 Oct 2017 21:23:51 +0200 Mihai Popescu wrote: > I am trying to setup a solution on an OpenBSD computer, where i want > to upload and then download large volume of data. I was using ftpd > daemon to do this, but I wonder if there is another way to do this, > regarding speed of transfer. > If on a trustworthy private network or via a cross over network cable, netcat can be quiet fast, e.g: # I started netcat listening on a host with spare space: $ umask 077; nc -l 5 | dd of=/mnt/kingswood/_home.dump # On the cramped host, I unmounted & disk dumped to netcat: $ mktemp /tmp/operator/tmp.UZEOHQyzDH $ dump -0anu -f - /dev/rwd1f 2>/tmp/operator/tmp.UZEOHQyzDH | nc -N -w 15 torana.internal 5 DUMP: Date of this level 0 dump: Fri Aug 21 12:56:36 2015 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rwd1f (/home) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 190840212 tape blocks. DUMP: Volume 1 started at: Fri Aug 21 12:56:48 2015 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.80% done, finished in 10:21 DUMP: 1.62% done, finished in 10:06 DUMP: 2.44% done, finished in 9:59 DUMP: 3.26% done, finished in 9:52 DUMP: 4.08% done, finished in 9:47 DUMP: 4.91% done, finished in 9:40 . ... DUMP: 97.54% done, finished in 0:15 DUMP: 98.35% done, finished in 0:10 DUMP: 99.17% done, finished in 0:05 DUMP: 99.99% done, finished in 0:00 DUMP: 190837578 tape blocks DUMP: Date of this level 0 dump: Fri Aug 21 12:56:36 2015 DUMP: Volume 1 completed at: Fri Aug 21 23:06:51 2015 DUMP: Volume 1 took 10:10:03 DUMP: Volume 1 transfer rate: 5213 KB/s DUMP: Date this dump completed: Fri Aug 21 23:06:51 2015 DUMP: Average transfer rate: 5213 KB/s DUMP: level 0 dump on Fri Aug 21 12:56:36 2015 DUMP: DUMP IS DONE # Netcat to dd on the spacious host logged: 314140569+87238623 records in 381675140+0 records out 195417671680 bytes transferred in 37251.937 secs (5245839 bytes/sec) $ df -h /mnt/kingswood Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1g 210G182G 17.5G91%/mnt/kingswood $ ls -lh /mnt/kingswood/ total 381722816 -rw--- 1 operator operator 182G Aug 21 23:06 _home.dump ... # After rejigging the disks on the cramped host, newfs, etc, I restored: # nc -l 5 | restore -ryvf - > restore.output.$RANDOM 2>&1 # Transfer the dump back to the previously cramped host, via netcat: $ dd if=/mnt/kingswood/_home.dump | nc -v -N -w 15 kingswood.internal 5 Connection to kingswood.internal 5 port [tcp/*] succeeded! 381675140+0 records in 381675140+0 records out 195417671680 bytes transferred in 29107.667 secs (6713615 bytes/sec) # less /home/restore.output.569 Level 0 dump of /home on kingswood.internal:/dev/wd1f Label: none Verify tape and initialize maps Dump date: Fri Aug 21 12:56:36 2015 Dumped from: the epoch Begin level 0 restore Initialize symbol table. Extract directories from tape Calculate extraction list. Make node .. $ df -h /home Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1d 299G182G102G64%/home 182G was restored on the newly formatted and enlarged partition (now 'd' instead of 'f'), via netcat, from another host. As well as disk partitions, dump(8) works on files & directories too. Everything needed is in base OpenBSD. Ace! -- Craig Skinner | http://linkd.in/yGqkv7
Re: CUPS and AVAHI (bloatware)
On 30.10.2017 00:32, Ingo Schwarze wrote: > Hi, > > Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +: > > >> man/info pages, pdf/html docs - in -doc; > > Over my dead body. Software without documentation is completely > useless, almost a crime. Docs must always be available, even on > a tiny server. The sysadmin logs into the server, needs a brief > look at the docs to fix stuff -- and is slowed down because the > docs aren't there, and a web search turns up the wrong version, > and a wild goose chase ensues? No way. So true! I am that sysadmin and have such a system as a build slave among many others (~30 combinations of OS / distro / arch). I understand why it is built with docs separated in dedicated packages (it's Alpine Linux, designed originally for embedded stuff, where disk space really counts), but it's so damn frustrating when I need to look up some of the differences. And it's a pretty eccentric Linux distro, with quite a lot of peculiarities. […] pgp_d2ih4mXM9.pgp Description: OpenPGP digital signature
Re: Add support for Mac mini 2014
On 31.10.17 8:41 , Mike Larkin wrote:
> This machine is not a macppc. This machine is an amd64.
I was talking about the Mac mini 2005, which was macppc when I last used
it. My current Mac mini 2014 is intel and amd64.
Anyway, my call is still on. Who wants to help with getting OpenBSD to
run on amd64 Mac Mini 2014?
Attaching again my patch and the dmesg of the Mac mini 2014.
*Kristian
--- 6.2/src/sys/dev/acpi/dsdt.c Sun May 28 17:36:45 2017
+++ src/sys/dev/acpi/dsdt.c Mon Oct 30 16:08:39 2017
@@ -2488,6 +2488,11 @@
aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
val, mode, fld->v_field.flags);
break;
+ case ACPI_OPREG_CMOS:
+ printf("RegionSpace: %u\n", ref1->v_opregion.iospace);
+ aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
+ val, mode, fld->v_field.flags);
+ break;
default:
aml_die("Unsupported RegionSpace 0x%x",
ref1->v_opregion.iospace);
OpenBSD 6.2-stable (GENERIC.MP) #3: Mon Oct 30 16:47:38 CET 2017
root@test.localnet:/home/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4147183616 (3955MB)
avail mem = 4014477312 (3828MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x88d1 (49 entries)
bios0: vendor Apple Inc. version "MM71.88Z.0224.B00.1708080033" date 08/08/2017
bios0: Apple Inc. Macmini7,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT DMAR MCFG
acpi0: wakeup devices P0P2(S3) EC__(S3) HDEF(S3) RP03(S4) ARPT(S4) RP04(S4)
GIGE(S4) SDXC(S3) RP05(S3) RP06(S3) XHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz, 2000.33 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2000329420 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz, 2000.00 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz, 2000.00 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz, 2000.00 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xe000, bus 0-154
RegionSpace: 5
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 2 (RP03)
acpiprt3 at acpi0: bus 3 (RP04)
acpiprt4 at acpi0: bus 4 (RP05)
acpiprt5 at acpi0: bus -1 (RP06)
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 m
Re: Add support for Mac mini 2014
On Tue, Oct 31, 2017 at 08:34:12AM +0100, Kristian Peters wrote:
> Hi all,
>
> So, I'm taking this to openbsd-misc and kindly ask who wants to help
> with getting OpenBSD to run (again) on a Mac mini (latest intel model)?
>
> As my knowledge of programming gasio code is limited, I would need help
> to implement that what Mike suggested.
>
> Otherwise, I guess, it's time for me to move on after 10 years macppc or so.
>
This machine is not a macppc. This machine is an amd64.
-ml
> Best wishes, *Kristian
>
> On 30.10.17 21:27 , Mike Larkin wrote:
> >
> > I don't think this is right. It may be "solving" your problem but our rwgas
> > implementation doesn't handle this type of OpRegion. So, at best, we're
> > ignoring
> > the request (with the changes above), or worse, perhaps trashing some
> > memory.
> >
> > Someone needs to add the I/O for this type of region (CMOS NVRAM) to
> > the gasio code in acpi.c. There is a sequence of IN/OUT instructions that
> > need to
> > occur (in a proper order, with correct locking because the OS is using the
> > device also) to get at those NVRAM registers. It probably isn't a huge
> > amount
> > of work, but nobody has stepped up to do it yet.
> >
> > If you want a workaround, you might try just ignoring ACPI_OPREG_CMOS
> > locally
> > in your tree. That too isn't right but at least it won't be possibly causing
> > side effects/damage elsewhere.
> >
> > -ml
> >
> > On Mon, Oct 30, 2017 at 06:31:19PM +0100, Kristian Peters wrote:
> >> Hi,
> >>
> >> As I thought, a simple addition to acpi/dsdt.c and the Mac mini is able
> >> to boot. I used the external hard drive from a fresh 6.2-install on
> >> another computer to that purpose. This patch is tested (tried to compile
> >> the release under the newly built kernel) and was made against 6.2-release.
> >>
> >> I attach the patch and the dmesg-output of the Mac mini running with the
> >> patched kernel.
> >>
> >> Can you merge it in -current?
> >>
> >> --- 6.2/src/sys/dev/acpi/dsdt.c Sun May 28 17:36:45 2017
> >> +++ src/sys/dev/acpi/dsdt.c Mon Oct 30 16:08:39 2017
> >> @@ -2488,6 +2488,11 @@
> >> aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
> >> val, mode, fld->v_field.flags);
> >> break;
> >> + case ACPI_OPREG_CMOS:
> >> + printf("RegionSpace: %u\n",
> >> ref1->v_opregion.iospace);
> >> + aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
> >> + val, mode, fld->v_field.flags);
> >> + break;
> >> default:
> >> aml_die("Unsupported RegionSpace 0x%x",
> >> ref1->v_opregion.iospace);
> >>
> >> PS: I still fail to build the full release and, thus, also the
> >> install62.fs image I want to use for installation. So it would be great
> >> if you consider fixing the issue soon.
> >>
> >> Best wishes, *Kristian
> >>
>
Add support for Mac mini 2014
Hi all,
So, I'm taking this to openbsd-misc and kindly ask who wants to help
with getting OpenBSD to run (again) on a Mac mini (latest intel model)?
As my knowledge of programming gasio code is limited, I would need help
to implement that what Mike suggested.
Otherwise, I guess, it's time for me to move on after 10 years macppc or so.
Best wishes, *Kristian
On 30.10.17 21:27 , Mike Larkin wrote:
>
> I don't think this is right. It may be "solving" your problem but our rwgas
> implementation doesn't handle this type of OpRegion. So, at best, we're
> ignoring
> the request (with the changes above), or worse, perhaps trashing some memory.
>
> Someone needs to add the I/O for this type of region (CMOS NVRAM) to
> the gasio code in acpi.c. There is a sequence of IN/OUT instructions that
> need to
> occur (in a proper order, with correct locking because the OS is using the
> device also) to get at those NVRAM registers. It probably isn't a huge amount
> of work, but nobody has stepped up to do it yet.
>
> If you want a workaround, you might try just ignoring ACPI_OPREG_CMOS locally
> in your tree. That too isn't right but at least it won't be possibly causing
> side effects/damage elsewhere.
>
> -ml
>
> On Mon, Oct 30, 2017 at 06:31:19PM +0100, Kristian Peters wrote:
>> Hi,
>>
>> As I thought, a simple addition to acpi/dsdt.c and the Mac mini is able
>> to boot. I used the external hard drive from a fresh 6.2-install on
>> another computer to that purpose. This patch is tested (tried to compile
>> the release under the newly built kernel) and was made against 6.2-release.
>>
>> I attach the patch and the dmesg-output of the Mac mini running with the
>> patched kernel.
>>
>> Can you merge it in -current?
>>
>> --- 6.2/src/sys/dev/acpi/dsdt.c Sun May 28 17:36:45 2017
>> +++ src/sys/dev/acpi/dsdt.c Mon Oct 30 16:08:39 2017
>> @@ -2488,6 +2488,11 @@
>> aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
>> val, mode, fld->v_field.flags);
>> break;
>> + case ACPI_OPREG_CMOS:
>> + printf("RegionSpace: %u\n",
>> ref1->v_opregion.iospace);
>> + aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
>> + val, mode, fld->v_field.flags);
>> + break;
>> default:
>> aml_die("Unsupported RegionSpace 0x%x",
>> ref1->v_opregion.iospace);
>>
>> PS: I still fail to build the full release and, thus, also the
>> install62.fs image I want to use for installation. So it would be great
>> if you consider fixing the issue soon.
>>
>> Best wishes, *Kristian
>>
