Re: OpenBSD's extremely poor network/disk performance?
And you link a report from 2018 in 2020, currently we are at OpenBSD 6.6. Maybe instead of spamming stupidity on the mailing list do the benchmarks yourself with current systems on the same hardware and publish those results. I personally don't have any issues with OpenBSD being drastically slower for some tasks than Linux, except MySQL server, so I run that on netbsd and problem is solved. ‐‐‐ Original Message ‐‐‐ On Tuesday, January 7, 2020 3:47 PM, wrote: > Hamd writes: > > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > ... lists full of the uninteresting type of wine and that their > > twitterings -still- don't include any code. > > Yes. Yes it is. > > Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour. > > Matthew
Re: OpenBSD's extremely poor network/disk performance?
On 2020-01-30 10:57, Handreas wrote: > "Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour." > > Repeat it again? > https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt?_ga=2.120267019.2069438099.1580381821-1178380388.1580381821 syspatch rcctl restart smtpd Also, I have seen ~147 megabytes per second of data read from disk and from /dev/urandom without issue at almost any time!
Re: OpenBSD's extremely poor network/disk performance?
"Can't say much for the performance of a suite of servers which have all been taken down to handle the security threat du jour." Repeat it again? https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt?_ga=2.120267019.2069438099.1580381821-1178380388.1580381821 adresine sahip kullanıcı 7 Oca 2020 Sal, 17:48 tarihinde şunu yazdı: > Hamd writes: > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > ... lists full of the uninteresting type of wine and that their > > twitterings -still- don't include any code. > > Yes. Yes it is. > > Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour. > > Matthew > >
Re: OpenBSD's extremely poor network/disk performance
On Thu, Jan 9, 2020 at 3:25 PM Hamd wrote: > Joe, are you a joke? Please stop insulting me, this is not > my/your_personal_fancy_forum. > > This will be my last post here in misc. > > Default setups, no config. changes. > Just patches installed. > Same hardware. > > FreeBSD: > freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 > && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) > 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w > > Result: *854.79 MB/s disk speed* > > freebsd@test:~ # uname -a > FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 > > OpenBSD: > test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) > 0m12.32s real 0m00.13s user 0m01.28s system > > Result: *16.64 MB/s disk speed* > > test$ uname -a > OpenBSD test.local 6.6 GENERIC#3 amd64 > > This thread should have never gone beyond original malicious post. I am posting this just for the archiving purpose. 101.69 MB/s on the RAID1. 10 year old desktop hardware and slow plater datacenter HDDs. 8 GB of low quality consumer RAM. oko# bioctl softraid0 Volume Status Size Device softraid0 0 Online 2000396018176 sd3 RAID1 0 Online 2000396018176 0:0.0 noencl 1 Online 2000396018176 0:1.0 noencl oko# time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 2.013 secs (101690032 bytes/sec) 0m02.17s real 0m00.16s user 0m01.13s system oko# uname -a OpenBSD oko.int.bagdala2.net 6.6 GENERIC.MP#3 amd64 Small Office FreeBSD file server ZFS mirror 161.15 MB/s root@hera:/tmp # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT storage 3.62T 537G 3.10T- - 0%14% 1.00x ONLINE - zroot57.5G 9.20G 48.3G- -11%16% 1.00x ONLINE - root@hera:/tmp # cd /tmp root@hera:/tmp # uname -a FreeBSD hera.int.autonsys.com 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0: Tue Nov 12 08:59:04 UTC 2019 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@hera:/tmp # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 1.270828 secs (161154799 bytes/sec) 0.031u 1.468s 0:01.59 93.7% 26+171k 10+5io 0pf+0w Large file server 128 GB of RAM and 24 cores on ZFS mirror 542.8 MB/s root@uranus:/tmp # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.377304 secs (542797946 bytes/sec) 0.000u 0.930s 0:01.04 89.4% 15+169k 11+5io 0pf+0w The same file server raidz2 pool 643.36 MB/s root@uranus:/data0 # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.318328 secs (643361055 bytes/sec) 0.007u 0.812s 0:02.36 34.3% 16+173k 11+5io 0pf+0w My home DragonFly file server HAMMER 1 42.52 MB/s Intel(R) Celeron(R) CPU 1037U @ 1.80GHz 8 GB of lowest grade consumer RAM dfly# time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 4.816742 secs (42518366 bytes/sec) 0.021u 1.372s 0:05.22 26.6% 11+67k 0+6346io 0pf+0w dfly# uname -a DragonFly dfly.int.bagdala2.net 5.6-RELEASE DragonFly v5.6.2-RELEASE #26: Sun Aug 11 16:04:07 EDT 2019 r...@dfly.int.bagdala2.net:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 Here is your Linux Red Hat to be precies. Just look the spec of the machine. That is 764 GB of RAM and 88 cores. SGI XFS file system circa 1990s as Linux has no other usable file system. root@lov5$ free -h totalusedfree shared buff/cache available Mem: 754G286G411G1.5G 56G 464G Swap: 4.0G4.0G 19M root@lov5$ uname -a Linux lov5.int.autonlab.org 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 09:31:31 EDT 2019 x86_64 x86_64 x86_64 GNU/Linux root@lov5$ more /etc/redhat-release Springdale Linux release 7.7 (Verona) root@lov5$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes (205 MB) copied, 0.317884 s, 644 MB/s real0m2.232s user0m0.079s sys 0m0.279s Best, Predrag
Re: OpenBSD's extremely poor network/disk performance?
On 2020-01-09 06:22, Hamd wrote: Joe, are you a joke? Please stop insulting me, this is not my/your_personal_fancy_forum. This will be my last post here in misc. Default setups, no config. changes. Just patches installed. Same hardware. FreeBSD: freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w Result: *854.79 MB/s disk speed* freebsd@test:~ # uname -a FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 OpenBSD: test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) 0m12.32s real 0m00.13s user 0m01.28s system Result: *16.64 MB/s disk speed* [snip] probook$ dd if=/dev/zero of=test.tmp bs=4k count=5 && sync 5+0 records in 5+0 records out 20480 bytes transferred in 0.731 secs (280047607 bytes/sec) I'm getting well over 250MB/s on my laptop. Is your hard drive attached as an sd or wd device?
Re: OpenBSD's extremely poor network/disk performance?
On Thu, Jan 9, 2020 at 3:25 PM Hamd wrote: > Joe, are you a joke? Please stop insulting me, this is not > my/your_personal_fancy_forum. > > This will be my last post here in misc. > > Default setups, no config. changes. > Just patches installed. > Same hardware. > > FreeBSD: > freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 > && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) > 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w > > Result: *854.79 MB/s disk speed* > > freebsd@test:~ # uname -a > FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 > > OpenBSD: > test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) > 0m12.32s real 0m00.13s user 0m01.28s system > > Result: *16.64 MB/s disk speed* > > test$ uname -a > OpenBSD test.local 6.6 GENERIC#3 amd64 > > I have no idea what hw you are on, but on my apu2c4*: tugs$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5" 5+0 records in 5+0 records out 20480 bytes transferred in 1.495 secs (136960919 bytes/sec) 0m01.51s real 0m00.04s user 0m01.35s system tugs$ uname -a OpenBSD tugs.antarctica.no 6.6 GENERIC.MP#584 amd64 Seems pretty damn fast to me. *) https://pcengines.ch/apu2c4.htm
Re: OpenBSD's extremely poor network/disk performance?
On 1/9/20 4:37 PM, Karel Gardas wrote: On 1/9/20 3:22 PM, Hamd wrote: FreeBSD: freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w Result: *854.79 MB/s disk speed* I'm afraid a lot of those data are still in RAM waiting for fs sync. At least do sync which is whole sys sync and add time of it to to the time of dd. It'll still not be 100% accurate, but at least more realistic... Shit happen. Sorry I've overlooked && sync on another line. Default setup, does it mean ZFS or UFS? I don't remember the default option since I've installed 12.1 few weeks ago and has not paid attention. Looking forward to see your openbsd dmesg anyway.
Re: OpenBSD's extremely poor network/disk performance?
On 1/9/20 3:22 PM, Hamd wrote: FreeBSD: freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w Result: *854.79 MB/s disk speed* I'm afraid a lot of those data are still in RAM waiting for fs sync. At least do sync which is whole sys sync and add time of it to to the time of dd. It'll still not be 100% accurate, but at least more realistic... OpenBSD: test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) 0m12.32s real 0m00.13s user 0m01.28s system Result: *16.64 MB/s disk speed* test$ uname -a OpenBSD test.local 6.6 GENERIC#3 amd64 As someone already recommended you, you need to provide at least dmesg.
Re: OpenBSD's extremely poor network/disk performance?
On 17:22 Thu 09 Jan, Hamd wrote: > Joe, are you a joke? Please stop insulting me, this is not > my/your_personal_fancy_forum. > > This will be my last post here in misc. > > Default setups, no config. changes. > Just patches installed. > Same hardware. > > FreeBSD: > freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 > && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) > 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w > > Result: *854.79 MB/s disk speed* > > freebsd@test:~ # uname -a > FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 > > OpenBSD: > test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" > 5+0 records in > 5+0 records out > 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) > 0m12.32s real 0m00.13s user 0m01.28s system > > Result: *16.64 MB/s disk speed* > > test$ uname -a > OpenBSD test.local 6.6 GENERIC#3 amd64 > > You all guys, please don't get me wrong in any way, I truly adore > cleanness, stability and security of OpenBSD, huge efforts of all the dev > team is really, much appreciated! > > I agree when it comes to OpenBSD, of course, security comes FIRST. But in > 2020, a speed of 16 megabytes per second...hurts the users. A lot. > > I really wish I could do contribute the code somehow..*sighs > > Regards. Please, stop using dd as a benchmark. Use fio or similar programs.
Re: OpenBSD's extremely poor network/disk performance?
just out of curiosity: did you do the FreeBSD test on ZFS with compression enabled? Am 09.01.20 um 15:22 schrieb Hamd: Joe, are you a joke? Please stop insulting me, this is not my/your_personal_fancy_forum. This will be my last post here in misc. Default setups, no config. changes. Just patches installed. Same hardware. FreeBSD: freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w Result: *854.79 MB/s disk speed* freebsd@test:~ # uname -a FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 OpenBSD: test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) 0m12.32s real 0m00.13s user 0m01.28s system Result: *16.64 MB/s disk speed* test$ uname -a OpenBSD test.local 6.6 GENERIC#3 amd64 You all guys, please don't get me wrong in any way, I truly adore cleanness, stability and security of OpenBSD, huge efforts of all the dev team is really, much appreciated! I agree when it comes to OpenBSD, of course, security comes FIRST. But in 2020, a speed of 16 megabytes per second...hurts the users. A lot. I really wish I could do contribute the code somehow..*sighs Regards. Joe Greco , 8 Oca 2020 Çar, 18:29 tarihinde şunu yazdı: On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote: Under less than 24 hours, after my post, the misc has received 2 or 3 brand new questions/posts regarding slow*. Well, in the case of my issue, I am reasonably certain that this isn't an issue with LibreSSL. I raised it as an issue of simply not knowing how to get it to do what I need at the speeds it is clearly capable of, on i386. It works fine and at approximately OpenSSL speeds on amd64. The problem is, well, obviously not me, personally. I beg to differ. Your repurposing my question for your own ends in an attempt to categorize it as an general OpenBSD performance issue is, in my opinion, full of **it. This is not helpful to those of us who are asking legitimate questions of those who are more familiar with these projects. I know I've made a dumb mistake of some sort and I was hoping someone would point it out. If you do not like the product, don't use it. Or submit a patch to fix it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: OpenBSD's extremely poor network/disk performance?
Joe, are you a joke? Please stop insulting me, this is not my/your_personal_fancy_forum. This will be my last post here in misc. Default setups, no config. changes. Just patches installed. Same hardware. FreeBSD: freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 0.239590 secs (854792500 bytes/sec) 0.000u 0.195s 0:00.25 76.0% 22+198k 0+1568io 0pf+0w Result: *854.79 MB/s disk speed* freebsd@test:~ # uname -a FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 OpenBSD: test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=5 && sync" 5+0 records in 5+0 records out 20480 bytes transferred in 12.303 secs (16645247 bytes/sec) 0m12.32s real 0m00.13s user 0m01.28s system Result: *16.64 MB/s disk speed* test$ uname -a OpenBSD test.local 6.6 GENERIC#3 amd64 You all guys, please don't get me wrong in any way, I truly adore cleanness, stability and security of OpenBSD, huge efforts of all the dev team is really, much appreciated! I agree when it comes to OpenBSD, of course, security comes FIRST. But in 2020, a speed of 16 megabytes per second...hurts the users. A lot. I really wish I could do contribute the code somehow..*sighs Regards. Joe Greco , 8 Oca 2020 Çar, 18:29 tarihinde şunu yazdı: > On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote: > > Under less than 24 hours, after my post, the misc has received 2 or 3 > brand > > new questions/posts regarding slow*. > > Well, in the case of my issue, I am reasonably certain that this isn't > an issue with LibreSSL. I raised it as an issue of simply not knowing > how to get it to do what I need at the speeds it is clearly capable > of, on i386. It works fine and at approximately OpenSSL speeds on > amd64. > > > The problem is, well, obviously not me, personally. > > I beg to differ. > > Your repurposing my question for your own ends in an attempt to > categorize it as an general OpenBSD performance issue is, in my > opinion, full of **it. > > This is not helpful to those of us who are asking legitimate > questions of those who are more familiar with these projects. > I know I've made a dumb mistake of some sort and I was hoping > someone would point it out. > > If you do not like the product, don't use it. Or submit a patch > to fix it. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "The strain of anti-intellectualism has been a constant thread winding its > way > through our political and cultural life, nurtured by the false notion that > democracy means that 'my ignorance is just as good as your > knowledge.'"-Asimov >
Re: OpenBSD's extremely poor network/disk performance?
On Wed, 8 Jan 2020 17:57:37 +0300 Hamd wrote: > Under less than 24 hours, after my post, the misc has received 2 or 3 > brand new questions/posts regarding slow*. The problem is, well, > obviously not me, personally. > For the Dev Team (All of 'em. Volunteer, beer-teer, pay-teer ones): I > regretfully think, the time of changing that filesystem older than my > 2xgrandfather, has arrived. Just speaking anecdotally for myself: I've never noticed especially slow disk performance with OpenBSD. If OpenBSD's disk performance really is 5 or 10 times slower than Linux, perhaps in most situations disk caching makes the difference negligible. If you really want to see an OS with slow disks that dramatically slow down the whole system, get yourself a copy of OpenSolaris and load it on a PC. Very nice, very stable, but everything takes 4 times as long. SteveT Steve Litt January 2020 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
Hi Karel, Thanks, for the correction... I thought zfs was bigger than that ;) Thanks On Wednesday, 8 January 2020, Karel Gardas wrote: > > > On 1/8/20 12:44 PM, Tom Smyth wrote: > >> As far as im aware there are 2 concerns about ZFS, >> 1) its license is not BSD /ISC you can use it and make money and not be >> sued, >> but it is more restrictive than BSD / ISC >> > > Yes, CDDL seems to be a no go based on past CDDL discussion which is > available for example in Star & OpenBSD thread on @tech: > > https://marc.info/?l=openbsd-tech=110806948606417=2 > >> 2) then there is the Number of Lines of code, which I believe is far >> longer than >> the OpenBSD code base, who and what team would manage the >> introduction of that code >> and the risks that come with that large a code base. >> > > Need to correct you a bit: > > ZFS: ~110k lines > XFS: ~95k lines > Ext4: ~38k lines > > while OpenBSD src/sys alone: > ~3.7mil lines where majority is in dev. But if I subtract drm code which > is probably the biggest contribution in dev (~1.7 mil lines), then I still > get roughly 2 mil lines of code in sys -- which is just part of base. > > LInes counted by sloccount. > > -- Kindest regards, Tom Smyth.
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
On 1/8/20 12:44 PM, Tom Smyth wrote: As far as im aware there are 2 concerns about ZFS, 1) its license is not BSD /ISC you can use it and make money and not be sued, but it is more restrictive than BSD / ISC Yes, CDDL seems to be a no go based on past CDDL discussion which is available for example in Star & OpenBSD thread on @tech: https://marc.info/?l=openbsd-tech=110806948606417=2 2) then there is the Number of Lines of code, which I believe is far longer than the OpenBSD code base, who and what team would manage the introduction of that code and the risks that come with that large a code base. Need to correct you a bit: ZFS: ~110k lines XFS: ~95k lines Ext4: ~38k lines while OpenBSD src/sys alone: ~3.7mil lines where majority is in dev. But if I subtract drm code which is probably the biggest contribution in dev (~1.7 mil lines), then I still get roughly 2 mil lines of code in sys -- which is just part of base. LInes counted by sloccount.
Re: OpenBSD's extremely poor network/disk performance?
Sent: Tuesday, January 07, 2020 at 7:35 AM From: "Hamd" To: misc@openbsd.org Subject: OpenBSD's extremely poor network/disk performance? It's 2020 and it's -still- sad to see OpenBSD -still- has the lowest/poorest (general/overall) performance ever: https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 My reference is not -only- that url, of course. My reference is my OpenBSD, giving ~8 MB/s file transfer/network/disk speed. A Linux distro, on the same computer (dual boot), providing 89 MB/s speed. (Longest) sad story of the year: When it comes to OpenBSD; security - great! Performance - horrible! I truly wish it was much better.. -- I did a test using bonnie++ on my T420 ThinkPad. I have softdep inabled for my /Home filesystem Here are the results: Version 1.97 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP leo.cats.domain 8G 313 98 25039 5 7747 3 364 98 93950 31 86.6 10 Latency 49275us 315ms1024ms 58491us 76221us4459ms K/sec means KiloBytes/second. If am reading this correctly, it looks like reading at ~25 Mb/sec. Since it is sequential, it didn't use soft updates. My abbreviated dmesg: OpenBSD 6.6 (GENERIC.MP) #4: Wed Dec 18 06:44:06 MST 2019 clee...@leo.cats.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4156157952 (3963MB) avail mem = 4017496064 (3831MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.30 MHz, 06-2a-07 cpu0: 256KB 64b/line 8-way L2 cache 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.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz, 06-2a-07 cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: naa.5000c500441a1cbd sd0: 305245MB, 512 bytes/sector, 625142448 sectors >From man 8 mount: softdep(FFS only) Mount the file system using soft dependencies. Instead of metadata being written immediately, it is written in an ordered fashion to keep the on-disk state of the file system consistent. This results in significant speedups for file create/delete operations. This option is ignored when using the -u flag and a file system is already mounted read/write. Here is what my fstab looks like removed.b none swap sw removed.a / ffs rw 1 1 removed.k /home ffs rw,nodev,nosuid,softdep 1 2 removed.d /tmp ffs rw,nodev,nosuid,softdep 1 2 removed.f /usr ffs rw,nodev,softdep 1 2 removed.g /usr/X11R6 ffs rw,nodev,softdep 1 2 removed.h /usr/local ffs rw,wxallowed,nodev,softdep 1 2 removed.j /usr/obj ffs rw,nodev,nosuid,softdep 1 2 removed.i /usr/src ffs rw,nodev,nosuid,softdep 1 2 removed.e /var ffs rw,nodev,nosuid 1 2
Re: OpenBSD's extremely poor network/disk performance?
On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote: > Under less than 24 hours, after my post, the misc has received 2 or 3 brand > new questions/posts regarding slow*. Well, in the case of my issue, I am reasonably certain that this isn't an issue with LibreSSL. I raised it as an issue of simply not knowing how to get it to do what I need at the speeds it is clearly capable of, on i386. It works fine and at approximately OpenSSL speeds on amd64. > The problem is, well, obviously not me, personally. I beg to differ. Your repurposing my question for your own ends in an attempt to categorize it as an general OpenBSD performance issue is, in my opinion, full of **it. This is not helpful to those of us who are asking legitimate questions of those who are more familiar with these projects. I know I've made a dumb mistake of some sort and I was hoping someone would point it out. If you do not like the product, don't use it. Or submit a patch to fix it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: OpenBSD's extremely poor network/disk performance?
"4.) The code is right there, you are invited to improve the situation." Simple answer: I'm not a developer, I'm a user. A regular one. Under less than 24 hours, after my post, the misc has received 2 or 3 brand new questions/posts regarding slow*. The problem is, well, obviously not me, personally. For the Dev Team (All of 'em. Volunteer, beer-teer, pay-teer ones): I regretfully think, the time of changing that filesystem older than my 2xgrandfather, has arrived. Ciao a tutti. infoomatic , 7 Oca 2020 Sal, 18:31 tarihinde şunu yazdı: > 1.) OpenBSD never stated that ultimate performance is their goal, but > clean maintainable code is, and thus in case of a compromise the > developers will choose clean code over performance. > > 2.) to quote Breandan Gregg: "All benchmarks are wrong until proven > otherwise" > > 3.) It's 2020 and you quote a benchmark from 2018? > > 4.) The code is right there, you are invited to improve the situation. > > > Am 07.01.20 um 15:35 schrieb Hamd: > > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > lowest/poorest (general/overall) performance ever: > > https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 > > > > My reference is not -only- that url, of course. My reference is my > OpenBSD, > > giving ~8 MB/s file transfer/network/disk speed. > > > > A Linux distro, on the same computer (dual boot), providing 89 MB/s > speed. > > > > (Longest) sad story of the year: When it comes to OpenBSD; security - > > great! Performance - horrible! I truly wish it was much better.. > > > > No, I'm not a fan of Calomel. >
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
Howdy Stuart, On Wed, 8 Jan 2020 at 11:17, Stuart Longland wrote: > > On 8/1/20 1:25 am, Karel Gardas wrote: > > And yes, ffs performance sucks, but nor me nor you provide any diff to > > change that so we can just shut up and use what's available. > > Okay, question is if not ffs, then what? > > - Other BSDs have ZFS… is it viable to port that to OpenBSD? (Maybe > it's been done before? I didn't check.) As far as im aware there are 2 concerns about ZFS, 1) its license is not BSD /ISC you can use it and make money and not be sued, but it is more restrictive than BSD / ISC 2) then there is the Number of Lines of code, which I believe is far longer than the OpenBSD code base, who and what team would manage the introduction of that code and the risks that come with that large a code base. > - FreeBSD has UFS2, DragonFlyBSD has HAMMER… Could we borrow their code? > - If we could clean-room implement a BSD-licensed as a user I would say sweet... but someone more knowledgable / involved in the project would need to see a diff before a determination can be made. > EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be > interest in supporting that in OpenBSD? what is the story with the license? if the license is not ISC / BSD I dont think it would be in base.. as a user I would say more filessytems sweet... but someone more knowledgeable / involved in the project would need to see a diff before a determination can be made. > - Or do we implement yet another file system? (Seems like too much work > for not much gain IMO.) as an OpenBSD user I would say that the performance of Network is dependent on your hardware. / the specific hardware Driver compatibility /capability in OpenBSD, I have had a different performance experience depending on the hardware I was using, and the maturity of the Driver support for that hardware. I have found the em(4) supported nics are pretty good ix(4) has solid performance vmx(4) have been good but it is dependent on the Vmware version you are using , and then others like vio(4) interfaces I have not had as good a performance. but that is more due to the age of the drivers and their capability vs what newer virtio drivers can do. But as a number of members of the OpenBSD Project have said to me Diffs are welcome ... Good Diffs will be considered just bear in mind the the License Requirements and Coding Style KNF when submitting a diff and do it off current... > > Regards, > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > -- Kindest regards, Tom Smyth.
File systems [was Re: OpenBSD's extremely poor network/disk performance?]
On 8/1/20 1:25 am, Karel Gardas wrote: > And yes, ffs performance sucks, but nor me nor you provide any diff to > change that so we can just shut up and use what's available. Okay, question is if not ffs, then what? - Other BSDs have ZFS… is it viable to port that to OpenBSD? (Maybe it's been done before? I didn't check.) - FreeBSD has UFS2, DragonFlyBSD has HAMMER… Could we borrow their code? - If we could clean-room implement a BSD-licensed EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be interest in supporting that in OpenBSD? - Or do we implement yet another file system? (Seems like too much work for not much gain IMO.) There's merit in the third option, OpenBSD already supports EXT2 (which is also 90's vintage like ffs) as there are some platforms (e.g. loongson) that require it. I run BTRFS on a lot of my Linux machines, and aside from some features that are still experimental (quotas being one such issue), it seems to do the job. I've also been a big XFS user in the past. Performance seems good and XFS in particular has seen widespread production use, particularly in high-performance computing arenas. (SGI didn't exactly do things small!) EXT4 is also very widespread and stable, and seems to offer decent performance. ZFS and BTRFS are much newer, and more complicated with software RAID functionality built in. I think these would be harder to implement from scratch. DIY file systems doesn't seem like a good plan for success… it'll be a lot of work, won't be compatible with anything else, and could be as bad if not worse than what we have now, whilst also being untested. ffs is at least mature and stable! Are any of the "modern" file systems (from a design perspective, licensing is a different matter) suitable for use as OpenBSD's root fs? What would be needed? Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: OpenBSD's extremely poor network/disk performance?
There might be something wrong with your setup. I routinely get 500+ MB/s disk and full 1 GBit Ethernet. > On Jan 7, 2020, at 9:38 AM, Hamd wrote: > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > lowest/poorest (general/overall) performance ever: > https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 > > My reference is not -only- that url, of course. My reference is my OpenBSD, > giving ~8 MB/s file transfer/network/disk speed. > > A Linux distro, on the same computer (dual boot), providing 89 MB/s speed. > > (Longest) sad story of the year: When it comes to OpenBSD; security - > great! Performance - horrible! I truly wish it was much better.. > > No, I'm not a fan of Calomel.
LibreSSL performance issue (was: Re: OpenBSD's extremely poor network/disk performance?)
On Tue, Jan 07, 2020 at 09:33:46AM -0600, Edgar Pettijohn wrote: > > In reality, when you dig down, often you find that there's another > > reason for the issue.?? I was recently trying to substitute libressl > > into an openssl environment.?? Performance tanked.?? Some checking > > showed the speed of "speed -evp aes-256-gcm" was way off.?? It looked > > to me like it was an issue with not using AES-NI.?? I'm not going to > > blame libressl for that, I just lacked the time to do a deep dive on > > it to figure out what was (hopefully!) configured wrong.?? Probably > > something with ia32cap or whatever the libressl equivalent is. > > > > ... JG > > I believe it has something to do with actually zeroing out memory > before freeing it. Which seems like a good thing to do for crypto > stuff. My apologies. I posted an insufficient description of the issue as it was intended as an argument refuting the OP. If we want to discuss my issue, that's fine and I welcome the input. I normally manage to resolve these things eventually but this stumped me a bit. This appears to be an i386-specific issue and it is perhaps a 5:1 performance difference. Compiled on a FreeBSD 12.1R-amd64 VM, I see exactly what I would hope to see: --Begin-FreeBSD-12.1R-amd64 # uname -r; uname -m 12.1-RELEASE amd64 # libressl-3.0.2/apps/openssl/openssl speed -evp aes-256-gcm WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf Doing aes-256-gcm for 3s on 16 size blocks: 42776805 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 64 size blocks: 28274190 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 9382555 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 2636912 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 334132 aes-256-gcm's in 3.01s LibreSSL 3.0.2 built on: date not available options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-gcm 228204.73k 601456.74k 798353.68k 897432.60k 909765.10k # openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: 40297566 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 64 size blocks: 27287454 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 10106391 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 2858781 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 368695 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 16384 size blocks: 184909 aes-256-gcm's in 3.01s OpenSSL 1.1.1d-freebsd 10 Sep 2019 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-gcm 214362.12k 580620.32k 860172.00k 973262.71k 1006783.15k 1007226.70k --End-FreeBSD-12.1R-amd64 Okay, so that looks fantastic to me. Now running it on i386 on a VM "right next door" on the same hypervisor. --Begin-FreeBSD-12.1R-i386 # uname -r; uname -m 12.1-RELEASE i386 # libressl-3.0.2/apps/openssl/openssl speed -evp aes-256-gcm WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf Doing aes-256-gcm for 3s on 16 size blocks: 8904897 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 64 size blocks: 2387064 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 603284 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 153381 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 19041 aes-256-gcm's in 3.01s LibreSSL 3.0.2 built on: date not available options:bn(64,32) rc4(ptr,int) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(idx) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-gcm 47427.78k50805.69k51347.19k52207.47k51858.50k # openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: 32056370 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 64 size blocks: 21569563 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 8523369 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 2528081 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 334502 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 16384 size blocks: 167762 aes-256-gcm's in 3.02s OpenSSL 1.1.1d-freebsd 10 Sep 2019 built on: reproducible build, date unspecified options:bn(64,32) rc4(8x,mmx) des(long) aes(partial) idea(int) blowfish(ptr)
Re: OpenBSD's extremely poor network/disk performance?
On 1/7/20 3:35 PM, Hamd wrote: It's 2020 and it's -still- sad to see OpenBSD -still- has the lowest/poorest (general/overall) performance ever: https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 Read comments to the article, I already done mine: https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1058778-initial-benchmarks-of-openbsd-6-4-dragonflybsd-5-3-freebsd-vs-linux?p=1059046#post1059046
Re: OpenBSD's extremely poor network/disk performance?
On Jan 7, 2020 9:18 AM, Joe Greco wrote: > > On Tue, Jan 07, 2020 at 02:47:02PM +, cho...@jtan.com wrote: > > Hamd writes: > > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > > ... lists full of the uninteresting type of wine and that their > > > twitterings -still- don't include any code. > > > > Yes. Yes it is. > > > > Can't say much for the performance of a suite of servers which have > > all been taken down to handle the security threat du jour. > > Well, that's kind of ridiculous, that's not generally how threats are > remediated in the real world. > > If you take a server down for 15 minutes to apply patches to Insecure- > But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is > performing lots faster during that 99.85%, but admittedly performs at > zero during the patch process. Redundancy can cover that in many > cases. > > A different argument could be that if you require a particular level of > performance, and you have to deploy more compute resources to get it, > that increases capex and opex, and the end result is a greater level of > e-waste down the road, and perhaps a greater amount of pollution if the > power is generated from "bad" sources. > > In reality, when you dig down, often you find that there's another > reason for the issue. I was recently trying to substitute libressl > into an openssl environment. Performance tanked. Some checking > showed the speed of "speed -evp aes-256-gcm" was way off. It looked > to me like it was an issue with not using AES-NI. I'm not going to > blame libressl for that, I just lacked the time to do a deep dive on > it to figure out what was (hopefully!) configured wrong. Probably > something with ia32cap or whatever the libressl equivalent is. > > ... JG I believe it has something to do with actually zeroing out memory before freeing it. Which seems like a good thing to do for crypto stuff. Edgar > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "The strain of anti-intellectualism has been a constant thread winding its way > through our political and cultural life, nurtured by the false notion that > democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov >
Re: OpenBSD's extremely poor network/disk performance?
1.) OpenBSD never stated that ultimate performance is their goal, but clean maintainable code is, and thus in case of a compromise the developers will choose clean code over performance. 2.) to quote Breandan Gregg: "All benchmarks are wrong until proven otherwise" 3.) It's 2020 and you quote a benchmark from 2018? 4.) The code is right there, you are invited to improve the situation. Am 07.01.20 um 15:35 schrieb Hamd: It's 2020 and it's -still- sad to see OpenBSD -still- has the lowest/poorest (general/overall) performance ever: https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 My reference is not -only- that url, of course. My reference is my OpenBSD, giving ~8 MB/s file transfer/network/disk speed. A Linux distro, on the same computer (dual boot), providing 89 MB/s speed. (Longest) sad story of the year: When it comes to OpenBSD; security - great! Performance - horrible! I truly wish it was much better.. No, I'm not a fan of Calomel.
Re: OpenBSD's extremely poor network/disk performance?
It's 2020 and you are sending a link to article from 2018? Anyway, you (phoronix) compare '90 ffs technology with state of the art of current storage/fs in linuxes/bsd represented by XFS/Ext4 and ZFS filesystems and you compare with the winner right? Kind of unfair don't you think? And yes, ffs performance sucks, but nor me nor you provide any diff to change that so we can just shut up and use what's available. On 1/7/20 3:35 PM, Hamd wrote: It's 2020 and it's -still- sad to see OpenBSD -still- has the > lowest/poorest (general/overall) performance ever: > https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 > > > My reference is not -only- that url, of course. My reference is my OpenBSD, giving ~8 MB/s file transfer/network/disk speed. > > A Linux distro, on the same computer (dual boot), providing 89 MB/s > speed. > > (Longest) sad story of the year: When it comes to OpenBSD; security - > great! Performance - horrible! I truly wish it was much better.. > > No, I'm not a fan of Calomel.
Re: OpenBSD's extremely poor network/disk performance?
On Tue, Jan 07, 2020 at 05:35:13PM +0300, Hamd wrote: > It's 2020 and it's -still- sad to see OpenBSD -still- has the > lowest/poorest (general/overall) performance ever: Thank you for your kind and encouraging words. I will get right on fixing these issues for you. -- I'm not entirely sure you are real.
Re: OpenBSD's extremely poor network/disk performance?
2020-01-07 15:35 GMT+01:00, Hamd : > It's 2020 and it's -still- sad to see OpenBSD -still- has the > lowest/poorest (general/overall) performance ever: > https://www.phoronix.com/scan.php?page=article=8-linux-bsd=1 > > My reference is not -only- that url, of course. My reference is my OpenBSD, > giving ~8 MB/s file transfer/network/disk speed. Maybe if you post a dmesg output and a guide to reproduce it then the bottleneck can be identified and further steps can be taken. > > A Linux distro, on the same computer (dual boot), providing 89 MB/s speed. > > (Longest) sad story of the year: When it comes to OpenBSD; security - > great! Performance - horrible! I truly wish it was much better.. > > No, I'm not a fan of Calomel. >
Re: OpenBSD's extremely poor network/disk performance?
On Tue, Jan 07, 2020 at 02:47:02PM +, cho...@jtan.com wrote: > Hamd writes: > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > ... lists full of the uninteresting type of wine and that their > > twitterings -still- don't include any code. > > Yes. Yes it is. > > Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour. Well, that's kind of ridiculous, that's not generally how threats are remediated in the real world. If you take a server down for 15 minutes to apply patches to Insecure- But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is performing lots faster during that 99.85%, but admittedly performs at zero during the patch process. Redundancy can cover that in many cases. A different argument could be that if you require a particular level of performance, and you have to deploy more compute resources to get it, that increases capex and opex, and the end result is a greater level of e-waste down the road, and perhaps a greater amount of pollution if the power is generated from "bad" sources. In reality, when you dig down, often you find that there's another reason for the issue. I was recently trying to substitute libressl into an openssl environment. Performance tanked. Some checking showed the speed of "speed -evp aes-256-gcm" was way off. It looked to me like it was an issue with not using AES-NI. I'm not going to blame libressl for that, I just lacked the time to do a deep dive on it to figure out what was (hopefully!) configured wrong. Probably something with ia32cap or whatever the libressl equivalent is. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: OpenBSD's extremely poor network/disk performance?
Hamd writes: > It's 2020 and it's -still- sad to see OpenBSD -still- has the > ... lists full of the uninteresting type of wine and that their > twitterings -still- don't include any code. Yes. Yes it is. Can't say much for the performance of a suite of servers which have all been taken down to handle the security threat du jour. Matthew
