Re: LAN slow speed transfer

Hi, thank you Stu for the feedback. Turns out the problem was one of the cables. It is advertised as 5E, but maybe there is something fishy with it. Fact is, I bought another, changed it, and now I got something around 95 MBytes/s of LAN transfer rate. Best, Vitor Em qui., 2 de fev. de 2023 às 1

Yubikey detection by non-root user

Janne: I will read those man pages. I have never read or used fbtab or hotplugd. Thanks for the recommendations. Stuart: Glad I'm not messing things up that much. Will remember your advice of a dedicated user in case of a cli program. Thank you,

Re: doas.conf example

On 2023-02-02, Jon Fineman wrote: > I was following the doas.conf example in > > > Specially I added the below: > permit nopass setenv { \ > FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \ > DESTDIR DISTDIR FETCH_CMD FLAVOR G

doas.conf example

I was following the doas.conf example in Specially I added the below: permit nopass setenv { \ FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \ DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF \ MULTI_PACKAGES NOM

Re: LAN slow speed transfer

On 2023-02-02, vitmau...@gmail.com wrote: > Hello guys, > > I'm having problems trying to improve my transfer speed over LAN. I > can't consistently reach speeds over 10 MBytes/s using iPerf (real > disk writing transfers with scp render basically the same results). > Since both server (OpenBSD) a

LAN slow speed transfer

Hello guys, I'm having problems trying to improve my transfer speed over LAN. I can't consistently reach speeds over 10 MBytes/s using iPerf (real disk writing transfers with scp render basically the same results). Since both server (OpenBSD) and client (Windows) are able to reach speeds over 30 M

Re: Yubikey detection by non-root user

On 2023-02-01, Leonardo Moreno wrote: > Hello, > > I had trouble getting my Yubikey recognized by KeepassXC > as a normal user (staff class, wheel group). > > I compared the ktrace of ykpersonalize between root and this user > and saw that the latter couldn't access /dev/usb0 and /dev/ugen1.00 > >

Re: hw.ncpuonline (2 of 2)

On Thu, Feb 02, 2023 at 10:41:03AM -, Stuart Henderson wrote: > While the main reason for OpenBSD not scheduling work on 'cores' it sees > as SMT rather than full cores was for safety, a secondary reason was > that we don't have a way to treat them differently in the scheduler than > 'full' cor

Re: hw.ncpuonline (2 of 2)

On 2023-02-02, Crystal Kolipe wrote: > On Wed, Feb 01, 2023 at 04:56:17PM -0800, Justin Muir wrote: >> As requested, dmesg output: > > ... > >> cpu0: smt 0, core 0, package 0 >> cpu1: smt 1, core 0, package 0 >> cpu2: smt 0, core 1, package 0 >> cpu3: smt 1, core 1, package 0 > > This CPU presents

Re: hw.ncpuonline (2 of 2)

On Wed, Feb 01, 2023 at 04:56:17PM -0800, Justin Muir wrote: > As requested, dmesg output: ... > cpu0: smt 0, core 0, package 0 > cpu1: smt 1, core 0, package 0 > cpu2: smt 0, core 1, package 0 > cpu3: smt 1, core 1, package 0 This CPU presents itself as two cores, each with two threads, making