Re: OpenBSD and multitasking
Den tis 26 apr. 2022 kl 22:50 skrev Mihai Popescu : > $ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync > 10737418240 bytes transferred in 260.289 secs (41251827 bytes/sec) > $ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync > 10737418240 bytes transferred in 24.006 secs (447266094 bytes/sec) > > The test is done using a mechanical disk and a ssd one. I think the > dude telling that some entry level ssd have the same performance like > mechanical disks is the same with the one telling ssd will wear very > fast. My mistake to believe it without testing. Even if the best-case transfer speeds were the same, the zero seek times of ssds will make a huge difference when dealing with all other kinds of IO than "super large linear writes", which is basically 99.9% of all IO you do when using the computer. -- May the most significant bit of your life be positive.
Understanding pf statistics
In the following command, is "Packets" the number of dropped packets after 5,435,315 evaluations of that block rule? If so, is "Bytes" the total size of those 16,303 dropped packets? And is "States" zero because it is a block rule, thus no state created? # pfctl -s rules -vR11 block drop in log quick on egress from to any [Evaluations: 5435315 Packets: 16303 Bytes: 943433 States: 0] [Inserted: uid 0 pid 86885 State Creations: 0]
Re: Framework laptop fails to enter sleep/suspend/hibernate
Ah yes this kind of makes sense. I was planning on making some room on the nvme drive for OpenBSD eventually anyways. Thanks! On Mon., Apr. 25, 2022, 05:01 Dave Voutila, wrote: > > Andrew W writes: > > > Not sure what else to try but I can't seem to get sleep/suspend to work > on > > my frame.work laptop. I've tried OpenBSD 7.0 and 7.1 now, running off a > 1TB > > USB drive. > > S4/Hibernation is not supported when swap is on a USB disk. I haven't > read the suspend code paths lately, but I wouldn't be susprised if this > is a problem as well. > > > > > Running apm -S or apm -z the screen goes blank and the keyboard remains > > backlit, eventually the fan starts spinning faster. I need to long press > > the power button to force shutdown the machine. Hibernate says it's not > > supported, which is a bit less of a concern to me but having one of them > > working would be very helpful. > > > > I've tried w/o X running, same results. I don't see any failures related > to > > the TPM in dmesg but also I've tried w/ it set to "hidden" in the bios, > > same result. > > > > I'm new to OpenBSD so maybe I'm missing something important to get this > > working but I haven't seen much in the way of configuration related to > this > > functionality? > > Can you try with your root and swap partitions on your nvme disk and not > on USB? Barring that, capturing all your machine details with sendbug(1) > would be helpful. > > -dv >
Re: OpenBSD and multitasking
$ 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 $ 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 24.006 secs (447266094 bytes/sec) 0m24.00s real 0m00.02s user 0m18.24s system The test is done using a mechanical disk and a ssd one. I think the dude telling that some entry level ssd have the same performance like mechanical disks is the same with the one telling ssd will wear very fast. My mistake to believe it without testing. Thank you for your fault tolerance.
Re: OpenBSD and multitasking
This is just to confirm that both Chrome and Firefox perform _much_ better after I replaced a HDD with a SSD in a Thinkpad T410. On Apr 26 13:40:46, sh+openbsd-m...@codevoid.de wrote: > Mihai Popescu wrote (2022-04-26 01:13 CEST): > > I use OpenBSD amd64 snapshots on the following dmesg hardware. > > The download rate on a browser was slow and I figured out with some > > memory mapped partition that disk transfer rate was slow. > > I can bear this since I'm not into large file transfer business. But > > here is another interesting fact: each time my disk is used by some > > file transfer, all the running applications, mostly GUI based are > > stalling - that includes mostly chromium ( even if it is not chromium > > that it does the disk data transfer). > > > > My questions are: is something incorrectly set up on my computer, > > regarding the multitasking? > > I understand disk operations are slow, but may I say that kernel is > > dragged in that slow transfer too (no DMA, no cache, etc.)? > > Does this happens to all users, but since there are more powerful > > configuration involved the delay is not so noticeable? > > Mount your file systems with the softdep flag (described in mount(8)). > This should bring HDD i/o to what you're used to on other operating > systems. > > > I know it is hard to project this, but can someone give me a hint > > about a minimum hardware to allow using chromium with no delays, > > please? > > "No" delays? You need one of these https://www.oreillyauto.com/flux-capacitor > so you can jump over the delays. The good news is, that the slowness > of your machine wouldn't matter anymore. Unfortunately this would have > the side effect that the world around you ages faster. I'd suggest you > invest into real estate to make the skipped time worth more... but I'm > getting carried away... > > *scnr* > > > I know, it should be advisable to get the maximum performance > > hardware, but i'm not in that case. > > This is all very personal. I think chrome+openbsd runs well on 5 year > old hardware with an SSD. > > Best Regards, > Stefan > >
Re: Sysctl settings for transmission bittorrent (udp receive buffer size)
On Mon, Apr 25, 2022 at 07:47:37PM -, Stuart Henderson wrote: > On 2022-04-25, Daniel Schuermann wrote: > > I can't get transmission (bittorrent client) to work properly. > > > > From the logs: > > transmission-daemon: UDP Failed to set receive buffer: > > requested 4194304, got 41600 > > > > On Linux I would do: > > sysctl net.core.rmem_max=4194304 > > I couldn't figure out the correct settings for OpenBSD. > > > > net.inet.udp.recvspace sets the default, not the max buffer size, > > e.g. sysctl net.inet.udp.recvspace=4194304 causes errors: > > nslookup openbsd.org > > nslookup: isc_socket_create: not enough free resources > > That is the right sysctl, the alternative is to set per-socket with > setsockopt() (SO_SNDBUF, SO_RCVBUF). > > The max is 256K (262144). Looking through upstream's problem tracker, I see that this is a design requirement of uTP and that the message, while appearing to be an error, is informational; uTP will still operate. https://trac.transmissionbt.com/ticket/4321 https://trac.transmissionbt.com/ticket/5317
Re: OpenBSD and multitasking
On 2022-04-26, Mike Larkin wrote: > On Tue, Apr 26, 2022 at 02:13:16AM +0300, Mihai Popescu wrote: >> I can bear this since I'm not into large file transfer business. But >> here is another interesting fact: each time my disk is used by some >> file transfer, all the running applications, mostly GUI based are >> stalling - that includes mostly chromium ( even if it is not chromium >> that it does the disk data transfer). I have found MP performance to be poor when doing lots of disk io, in my case noticed when doing multithreaded searches (the_silver_searcher) over unpacked source from the whole ports tree, making the machine often respond poorly when it was running (including lack of response to keyboard/mouse). > See comments below. The hardware is ancient. I'd say try running > chrome on windows on this hardware and you'll probably see it's also > horrible. Chrome runs reasonably well on other OS including Windows on much worse machines than this. >> avail mem = 7460139008 (7114MB) >> cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.45 MHz, [...] not bad really >> cpu1: disabling user TSC (skew=129) >> cpu2: disabling user TSC (skew=186) this is not ideal if you have software calling gettimeofday a lot. browsers often do. >> sd0 at scsibus1 targ 0 lun 0: >> naa.5000c5006520feaf > > HDD, not SSD, and release date of this model is April 2011... Eleven years > ago. at least it's not SMR like many newer HDDs :) >From Mihai's description it really feels like it's disk io in particular that's causing the problem. Performance could well be better on OS with better developed SMP (I don't get the impression that disk io has really been a target area for our MP work). I am sure the #1 improvement will be replacing this with SSD, or adding SSD and moving those filesystems which see frequent access. (Even if the machine won't boot from NVMe directly, a cheap M.2 NVMe in a PCIe carrier card for /usr/local, /home, /tmp would have a good cost/benefit ratio). Alternatively this hardware will likely work better with another OS. Choice of OS is a trade-off.
