Re: socket cores
i Gustavo Rios [rios.gust...@gmail.com] wrote: > Hi folks! > > I have a simple question: how many cores does OBSD support ? > There's various hard-coded limits at something like 64-128 cores (depending on architecture) Depending on your application, a useful number of cores is somewhere between 4 and 16 right now, although a purely computational multi-thread/multi-process application could perhaps use much more. Applications that make heavy use of kernel services are all undergoing acceleration as the kernel unlocks and things are changed to take advantage of parallelization where this is possible. Here's a 16 core box doing NAT on 250kpps (250k in and out) with vlan tagging and if_ix multiqueue. One more interesting item here is that the majority of work is spread across four CPUs. It's running OpenBSD 7.4 (not current which is has a bit more unlocked.) The same config starts to putter around 800-900kpps in/out (increased latency) but doesn't drop traffic. load averages: 1.91, 2.11, 2.04test 18:33:34 35 processes: 34 idle, 1 on processorup 0 days 09:56:29 CPU00: 0.0% user, 0.0% nice, 0.0% sys, 0.4% spin, 4.8% intr, 94.8% idle CPU01: 0.0% user, 0.0% nice, 39.4% sys, 1.4% spin, 0.0% intr, 59.2% idle CPU02: 0.0% user, 0.0% nice, 36.8% sys, 0.4% spin, 1.0% intr, 61.8% idle CPU03: 0.0% user, 0.0% nice, 32.6% sys, 1.6% spin, 0.8% intr, 65.0% idle CPU04: 0.0% user, 0.0% nice, 23.6% sys, 0.6% spin, 0.8% intr, 75.0% idle CPU05: 0.0% user, 0.0% nice, 6.0% sys, 0.2% spin, 0.6% intr, 93.2% idle CPU06: 0.0% user, 0.0% nice, 0.2% sys, 0.2% spin, 1.4% intr, 98.2% idle CPU07: 0.0% user, 0.0% nice, 0.0% sys, 0.4% spin, 1.8% intr, 97.8% idle CPU08: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 1.8% intr, 98.2% idle CPU09: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 2.0% intr, 98.0% idle CPU10: 0.0% user, 0.0% nice, 0.0% sys, 0.2% spin, 1.8% intr, 98.0% idle CPU11: 0.0% user, 0.0% nice, 0.0% sys, 0.2% spin, 0.8% intr, 99.0% idle CPU12: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 1.4% intr, 98.6% idle CPU13: 0.0% user, 0.0% nice, 0.0% sys, 0.2% spin, 1.4% intr, 98.4% idle CPU14: 0.0% user, 0.0% nice, 0.0% sys, 0.2% spin, 1.0% intr, 98.8% idle CPU15: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 1.8% intr, 98.2% idle Memory: Real: 57M/M act/tot Free: 60G Cache: 815M Swap: 0K/2035M
Re: tmux: mouse works in st but not in xterm
Stuart Henderson wrote: > On 2024-02-01, Omar Polo wrote: > > On 2024/02/01 12:06:13 +0100, rsyk...@disroot.org wrote: > >> Dear list, > >> > >> > >> when I run tmux in xterm, the mouse support does not work. > > > > by default mouse support is disabled on xterm on OpenBSD. No clue why, > > as I think it's useful. The knob to enable it is > > > > XTerm*allowMouseOps: true > > > > which is documented in xterm. > > - > PatchSet 127 > Date: 2021/10/31 18:38:43 > Author: matthieu > Branch: HEAD > Tag: (none) > Log: > Disable mouse tracking by default. > > This causes extra control sequences to be sent to the shell when an > application that has it enabled crashes. Discussed with deraadt@ > > Members: > Makefile:1.36->1.37 > xterm.man:1.55->1.56 > > - thank you. I probably should have found it in the man page. I will reenable it hoping it will not cause me any harm. Best regards, Ruda
Re: tmux: mouse works in st but not in xterm
On 2024-02-01, Omar Polo wrote: > On 2024/02/01 12:06:13 +0100, rsyk...@disroot.org wrote: >> Dear list, >> >> >> when I run tmux in xterm, the mouse support does not work. > > by default mouse support is disabled on xterm on OpenBSD. No clue why, > as I think it's useful. The knob to enable it is > > XTerm*allowMouseOps: true > > which is documented in xterm. - PatchSet 127 Date: 2021/10/31 18:38:43 Author: matthieu Branch: HEAD Tag: (none) Log: Disable mouse tracking by default. This causes extra control sequences to be sent to the shell when an application that has it enabled crashes. Discussed with deraadt@ Members: Makefile:1.36->1.37 xterm.man:1.55->1.56 -
Re: SATA slow/timeouts, AMD 600 Series AHCI, OpenBSD 7.4 amd64
b...@po.cwru.edu writes: >> Divan Santana [20240131 165546 +0200]: >> >> b...@po.cwru.edu writes: >> >> > Onboard SATA seems to require additional initialization on a Gigabyte >> > B650 in OpenBSD 7.4 amd64; basic requests take minutes to complete and >> > each block read takes 30 seconds. During boot, attached SSDs will block >> > pending these requests; >> >> I have the same issue. I was hoping to install openbsd 7.4 on this new >> AMD MSI board server. >> >> This issue is quite a show stopper for me. >> >> If anyone wants some further input from me to debug this, let me know. >> >> @b...@po.cwru.edu is there any workaround? > The only user-land workaround I know is to suspend with `zzz -z`. After > resuming, the bus seems to be in a workable state. > > I've had great success with the noted kernel driver workaround, which > applies the reset during system startup. Optical drive performance has > been as expected with that workaround. OK, the zzz -z works well. After that the issue appears resolved. I just had to enable/start apmd. How can one apply your patch, so the issue is resolved on boot? Currently to boot the system takes REALLY long because of this issue and the 3 SATA drives I have in it. > Hopefully one of those will work for you, and if any OpenBSD developers > are listening, maybe one of them can see the "right" way to do this. Hope so :)
Re: tmux: mouse works in st but not in xterm
On 2024/02/01 12:06:13 +0100, rsyk...@disroot.org wrote: > Dear list, > > > when I run tmux in xterm, the mouse support does not work. by default mouse support is disabled on xterm on OpenBSD. No clue why, as I think it's useful. The knob to enable it is XTerm*allowMouseOps: true which is documented in xterm.
tmux: mouse works in st but not in xterm
Dear list, when I run tmux in xterm, the mouse support does not work. When I run tmux in the st terminal, mouse support is functional (e.g., I can resize the panes). Can somebody perhaps have a clue, what can be going on? On linux, there is no problem in xterm. I also renamed ~/.Xdefaults to get any settings there out of the game, tried to set TERM to the same value as st uses, but all to no avail. I do not know what to try next. Thanks! Ruda PS.: I do have set -g mouse on in ~/.tmux.conf; that's why mouse works in st.
