Re: disk i/o test
> On Mar 7, 2022, at 12:10 PM, Brian Brombacher wrote: > > Hi Mihai, > > Not exactly related to disk speed, but have you cranked up the following > sysctl to see if it helps? > > sysctl kern.bufcachepercentage=9 > > I put an entry in /etc/sysctl.conf for persistence. > > This will cause up to 90% of system memory to be used as a unified buffer > cache for disk access. Not sure if that helps but I use that value on every > install, including desktop and servers. I can’t remember if the default > value has changed in the past 10 years but I always go with 90%. I was helped off-list with this information, there is a memory threshold on amd64 that affects the behavior of the sysctl. If you have more than 4 gb of memory, the sysctl isn’t important. > > -Brian > >>> On Mar 7, 2022, at 6:17 AM, Mihai Popescu wrote: >>> >>> On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson wrote: >>> >>> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu : Since this thread is moving slowly in another direction, let me >>> >>> True >>> reiterate my situation again: I am running a browser (mostly chromium) and the computer slows down on downloads. Since I've checked the downloads rates, I observed they are slow than my maximum 500Mbps for the line. I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the Chromium has 30 seconds delays in everything i do. >>> >>> I would make sure it is not some kind of DNS thing, 30 second delays >>> sounds A LOT >>> like trying a "dead" resolver 3 times with 10 secs in between, before >>> moving to a "working" one. >> >> By "delay" I mean the time passed from clicking on some Chromium menu >> and the actual display of that menu. Even using a tty is slow, login >> . password in that disk intense usage period. >> Tried Debian and FreeBSD, all are able to write disk and do graphics. >> That ZFS on FreeBSD is mind blowing, I hope it's reliable too. >> >> All I wanted was to compare my hardware and disk speeds with someone >> running OpenBSD: simple dmesg <-> speed report match, but I think I >> hit a taboo again. >> Found some discussions on misc@ about that, no clear answer. I think I >> will close this thread and see what this ZFS is about :-) . >> >> Thank you all. >>> >>> -- >>> May the most significant bit of your life be positive. >> >
Re: disk i/o test
Correction: kern.bufcachepercentage=90 > On Mar 7, 2022, at 12:07 PM, Brian Brombacher wrote: > > Hi Mihai, > > Not exactly related to disk speed, but have you cranked up the following > sysctl to see if it helps? > > sysctl kern.bufcachepercentage=9 > > I put an entry in /etc/sysctl.conf for persistence. > > This will cause up to 90% of system memory to be used as a unified buffer > cache for disk access. Not sure if that helps but I use that value on every > install, including desktop and servers. I can’t remember if the default > value has changed in the past 10 years but I always go with 90%. > > -Brian > >>> On Mar 7, 2022, at 6:17 AM, Mihai Popescu wrote: >>> >>> On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson wrote: >>> >>> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu : Since this thread is moving slowly in another direction, let me >>> >>> True >>> reiterate my situation again: I am running a browser (mostly chromium) and the computer slows down on downloads. Since I've checked the downloads rates, I observed they are slow than my maximum 500Mbps for the line. I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the Chromium has 30 seconds delays in everything i do. >>> >>> I would make sure it is not some kind of DNS thing, 30 second delays >>> sounds A LOT >>> like trying a "dead" resolver 3 times with 10 secs in between, before >>> moving to a "working" one. >> >> By "delay" I mean the time passed from clicking on some Chromium menu >> and the actual display of that menu. Even using a tty is slow, login >> . password in that disk intense usage period. >> Tried Debian and FreeBSD, all are able to write disk and do graphics. >> That ZFS on FreeBSD is mind blowing, I hope it's reliable too. >> >> All I wanted was to compare my hardware and disk speeds with someone >> running OpenBSD: simple dmesg <-> speed report match, but I think I >> hit a taboo again. >> Found some discussions on misc@ about that, no clear answer. I think I >> will close this thread and see what this ZFS is about :-) . >> >> Thank you all. >>> >>> -- >>> May the most significant bit of your life be positive. >>
Re: disk i/o test
Hi Mihai, Not exactly related to disk speed, but have you cranked up the following sysctl to see if it helps? sysctl kern.bufcachepercentage=9 I put an entry in /etc/sysctl.conf for persistence. This will cause up to 90% of system memory to be used as a unified buffer cache for disk access. Not sure if that helps but I use that value on every install, including desktop and servers. I can’t remember if the default value has changed in the past 10 years but I always go with 90%. -Brian > On Mar 7, 2022, at 6:17 AM, Mihai Popescu wrote: > > On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson wrote: >> >> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu : >>> >>> Since this thread is moving slowly in another direction, let me >> >> True >> >>> reiterate my situation again: I am running a browser (mostly chromium) >>> and the computer slows down on downloads. Since I've checked the >>> downloads rates, I observed they are slow than my maximum 500Mbps for >>> the line. >>> I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the >>> Chromium has 30 seconds delays in everything i do. >> >> I would make sure it is not some kind of DNS thing, 30 second delays >> sounds A LOT >> like trying a "dead" resolver 3 times with 10 secs in between, before >> moving to a "working" one. > > By "delay" I mean the time passed from clicking on some Chromium menu > and the actual display of that menu. Even using a tty is slow, login > . password in that disk intense usage period. > Tried Debian and FreeBSD, all are able to write disk and do graphics. > That ZFS on FreeBSD is mind blowing, I hope it's reliable too. > > All I wanted was to compare my hardware and disk speeds with someone > running OpenBSD: simple dmesg <-> speed report match, but I think I > hit a taboo again. > Found some discussions on misc@ about that, no clear answer. I think I > will close this thread and see what this ZFS is about :-) . > > Thank you all. >> >> -- >> May the most significant bit of your life be positive. >
Re: disk i/o test
On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson wrote: > > Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu : > > > > Since this thread is moving slowly in another direction, let me > > True > > > reiterate my situation again: I am running a browser (mostly chromium) > > and the computer slows down on downloads. Since I've checked the > > downloads rates, I observed they are slow than my maximum 500Mbps for > > the line. > > I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the > > Chromium has 30 seconds delays in everything i do. > > I would make sure it is not some kind of DNS thing, 30 second delays > sounds A LOT > like trying a "dead" resolver 3 times with 10 secs in between, before > moving to a "working" one. By "delay" I mean the time passed from clicking on some Chromium menu and the actual display of that menu. Even using a tty is slow, login . password in that disk intense usage period. Tried Debian and FreeBSD, all are able to write disk and do graphics. That ZFS on FreeBSD is mind blowing, I hope it's reliable too. All I wanted was to compare my hardware and disk speeds with someone running OpenBSD: simple dmesg <-> speed report match, but I think I hit a taboo again. Found some discussions on misc@ about that, no clear answer. I think I will close this thread and see what this ZFS is about :-) . Thank you all. > > -- > May the most significant bit of your life be positive.
Re: disk i/o test
Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu : > > Since this thread is moving slowly in another direction, let me True > reiterate my situation again: I am running a browser (mostly chromium) > and the computer slows down on downloads. Since I've checked the > downloads rates, I observed they are slow than my maximum 500Mbps for > the line. > I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the > Chromium has 30 seconds delays in everything i do. I would make sure it is not some kind of DNS thing, 30 second delays sounds A LOT like trying a "dead" resolver 3 times with 10 secs in between, before moving to a "working" one. -- May the most significant bit of your life be positive.
Re: disk i/o test
> On Mar 6, 2022, at 7:41 AM, Mihai Popescu wrote: > > Since this thread is moving slowly in another direction, let me > reiterate my situation again: I am running a browser (mostly chromium) > and the computer slows down on downloads. Since I've checked the > downloads rates, I observed they are slow than my maximum 500Mbps for > the line. > I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the > Chromium has 30 seconds delays in everything i do. > > As a suggestion from Stuart, I was trying to separate tests for > downloading and disk write. The disk looks slow. Is the disk brand new? If I missed this somewhere, apologies. If it’s not new, how confident are you that the region of disk where chromium is writing data to disk has not suffered from any reallocations at the physical layer? I find read and write performance to spinning disks is highly regulated by physical layout more than anything else. For linear access, of course. Getting 41 MB/sec on an old disk depending on the region you are accessing is not out of my expectations, if the disk has reallocations in the region accessed. Reallocations occur when the physical media is no longer usable within thresholds so a new sector/area is allocated elsewhere on the disk and mapped. This causes seeks for what you consider a linear access. The hardware does this for you and you can’t stop it nor should you want to. Solution: Get SSD’s. > I tried both Debian 11 and Ubuntu and the download and disk write > jumps to 500Mbps without problems. And no, I cannot tolerate Linux > enough to use it as a daily OS, so don't bother to recommend it. I > cannot attain this in OpenBSD. Maybe that is the maximum possible for > my hardware. Just asking, for the moment i can live with this delays. > I was curious if someone with similar hardware can do better. > > OpenBSD 7.1-beta (GENERIC.MP) #401: Thu Mar 3 12:48:28 MST 2022 >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 7711543296 (7354MB) > avail mem = 7460630528 (7115MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries) > bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018 > bios0: Hewlett-Packard HP Compaq Pro 6305 SFF > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT > acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4) > PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3) > EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.47 MHz, 15-10-01 > 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB > cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
Re: disk i/o test
Since this thread is moving slowly in another direction, let me reiterate my situation again: I am running a browser (mostly chromium) and the computer slows down on downloads. Since I've checked the downloads rates, I observed they are slow than my maximum 500Mbps for the line. I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the Chromium has 30 seconds delays in everything i do. As a suggestion from Stuart, I was trying to separate tests for downloading and disk write. The disk looks slow. I tried both Debian 11 and Ubuntu and the download and disk write jumps to 500Mbps without problems. And no, I cannot tolerate Linux enough to use it as a daily OS, so don't bother to recommend it. I cannot attain this in OpenBSD. Maybe that is the maximum possible for my hardware. Just asking, for the moment i can live with this delays. I was curious if someone with similar hardware can do better. OpenBSD 7.1-beta (GENERIC.MP) #401: Thu Mar 3 12:48:28 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7711543296 (7354MB) avail mem = 7460630528 (7115MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries) bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018 bios0: Hewlett-Packard HP Compaq Pro 6305 SFF acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4) PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.47 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: disabling user TSC (skew=206) cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins acpimcfg0 a
Re: disk i/o test
On 2022-03-06, Alceu Rodrigues de Freitas Junior wrote: > > > Em 05/03/2022 15:29, Janne Johansson escreveu: > >> It can work the other way around also, using free RAM on the >> hypervisor to create >> a larger write cache than the VM itself can have. > > That would improve performance, but at the cost of losing data. > > Not sure if already suggested, but depending on the nature of data (ETL, > for example, would be acceptable), using MFS as file system would have > much better performance. Don't over-estimate the capabilities of MFS, it is not particularly fast. Ignoring VM (and I don't know how things behave there) but on physical hardware I often see faster writes to even just plain SATA SSDs than to MFS. -- Please keep replies on the mailing list.
Re: disk i/o test
> > Besides this, are my values too low or just the expected ones? > > It seems the throughput is bad. The small IO test showed good numbers > for iops, but the second test (and I guess other people's suggestion > to try dd from /dev/zero) will show that you seem to have a "thin > wire" from the drive to the computer, it seeks fast but transfers data > slowly. > Well, i dit the dd stuff and post result before, but i think it is still low for expectations. This is the second AMD based computer with "transfer" problems and no clear explanation. Could be the hardware, could be the driver, i really cannot figure out. I think i will jump in Intel's boat next time, I know there are some problems too, but at least their CPU are the most used and maybe have fixes. Thank you for your time.
Re: disk i/o test
Den tors 3 mars 2022 kl 18:10 skrev Mihai Popescu : > > > https://openports.pl/path/benchmarks/fio > > To test perf on many small IO (measuring iops basically) run: > > > > fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g > > --iodepth=16 --runtime=60 --time_based --end_fsync=1 > > Run status group 0 (all jobs): > WRITE: bw=12.5MiB/s (13.1MB/s), 6370KiB/s-6438KiB/s > (6523kB/s-6592kB/s), io=754MiB (791MB), run=60305-60305msec > > > > To test large-IO perf: > > > > fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g > > --iodepth=1 --runtime=60 --time_based --end_fsync=1 > WRITE: bw=18.9MiB/s (19.8MB/s), 18.9MiB/s-18.9MiB/s > (19.8MB/s-19.8MB/s), io=1138MiB (1193MB), run=60364-60364msec > > > > > Look for the result in the post-run report, > > for small IO it can be > > write: IOPS=37.8k, BW=148MiB/s (155MB/s) > > and for larger writes > > write: IOPS=253, BW=253MiB/s (266MB/s) > > > > Not really like your report, did you run it on another OS or cited from > memory? No, ran it on an openbsd VM. Still, there would have been absolutely zero chance that my random setup would match yours exactly so it was not meant as a measuring stick on what is everyones acceptable level, only how to interpret differences between large IO throughput and small IO latency/iops values. > Besides this, are my values too low or just the expected ones? It seems the throughput is bad. The small IO test showed good numbers for iops, but the second test (and I guess other people's suggestion to try dd from /dev/zero) will show that you seem to have a "thin wire" from the drive to the computer, it seeks fast but transfers data slowly. You might want to test the large IO test again with iodepth 1 and only one thread just to see if it is caused by the drive jumping between serving data from different places, so asking for a single stream might give you the "optimal" transfer speed for a non-busy drive. The numbers you did get were somewhat like when I bought an IDE->CompactFlash adapter for my firewalls. The CF disk had "zero" seek times which is good for cvs updates and so on, but still a low ovreall transfer speed since CFs were just not anything like modern ssd/nvme flash drives. Also, IDE being what it is puts limits on concurrency when it comes to IO. -- May the most significant bit of your life be positive.
Re: disk i/o test
On Mar 03 10:11:07, n...@holland-consulting.net wrote: > noatime is a nice little kick with seemingly > zero consequences (it does defeat a standard Unix file system feature, > but I've not come across anything that uses file access time stamps). I remember some shells reporting "new mail" based on the atime of /var/mail/$USER
Re: disk i/o test
> https://openports.pl/path/benchmarks/fio > To test perf on many small IO (measuring iops basically) run: > > fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g > --iodepth=16 --runtime=60 --time_based --end_fsync=1 fio-3.26 Starting 2 threads Jobs: 2 (f=2): [F(2)][100.0%][w=6502KiB/s][w=1625 IOPS][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=96172096: Thu Mar 3 19:01:51 2022 write: IOPS=1592, BW=6370KiB/s (6523kB/s)(375MiB/60305msec); 0 zone resets clat (usec): min=3, max=531908, avg=622.66, stdev=11014.61 lat (usec): min=4, max=531908, avg=623.30, stdev=11014.61 clat percentiles (usec): | 1.00th=[ 5], 5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 6], | 30.00th=[ 6], 40.00th=[ 7], 50.00th=[ 7], 60.00th=[ 7], | 70.00th=[ 7], 80.00th=[10], 90.00th=[ 101], 95.00th=[ 111], | 99.00th=[ 127], 99.50th=[ 141], 99.90th=[221250], 99.95th=[240124], | 99.99th=[270533] bw ( KiB/s): min= 1783, max=17482, per=50.07%, avg=6413.82, stdev=3737.49, samples=119 iops: min= 445, max= 4370, avg=1603.28, stdev=934.38, samples=119 lat (usec) : 4=0.07%, 10=80.84%, 20=3.70%, 50=0.48%, 100=4.84% lat (usec) : 250=9.71% lat (msec) : 50=0.01%, 100=0.11%, 250=0.22%, 500=0.03%, 750=0.01% cpu : usr=0.38%, sys=3.18%, ctx=352, majf=0, minf=3 IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,96040,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=16 random-write: (groupid=0, jobs=1): err= 0: pid=-1958487488: Thu Mar 3 19:01:51 2022 write: IOPS=1609, BW=6438KiB/s (6592kB/s)(379MiB/60305msec); 0 zone resets clat (usec): min=3, max=531873, avg=616.18, stdev=10954.39 lat (usec): min=4, max=531873, avg=616.80, stdev=10954.38 clat percentiles (usec): | 1.00th=[ 5], 5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 6], | 30.00th=[ 6], 40.00th=[ 7], 50.00th=[ 7], 60.00th=[ 7], | 70.00th=[ 9], 80.00th=[56], 90.00th=[60], 95.00th=[64], | 99.00th=[ 120], 99.50th=[ 130], 99.90th=[221250], 99.95th=[240124], | 99.99th=[267387] bw ( KiB/s): min= 1791, max=17603, per=50.60%, avg=6481.80, stdev=3808.08, samples=119 iops: min= 447, max= 4400, avg=1620.29, stdev=952.06, samples=119 lat (usec) : 4=0.23%, 10=74.48%, 20=1.27%, 50=0.54%, 100=21.89% lat (usec) : 250=1.24% lat (msec) : 50=0.01%, 100=0.10%, 250=0.22%, 500=0.03%, 750=0.01% cpu : usr=0.25%, sys=3.15%, ctx=351, majf=0, minf=3 IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,97056,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=16 Run status group 0 (all jobs): WRITE: bw=12.5MiB/s (13.1MB/s), 6370KiB/s-6438KiB/s (6523kB/s-6592kB/s), io=754MiB (791MB), run=60305-60305msec > > To test large-IO perf: > > fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g > --iodepth=1 --runtime=60 --time_based --end_fsync=1 fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. random-write: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1 fio-3.26 Starting 1 thread Jobs: 1 (f=1): [W(1)][100.0%][w=9124KiB/s][w=8 IOPS][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=-1257487296: Thu Mar 3 19:06:55 2022 write: IOPS=18, BW=18.9MiB/s (19.8MB/s)(1138MiB/60364msec); 0 zone resets clat (usec): min=676, max=365152, avg=52717.28, stdev=77225.34 lat (usec): min=723, max=365213, avg=52776.70, stdev=77225.59 clat percentiles (usec): | 1.00th=[ 701], 5.00th=[ 1745], 10.00th=[ 1926], 20.00th=[ 1975], | 30.00th=[ 2040], 40.00th=[ 2180], 50.00th=[ 2343], 60.00th=[ 48497], | 70.00th=[ 51643], 80.00th=[ 64750], 90.00th=[206570], 95.00th=[231736], | 99.00th=[267387], 99.50th=[299893], 99.90th=[350225], 99.95th=[367002], | 99.99th=[367002] bw ( KiB/s): min= 4096, max=44259, per=100.00%, avg=19452.77, stdev=13520.95, samples=118 iops: min=4, max= 43, avg=18.68, stdev=13.28, samples=118 lat (usec) : 750=4.04%, 1000=0.09% lat (msec) : 2=20.65%, 4=28.65%, 20=0.09%, 50=13.80%, 100=16.08% lat (msec) : 250=14.41%, 500=2.20% cpu : usr=0.10%, sys=3.59%, ctx=542, majf=0, minf=3 IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%,
Re: disk i/o test
On Thu, Mar 3, 2022 at 3:08 PM Jan Klemkow wrote: > > On Thu, Mar 03, 2022 at 02:59:33PM +0200, Mihai Popescu wrote: > > 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk > > (i.e. cp /dev/null )? > > /dev/null will act as an empty file. you have to use /dev/zero. > > i do my test with this command: > > dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync $ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync 10240+0 records in 10240+0 records out 10737418240 bytes transferred in 260.289 secs (41251827 bytes/sec) 4m20.32s real 0m00.01s user 0m17.70s system Is it too low? Is it expected? More info are here: https://marc.info/?l=openbsd-misc&m=164548029214340&w=2
Re: disk i/o test
On 2022-03-03, Nick Holland wrote: > You mention "legacy" options in the BIOS, you may be running an old > machine. But also look at softdep and noatime mount options, softdep > is a HUGE performance gain, noatime is a nice little kick with seemingly softdep can help if you are working on larger numbers of files but won't help for, say, writes to one big file. (but it can also turn some io errors, which the machine might possibly otherwise recover from, into hard crashes) the effect is usually quite a lot smaller on SSDs.
Re: disk i/o test
On Thu, Mar 3, 2022 at 10:13 AM Nick Holland wrote: > You mention "legacy" options in the BIOS, you may be running an old > machine. But also look at softdep and noatime mount options, softdep > is a HUGE performance gain, noatime is a nice little kick with seemingly > zero consequences (it does defeat a standard Unix file system feature, > but I've not come across anything that uses file access time stamps). Forensics (mostly useful on production machines with well understood use patterns and software -- atime is rarely useful even there, but that's true of most forensic issues and tools). -- Raul
Re: disk i/o test
On 3/3/22 7:59 AM, Mihai Popescu wrote: Hello, I am trying to test some disk i/o speeds and I am stumbled on two questions: 1. Does it matter if I set in BIOS Legacy or AHCI for the drive, regarding the read/write performance? anywhere between "big difference" and "OH WOW, I CAN'T BELIEVE THEY EVEN PROVIDE THIS LEGACY OPTION!". Really, you don't want to use "legacy". Cool thing, you can ignore the BIOS warnings about changing the setting and being no longer able to boot, OpenBSD handles that well. 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk (i.e. cp /dev/null )? really, your best benchmark is your work you need to do. But if you are looking for repeatable benchmarks, dd'ing FROM /dev/zero or TO /dev/null is a starting point (use a larger block size than the default -- "bs=1m" gives you easy to read info info out of "pkill -info dd", but also consider untaring ports.tar.gz or src.tar.gz. I am on snapshots for amd64 and I think i have a really slow writing to disk on OpenBSD only. You mention "legacy" options in the BIOS, you may be running an old machine. But also look at softdep and noatime mount options, softdep is a HUGE performance gain, noatime is a nice little kick with seemingly zero consequences (it does defeat a standard Unix file system feature, but I've not come across anything that uses file access time stamps). Nick.
Re: disk i/o test
Den tors 3 mars 2022 kl 14:02 skrev Mihai Popescu : > I am trying to test some disk i/o speeds and I am stumbled on two questions: > 1. Does it matter if I set in BIOS Legacy or AHCI for the drive, > regarding the read/write performance? Probably yes. AHCI will be better if it works. > 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk > (i.e. cp /dev/null )? > https://openports.pl/path/benchmarks/fio To test perf on many small IO (measuring iops basically) run: fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g --iodepth=16 --runtime=60 --time_based --end_fsync=1 To test large-IO perf: fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g --iodepth=1 --runtime=60 --time_based --end_fsync=1 Look for the result in the post-run report, for small IO it can be write: IOPS=37.8k, BW=148MiB/s (155MB/s) and for larger writes write: IOPS=253, BW=253MiB/s (266MB/s) > I am on snapshots for amd64 and I think i have a really slow writing > to disk on OpenBSD only. Might be worth testing mount flags like softdep or (shudder) async if the data is backed up and not very important. -- May the most significant bit of your life be positive.
disk i/o test
Hello, I am trying to test some disk i/o speeds and I am stumbled on two questions: 1. Does it matter if I set in BIOS Legacy or AHCI for the drive, regarding the read/write performance? 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk (i.e. cp /dev/null )? I am on snapshots for amd64 and I think i have a really slow writing to disk on OpenBSD only. Thank you.
