Re: Riello IPG 800 USB Driver and NUT
Hello Aron,
I did check very briefly for support using upd(4), but stopped after
being unable to register the UPS with that driver. This would allow
sysctl keep information on the ups. I guess that to give it another go,
I will have to change the kernel. This task is not a priority since NUT
is already an acceptable interface as long as we can make it work.
Regards,
Marcos Madeira
On 07/01/20 23:38, Marcos Madeira | Secure Networks wrote:
> Hello again,
>
> I have a tried a few other things, but without much success.
>
> In regards to using to using ucycom0 or uhidev0 or ucom0 as the virtual
> devices, I was not able to do this, because of how NUT needs a device to
> connect to. None of those devices have a file like /dev/ucycom0 .
>
> In regards to using a serial driver, NUT mentions that the supported
> driver is riello_usb. I did try riello_ser, but it makes the system drop
> to ddb after service start. The nut driver port in this case is
> /dev/cuaU0. I actually reached a somewhat interesting state, where at
> every boot the system drops to ddb, because the upsd service is enabled.
> I am not sure if this is expected behavior as far as OpenBSD goes. I can
> gather more data, but need to get different hardware, because (I assume)
> that the problem is in the USB stack resulting in the keyboard not being
> available to even do 'show panic'. Should this error be pursued or is it
> expected? It can be replicated by using cu -l /dev/cuaU0. The error is
> as follows:
>
> (0, 0, 1) -> e
>
> kernel: page faut trap, code=0
>
> Stopped at usbd_is_dying+0xb: cmpb $0,0x8(%ecx)
>
> ddb{0}>
>
>
> Finally, when using the riello_usb driver, I get much different upsc
> output on Ubuntu as compared to OpenBSD. For example, the ups.status
> does not even change when unplugging the UPS. I will be checking this
> separately as it could be just a problem with the versions of the nut
> port. The following is the relevant output:
>
> $ upsc ups@127.0.0.1
>
> battery.capacity: 7
> battery.charge: 64720
> battery.charge.low: 40
> battery.runtime: 3145920
> battery.voltage: 5243.2
> battery.voltage.nominal: 12
> device.mfr: RPS S.p.a.
> device.model: USV5
> device.serial:
> device.type: ups
> driver.flag.ignorelb: enabled
> driver.name: riello_usb
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.synchronous: no
> driver.version: 2.7.4
> driver.version.internal: 0.03
> input.bypass.frequency: 5243.20
> input.bypass.voltage: 52432
> input.frequency: 5243.20
> input.voltage: 52432
> output.frequency: 0.00
> output.frequency.nominal: 50.0
> output.L1.current: 52432
> output.L1.power: 52432
> output.L1.realpower: 52432
> output.L2.current: 52432
> output.L2.power: 52432
> output.L2.realpower: 52432
> output.L3.current: 52432
> output.L3.power: 52432
> output.L3.realpower: 52432
> output.power.percent: 64720
> output.voltage: 52432
> output.voltage.nominal: 230
> ups.firmware: SWM036-01-02
> ups.load: 64720
> ups.mfr: RPS S.p.a.
> ups.model: USV5
> ups.power.nominal: 800
> ups.productid: 5500
> ups.realpower.nominal: 480
> ups.serial:
> ups.status: OL OFF
> ups.temperature: 64720
> ups.vendorid: 04b4
>
> Thank you for your consideration,
>
> Marcos Madeira
> Secure Networks Lda
> Tel.: 911 881 590
> mmade...@securenetworks.pt
> https://www.securenetworks.pt
>
> On 03/01/20 11:58, Marcos Madeira | Secure Networks wrote:
>> Hello misc,
>>
>> I am looking to use several Riello UPSs of model IPG 800 DE with
>> OpenBSD through the nut port. These UPSs also go by the name iPlug.
>> This is a compact UPS with only a single USB-B connector for
>> connectivity as is usual with low-end UPSs. However, I am facing an
>> obstacle due to how OpenBSD is discovering the UPS via the USB interface.
>>
>> Thank you for your consideration,
>>
>> --
>> Marcos Madeira
signature.asc
Description: OpenPGP digital signature
Re: Slow performance when using mu(4e)
Xiyue Deng writes: > Hi, > > Recently I tried to use mu4e on OpenBSD. However the indexing > performance is dreadly slow compared to my Linux box. There was also an > issue report on mu upstream[1] where someone reported mu can only > process ~7msg/s on OpenBSD. I suspect it's because of the slow write > performance on FFS, which in my case can only process ~2msg/s when the > index file grows large (over 1GB) (BTW my box is mips64el/Loongson > running 6.6-stable so it's even slower). The read part is probably OK > as when re-indexing it can quickly skip already indexed items but when > adding new contents to the index it becomes slow again. Would like to > ask for some suggestions on how to improve this situation. > > Thanks in advance. > > [1] https://github.com/djcb/mu/issues/1335 Ping. Would like to get some advice on how to improve this situation. signature.asc Description: PGP signature
Re: Odd /tmp behavior
On Tue, Jan 07, 2020 at 10:16:22AM -0700, Raymond, David wrote: > On an AMD-64 workstation /tmp fills up to 105% according to df, > apparently as a result of UNIX pipes in a shell script passing a whole > lot of moderately big files. Examination of /tmp with du and ls -gal > on /tmp shows no big files and trying to delete everything that is > there has no effect. Rebooting cleans out /tmp. > > I had /tmp mounted with the standard options + softdep. I eliminated > softdep and the problem appears to have gone away. > > Any ideas on what is going on with softdep here? Dmesg shows a long > series of "/tmp file system full" messages. If you're using current and that started to happens in the last week or so, then maybe there is some bug somewhere in the softdep code. Some devs are reworking some parts of softdep. If the problem is not new or you're using -stable, then maybe the problem is that you're using a too small /tmp partition. Softdep delays the writing of metadata. Maybe you're writing and deleting too much data without giving softdep a chance to update the metadata on the disk. Giving more space to /tmp should fix the problem. Even if you're not going to use so much space, softdep will need the extra space between the metadata updates. BTW, I prefer to use "async" for /tmp. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Issues with X and Gnome on OpenBSD new install
January 8, 2020 8:11 AM, "Michael G Workman" wrote: > Hello, > > OpenBSD is a great operating system, glad to have been to installed it > successfully. > > I installed OpenBSD on a Dell Vostro 1500 laptop with dual core 2ghz intel > processor, 2 GB of RAM, and 120 GB hard drive (circa 2008 laptop) > > I had problems with firefox, but installed Chromium instead and Chrome > works great for web browsing. > > I also installed bash and nano, and also installed Gnome. Hoping to use > Gnome instead of the default window manager. > > But encountered a fatal error, the X server could not be found, and also a > driver called xf86OpenConsole was missing, causing a fatal server error. > > When I installed it, I chose openbsd-dell for the hostname, and then > OpenBSD tacked on attlocal.net to it to make it openbsd-dell.attlocal.net, > but not sure how that happened, an nslookup on attlocal.net says it is an > invalid domain. > > I am sure it must be a simple fix, here is my Xorg.1.log file: > > Thanks. > > [ 6760.324] > X.Org X Server 1.20.5 > X Protocol Version 11, Revision 0 > [ 6760.324] Build Operating System: OpenBSD 6.6 amd64 > [ 6760.324] Current Operating System: OpenBSD openbsd-dell.attlocal.net > 6.6 GENERIC.MP#372 amd64 > [ 6760.324] Build Date: 12 October 2019 11:22:22AM > [ 6760.324] > [ 6760.325] Current version of pixman: 0.38.4 > [ 6760.325] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 6760.325] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 6760.325] (==) Log file: > "/home/mworkman72/.local/share/xorg/Xorg.1.log", Time: Tue Jan 7 15:01:09 > 2020 > [ 6760.341] (==) Using system config directory > "/usr/X11R6/share/X11/xorg.conf.d" > [ 6760.351] (==) No Layout section. Using the first Screen section. > [ 6760.351] (==) No screen section available. Using defaults. > [ 6760.351] (**) |-->Screen "Default Screen Section" (0) > [ 6760.351] (**) | |-->Monitor "" > [ 6760.352] (==) No monitor specified for screen "Default Screen Section". > Using a default monitor configuration. > [ 6760.352] (==) Automatically adding devices > [ 6760.352] (==) Automatically enabling devices > [ 6760.352] (==) Not automatically adding GPU devices > [ 6760.352] (==) Max clients allowed: 256, resource mask: 0x1f > [ 6760.401] (==) FontPath set to: > /usr/X11R6/lib/X11/fonts/misc/, > /usr/X11R6/lib/X11/fonts/TTF/, > /usr/X11R6/lib/X11/fonts/OTF/, > /usr/X11R6/lib/X11/fonts/Type1/, > /usr/X11R6/lib/X11/fonts/100dpi/, > /usr/X11R6/lib/X11/fonts/75dpi/ > [ 6760.401] (==) ModulePath set to "/usr/X11R6/lib/modules" > [ 6760.401] (II) The server relies on wscons to provide the list of input > devices. > If no devices become available, reconfigure wscons or disable > AutoAddDevices. > [ 6760.401] (II) Loader magic: 0xef025473000 > [ 6760.402] (II) Module ABI versions: > [ 6760.402] X.Org ANSI C Emulation: 0.4 > [ 6760.402] X.Org Video Driver: 24.0 > [ 6760.402] X.Org XInput driver : 24.1 > [ 6760.404] X.Org Server Extension : 10.0 > [ 6760.404] (EE) > Fatal server error: > [ 6760.404] (EE) xf86OpenConsole: No console driver found > Supported drivers: wscons > Check your kernel's console driver configuration and /dev entries(EE) > [ 6760.404] (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 6760.404] (EE) Please also check the log file at > "/home/mworkman72/.local/share/xorg/Xorg.1.log" for additional information. > [ 6760.405] (EE) > [ 6760.406] (EE) Server terminated with error (1). Closing log file. from the looks of things you are using startx(1) read https://www.openbsd.org/faq/faq11.html#StartingX and use xenodm(1) instead also look at your dmesg and look for something "drm" something. if you have errors do a fw_update(1). > > *Michael G. Workman* > (321) 432-9295 > michael.g.work...@gmail.com yorosiku ~
Re: Riello IPG 800 USB Driver and NUT
On Wed, Jan 8, 2020 at 10:52 AM Marcos Madeira | Secure Networks
wrote:
>
> Hello again,
>
> I have a tried a few other things, but without much success.
>
> In regards to using to using ucycom0 or uhidev0 or ucom0 as the virtual
> devices, I was not able to do this, because of how NUT needs a device to
> connect to. None of those devices have a file like /dev/ucycom0 .
>
> In regards to using a serial driver, NUT mentions that the supported
> driver is riello_usb. I did try riello_ser, but it makes the system drop
> to ddb after service start. The nut driver port in this case is
> /dev/cuaU0. I actually reached a somewhat interesting state, where at
> every boot the system drops to ddb, because the upsd service is enabled.
> I am not sure if this is expected behavior as far as OpenBSD goes. I can
> gather more data, but need to get different hardware, because (I assume)
> that the problem is in the USB stack resulting in the keyboard not being
> available to even do 'show panic'. Should this error be pursued or is it
> expected? It can be replicated by using cu -l /dev/cuaU0. The error is
> as follows:
>
> (0, 0, 1) -> e
>
> kernel: page faut trap, code=0
>
> Stopped at usbd_is_dying+0xb: cmpb $0,0x8(%ecx)
>
> ddb{0}>
>
>
> Finally, when using the riello_usb driver, I get much different upsc
> output on Ubuntu as compared to OpenBSD. For example, the ups.status
> does not even change when unplugging the UPS. I will be checking this
> separately as it could be just a problem with the versions of the nut
> port. The following is the relevant output:
>
> $ upsc ups@127.0.0.1
>
> [SNIP]
>
> Thank you for your consideration,
>
> Marcos Madeira
> Secure Networks Lda
> Tel.: 911 881 590
> mmade...@securenetworks.pt
> https://www.securenetworks.pt
>
> On 03/01/20 11:58, Marcos Madeira | Secure Networks wrote:
> >
> > Hello misc,
> >
> > I am looking to use several Riello UPSs of model IPG 800 DE with
> > OpenBSD through the nut port. These UPSs also go by the name iPlug.
> > This is a compact UPS with only a single USB-B connector for
> > connectivity as is usual with low-end UPSs. However, I am facing an
> > obstacle due to how OpenBSD is discovering the UPS via the USB interface.
> >
>
> > Thank you for your consideration,
> >
> > --
> > Marcos Madeira
>
Just a thought... IIRC on laptops you can access battery info in
sysctl(8) - charge level, charge remaining, whether it has AC input,
etc. Could you do the same here?
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Riello IPG 800 USB Driver and NUT
Hello again,
I have a tried a few other things, but without much success.
In regards to using to using ucycom0 or uhidev0 or ucom0 as the virtual
devices, I was not able to do this, because of how NUT needs a device to
connect to. None of those devices have a file like /dev/ucycom0 .
In regards to using a serial driver, NUT mentions that the supported
driver is riello_usb. I did try riello_ser, but it makes the system drop
to ddb after service start. The nut driver port in this case is
/dev/cuaU0. I actually reached a somewhat interesting state, where at
every boot the system drops to ddb, because the upsd service is enabled.
I am not sure if this is expected behavior as far as OpenBSD goes. I can
gather more data, but need to get different hardware, because (I assume)
that the problem is in the USB stack resulting in the keyboard not being
available to even do 'show panic'. Should this error be pursued or is it
expected? It can be replicated by using cu -l /dev/cuaU0. The error is
as follows:
(0, 0, 1) -> e
kernel: page faut trap, code=0
Stopped at usbd_is_dying+0xb: cmpb $0,0x8(%ecx)
ddb{0}>
Finally, when using the riello_usb driver, I get much different upsc
output on Ubuntu as compared to OpenBSD. For example, the ups.status
does not even change when unplugging the UPS. I will be checking this
separately as it could be just a problem with the versions of the nut
port. The following is the relevant output:
$ upsc ups@127.0.0.1
battery.capacity: 7
battery.charge: 64720
battery.charge.low: 40
battery.runtime: 3145920
battery.voltage: 5243.2
battery.voltage.nominal: 12
device.mfr: RPS S.p.a.
device.model: USV5
device.serial:
device.type: ups
driver.flag.ignorelb: enabled
driver.name: riello_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.internal: 0.03
input.bypass.frequency: 5243.20
input.bypass.voltage: 52432
input.frequency: 5243.20
input.voltage: 52432
output.frequency: 0.00
output.frequency.nominal: 50.0
output.L1.current: 52432
output.L1.power: 52432
output.L1.realpower: 52432
output.L2.current: 52432
output.L2.power: 52432
output.L2.realpower: 52432
output.L3.current: 52432
output.L3.power: 52432
output.L3.realpower: 52432
output.power.percent: 64720
output.voltage: 52432
output.voltage.nominal: 230
ups.firmware: SWM036-01-02
ups.load: 64720
ups.mfr: RPS S.p.a.
ups.model: USV5
ups.power.nominal: 800
ups.productid: 5500
ups.realpower.nominal: 480
ups.serial:
ups.status: OL OFF
ups.temperature: 64720
ups.vendorid: 04b4
Thank you for your consideration,
Marcos Madeira
Secure Networks Lda
Tel.: 911 881 590
mmade...@securenetworks.pt
https://www.securenetworks.pt
On 03/01/20 11:58, Marcos Madeira | Secure Networks wrote:
>
> Hello misc,
>
> I am looking to use several Riello UPSs of model IPG 800 DE with
> OpenBSD through the nut port. These UPSs also go by the name iPlug.
> This is a compact UPS with only a single USB-B connector for
> connectivity as is usual with low-end UPSs. However, I am facing an
> obstacle due to how OpenBSD is discovering the UPS via the USB interface.
>
> Thank you for your consideration,
>
> --
> Marcos Madeira
signature.asc
Description: OpenPGP digital signature
Issues with X and Gnome on OpenBSD new install
Hello, OpenBSD is a great operating system, glad to have been to installed it successfully. I installed OpenBSD on a Dell Vostro 1500 laptop with dual core 2ghz intel processor, 2 GB of RAM, and 120 GB hard drive (circa 2008 laptop) I had problems with firefox, but installed Chromium instead and Chrome works great for web browsing. I also installed bash and nano, and also installed Gnome. Hoping to use Gnome instead of the default window manager. But encountered a fatal error, the X server could not be found, and also a driver called xf86OpenConsole was missing, causing a fatal server error. When I installed it, I chose openbsd-dell for the hostname, and then OpenBSD tacked on attlocal.net to it to make it openbsd-dell.attlocal.net, but not sure how that happened, an nslookup on attlocal.net says it is an invalid domain. I am sure it must be a simple fix, here is my Xorg.1.log file: Thanks. [ 6760.324] X.Org X Server 1.20.5 X Protocol Version 11, Revision 0 [ 6760.324] Build Operating System: OpenBSD 6.6 amd64 [ 6760.324] Current Operating System: OpenBSD openbsd-dell.attlocal.net 6.6 GENERIC.MP#372 amd64 [ 6760.324] Build Date: 12 October 2019 11:22:22AM [ 6760.324] [ 6760.325] Current version of pixman: 0.38.4 [ 6760.325] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 6760.325] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 6760.325] (==) Log file: "/home/mworkman72/.local/share/xorg/Xorg.1.log", Time: Tue Jan 7 15:01:09 2020 [ 6760.341] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 6760.351] (==) No Layout section. Using the first Screen section. [ 6760.351] (==) No screen section available. Using defaults. [ 6760.351] (**) |-->Screen "Default Screen Section" (0) [ 6760.351] (**) | |-->Monitor "" [ 6760.352] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 6760.352] (==) Automatically adding devices [ 6760.352] (==) Automatically enabling devices [ 6760.352] (==) Not automatically adding GPU devices [ 6760.352] (==) Max clients allowed: 256, resource mask: 0x1f [ 6760.401] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 6760.401] (==) ModulePath set to "/usr/X11R6/lib/modules" [ 6760.401] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [ 6760.401] (II) Loader magic: 0xef025473000 [ 6760.402] (II) Module ABI versions: [ 6760.402] X.Org ANSI C Emulation: 0.4 [ 6760.402] X.Org Video Driver: 24.0 [ 6760.402] X.Org XInput driver : 24.1 [ 6760.404] X.Org Server Extension : 10.0 [ 6760.404] (EE) Fatal server error: [ 6760.404] (EE) xf86OpenConsole: No console driver found Supported drivers: wscons Check your kernel's console driver configuration and /dev entries(EE) [ 6760.404] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 6760.404] (EE) Please also check the log file at "/home/mworkman72/.local/share/xorg/Xorg.1.log" for additional information. [ 6760.405] (EE) [ 6760.406] (EE) Server terminated with error (1). Closing log file. *Michael G. Workman* (321) 432-9295 michael.g.work...@gmail.com
ifconfig behavior
Hi misc@ happy new year! While running snapshot #584 on amd64 I noticed setting addresses using ifconfig is not consistent for ipv4 and ipv6. Is this expected behavior? I wasn't able to find anything in the FAQ. Many thanks, Pedro Caetano pcaetano@rtr $ > doas ifconfig vether100 create pcaetano@rtr $ > doas ifconfig vether100 inet 10.10.10.1 pcaetano@rtr $ > doas ifconfig vether100 inet 10.10.10.2 pcaetano@rtr $ > doas ifconfig vether100 inet 10.10.10.3 pcaetano@rtr $ > ifconfig vether100 vether100: flags=8843 mtu 1500 lladdr fe:e1:ba:d5:bd:bf index 22 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.10.3 netmask 0xff00 broadcast 10.255.255.255 pcaetano@rtr $ > doas ifconfig vether100 destroy pcaetano@rtr $ > doas ifconfig vether100 create pcaetano@rtr $ > doas ifconfig vether100 inet6 fe80::1 pcaetano@rtr $ > doas ifconfig vether100 inet6 fe80::2 pcaetano@rtr $ > doas ifconfig vether100 inet6 fe80::3 pcaetano@rtr $ > doas ifconfig vether100 vether100: flags=8843 mtu 1500 lladdr fe:e1:ba:d7:91:b2 index 24 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet6 fe80::fce1:baff:fed7:91b2%vether100 prefixlen 64 scopeid 0x18 inet6 fe80::1%vether100 prefixlen 64 scopeid 0x18 inet6 fe80::2%vether100 prefixlen 64 scopeid 0x18 inet6 fe80::3%vether100 prefixlen 64 scopeid 0x18
Re: Odd /tmp behavior
On 2020-01-07 11:06, Karel Gardas wrote: On 1/7/20 7:38 PM, Jordan Geoghegan wrote: > Using softdep on /tmp is a silly idea. > Why? To naive eyes it may look like a natural solution: e.g. before temp file is even created (on drive), it may be deleted which means there is no meta-data change hence speedup of operation on /tmp. In case of classical ffs, you will need to create file (sync meta-data update), save some data (async), delete file (sync meta-data update). But honestly still need to read the code... softdep is very complex, and it is by no means perfect or bug free. A good rule of thumb is to only use softdep on larger partitions that will see a large number of writes (particularly smaller and/or random writes). Softdep can chew up a fair amount of kernel memory as well, and in certain cases changes can take over a minute to actually make their way on to disk. If softdep was the magic bullet that some people think it is, it would be enabled by default.
Re: usr/bin/whois: Query terms are ambiguous
Hi Markus, On 07.01.20 at 21:19, Markus Lude wrote: > The server on the other hand could handle different record types, for > example "n ..." for network address space, but there are more. > If the record type is missing the server assumes (in this case) the > record type is n and notifies you of this assumption. > So it may be the other way around, "n " may be missing here in the > query to the ARIN whois server. Okay, didn't know that at this time. Currently I know three query formats: whois on Linux: -V Md5.2 62.46.172.92 \r\n whois (sysinternals.com - Microsoft) on Windows -> This query doesn't like NIC.AT (invalid request): 62-46-172-92.ADSL.HIGHWAY.TELEKOM.AT\r\n whois on OpenBSD: 62.46.172.92\r\n > Compare the output of the following two: > > telnet whois.arin.net 43 > 62.46.172.92 > > which is also what you get with "whois 62.46.172.92" > and this: > > telnet whois.arin.net 43 > n 62.46.172.92 > > and if you want to see the mentioned help above: > > telnet whois.arin.net 43 > ? > > whois.apnic.net and whois.ripe.net understand "help" to display options. > > There seem to be no "standard" about options in queries to whois > servers. Okay, thanks! Nice, to learn something new. :)
Re: usr/bin/whois: Query terms are ambiguous
On Tue, Jan 07, 2020 at 06:49:40PM +0100, Johannes Krottmayer wrote: > Hi, Hi Johannes, > I have a strange issue, when using the "whois" client. > > Always get the following as example: > [...] > # > # Query terms are ambiguous. The query is assumed to be: > # "n 62.46.172.92" > # > # Use "?" to get help. > # > [...] > > I have OpenBSD 6.6 installed on two systems. The issue exists > on all those systems. > > Have looked for a bug (for a leading "n " string) in the > source of whois. But didn't find anything. I have also installed > OpenBSD on a vbox and analyzed the query with wireshark. I think you misunderstood the message. The whois binary only send "62.46.172.92" to the whois server, as you may see in you trace below. > But I think the query is correct (Ethernet frame): > 60 38 e0 c2 bd 30 08 00 27 06 0f 2d 08 00 45 00 `8...0..'..-..E. > 0010 00 42 62 43 40 00 40 06 dc 7c 0a 2a 2a 57 c7 47 .BbC@.@..|.**W.G > 0020 00 2e 60 1a 00 2b c7 76 ec 0f 9b fd 95 79 80 18 ..`..+.v.y.. > 0030 01 00 d3 cf 00 00 01 01 08 0a 00 13 e6 e0 a4 51 ...Q > 0040 91 22 36 32 2e 34 36 2e 31 37 32 2e 39 32 0d 0a ."62.46.172.92.. > > No leading "n " string. > > Has somebody noticed the same issue? The server on the other hand could handle different record types, for example "n ..." for network address space, but there are more. If the record type is missing the server assumes (in this case) the record type is n and notifies you of this assumption. So it may be the other way around, "n " may be missing here in the query to the ARIN whois server. Compare the output of the following two: telnet whois.arin.net 43 62.46.172.92 which is also what you get with "whois 62.46.172.92" and this: telnet whois.arin.net 43 n 62.46.172.92 and if you want to see the mentioned help above: telnet whois.arin.net 43 ? whois.apnic.net and whois.ripe.net understand "help" to display options. There seem to be no "standard" about options in queries to whois servers. Regards, Markus
Re: LibreSSL performance issue
On Tue, Jan 07, 2020 at 11:06:38AM -0800, Jordan Geoghegan wrote: > Is there a specific reason you're running i386 instead of amd64? Yes, i386 generates substantially smaller images than amd64. In an environment where you are constrained to the existing available virtualization capacity and are tasked with making the most of that, there is no obvious reason why you would build infrastructure devices such as a DHCP server using amd64. We also have a supply of embedded Soekris systems which only run the i386. > And why are you testing this on FreeBSD? Wrong mailing list Probably not. LibreSSL is intended to be portable, and the LibreSSL web site points back to the OpenBSD mailing lists: https://www.libressl.org/mail.html "See https://www.openbsd.org/mail.html for more details on posting or subscribing." So now over at https://www.openbsd.org/mail.html ... I would think libre...@openbsd.org would seem the obvious choice of list. However, it is listed under "Developer lists These lists are for technical discussions of aspects of OpenBSD. They are NOT for beginners or average users, they are not for problem reporting (unless you are including a good fix) and they are not for installation problems. If you have any question about if a message should be posted to any of these lists, it probably should not. Use misc instead." So according to the guidelines on the website, my issue didn't fit libre...@openbsd.org, and there is an instruction to use misc instead. Besides, it came up as a reply to a message posted on misc. ... 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: LibreSSL performance issue
Is there a specific reason you're running i386 instead of amd64? And why are you testing this on FreeBSD? Wrong mailing list On 2020-01-07 08:26, Joe Greco wrote: 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:
Re: Odd /tmp behavior
On 1/7/20 7:38 PM, Jordan Geoghegan wrote: > Using softdep on /tmp is a silly idea. > Why? To naive eyes it may look like a natural solution: e.g. before temp file is even created (on drive), it may be deleted which means there is no meta-data change hence speedup of operation on /tmp. In case of classical ffs, you will need to create file (sync meta-data update), save some data (async), delete file (sync meta-data update). But honestly still need to read the code...
Re: LibreSSL performance issue
On Tue, Jan 07, 2020 at 07:50:37PM +0100, Bodie wrote: > On 7.1.2020 17:26, Joe Greco wrote: > >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. > > [...] > >Now in the third run, calling the host system's OpenSSL but twiddling > >ia32cap, I get numbers that are very similar to the LibreSSL numbers > >showing a similar catastrophic performance reduction. My conclusion > >is that this is somehow an AES-NI detection issue. For whatever > >reason, > >FreeBSD's openssl gets it right by default. > > > >And the fourth run was "just to see." > > Just WOW > > So you start with blaming OpenBSD for poor performance and then as a > "prove" > you show tests of completely different OS on completely different > filesystem > on God knows which hypervisor and then throw in the mix amd64 vs i386? > > I think Phoronix will hire you ;-) I did no such thing. I used a problem I encountered as an example of how the original poster's implication isn't true. I did say "I'm not going to blame libressl". And if anything, if you read for comprehension, I defended OpenBSD. But now I kinda remember why I participate so rarely on these lists. ... 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: LibreSSL performance issue
On 7.1.2020 17:26, Joe Greco wrote: 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.47k 51858.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)
Re: Odd /tmp behavior
On 2020-01-07 09:16, Raymond, David wrote: On an AMD-64 workstation /tmp fills up to 105% according to df, apparently as a result of UNIX pipes in a shell script passing a whole lot of moderately big files. Examination of /tmp with du and ls -gal on /tmp shows no big files and trying to delete everything that is there has no effect. Rebooting cleans out /tmp. I had /tmp mounted with the standard options + softdep. I eliminated softdep and the problem appears to have gone away. Any ideas on what is going on with softdep here? Dmesg shows a long series of "/tmp file system full" messages. Dave Raymond Using softdep on /tmp is a silly idea. I see way too many people who don't understand how softdep works.
usr/bin/whois: Query terms are ambiguous
Hi, I have a strange issue, when using the "whois" client. Always get the following as example: [...] # # Query terms are ambiguous. The query is assumed to be: # "n 62.46.172.92" # # Use "?" to get help. # [...] I have OpenBSD 6.6 installed on two systems. The issue exists on all those systems. Have looked for a bug (for a leading "n " string) in the source of whois. But didn't find anything. I have also installed OpenBSD on a vbox and analyzed the query with wireshark. But I think the query is correct (Ethernet frame): 60 38 e0 c2 bd 30 08 00 27 06 0f 2d 08 00 45 00 `8...0..'..-..E. 0010 00 42 62 43 40 00 40 06 dc 7c 0a 2a 2a 57 c7 47 .BbC@.@..|.**W.G 0020 00 2e 60 1a 00 2b c7 76 ec 0f 9b fd 95 79 80 18 ..`..+.v.y.. 0030 01 00 d3 cf 00 00 01 01 08 0a 00 13 e6 e0 a4 51 ...Q 0040 91 22 36 32 2e 34 36 2e 31 37 32 2e 39 32 0d 0a ."62.46.172.92.. No leading "n " string. Has somebody noticed the same issue? -- Best regards, Johannes K.
Re: Odd /tmp behavior
On Tue, Jan 7, 2020 at 12:18 PM Raymond, David wrote: > On an AMD-64 workstation /tmp fills up to 105% according to df, > apparently as a result of UNIX pipes in a shell script passing a whole > lot of moderately big files. Examination of /tmp with du and ls -gal > on /tmp shows no big files and trying to delete everything that is > there has no effect. Rebooting cleans out /tmp. > > I had /tmp mounted with the standard options + softdep. I eliminated > softdep and the problem appears to have gone away. > > Any ideas on what is going on with softdep here? Dmesg shows a long > series of "/tmp file system full" messages. > > Dave Raymond > > -- > David J. Raymond > david.raym...@nmt.edu > http://physics.nmt.edu/~raymond > > man fstat -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Odd /tmp behavior
On an AMD-64 workstation /tmp fills up to 105% according to df, apparently as a result of UNIX pipes in a shell script passing a whole lot of moderately big files. Examination of /tmp with du and ls -gal on /tmp shows no big files and trying to delete everything that is there has no effect. Rebooting cleans out /tmp. I had /tmp mounted with the standard options + softdep. I eliminated softdep and the problem appears to have gone away. Any ideas on what is going on with softdep here? Dmesg shows a long series of "/tmp file system full" messages. Dave Raymond -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
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: Thinking of changing DNS Service provider, looking for recommendations
If it is for your personal use only, you can have a look at the Opennic Project. They have an alternate DNS structure separated for the regular DNS Root. They provide Dynamic DNS for their .dyn unofficial TDL. It is free of charge and you need no special client for it to work, only ftp/curl/wget and cron. The catch is that, for a computer to be able to access the .dyn TDL, it needs to use Opennic DNS servers. If it is just for you, you can configure your computers anr routers to use them and be done with it. If your need the general public to access it, you are out of luck with Opennic. Jay Hart wrote: > Hey all, and Happy New Years!!! > > I am currently using DYN.COM for DNS service. A few months back they changed > there payment > methodology and I am now considering finding another solution. DYN charges me > $5 US monthly so its > not a huge financial burden. That said, if I could find a free service > provider, all the better. > > My only real requirement is they must be able to support OpenBSD based > system. Currently using > DDclient. It works fine, has been for years. > > This would be for a residential connection. > > Guess what I'm really looking for, from the list, is a OpenBSD friendly > provider, and a brief > write up on how you are connected. I've looked over a few sites but nothing > stood out as being > OpenBSD friendly. > > Thanks in Advance, > > Jay > > -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
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
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.. No, I'm not a fan of Calomel.
Re: Boot fail using internal SATA port, success using USB port.
On 2020-01-05 22:22, Chris Bennett wrote: HyperThread must be off! Danger! Good to know, I disabled. Probably shouldn't enable virtualization unless using it. Also good to know. Secure boot is off, that is correct. Do you have the latest BIOS? Yes. I also tried downgrading. Will the disk boot if you skip UEFI completely and run in legacy mode? I am not sure how that would be. I am presented with the DELL logo and the option to (f2)UEFI setup, (f5)diagnostics and (f12)legacy mode but like I said the UEFI(DELL logo) stays static and those options glitch. Are you dual-booting with Windows? It hates everything and can mess up BIOS settings to make you love Windows even more. I dedicated the whole machine. Do you get to the boot> prompt? Then try booting the different hard drives listed above it manually. I do not even get to that, unless using a "SATA to USB" cable but that is impractical. Good Luck, Chris Bennett I also tried: -Installing OpenBSD using internal SATA port of problem machine then trying it on the internal SATA port of another. It worked. -Booting OpenBSD from secondary SATA port using a caddie. It did not work. -Much more troubleshooting and UEFI options. My deduction: -The internal port works fine since it can boot Windows. -There should not be anything wrong with UEFI since it can boot OpenBSD from USB port. -All behavior I noted indicates that the internal ports do not recognize the filesystem/format/partition. That is as far as I am educated. I decided to use OpenBSD on the older laptop despite it's falling apart. I will keep the problem laptop just for Winblows until I get proficient with OpenBSD and then sell the ungrateful PoS.
Re: But there is Fossil...
On Tue, Jan 07, 2020 at 12:26:49PM +, Roderick wrote: > > On Mon, 6 Jan 2020, Sean Kamath wrote: > > > Having said that, I use whatever repo projects provide. I’m not here to > > say VCS “A” is better than VCS “B”, just saying installing various > > VCS’s under OpenBSD is pretty damn simple. > > It seems to be like the wars perl vs python, emacs vs vi, etc. > > But no, there are differences: it is groupware, about workflow. > The appropriate VCS may depend on the way people works, see > for example: > > https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki There's a lot of fluff in there which doesn't apply to Got in any way. It used to be patches vs. CVS, then SVN vs. X, and these days it is usually Git vs. X. The actual reasons why people start writing VCS tools and make certain design choices rarely show up in high-level comparisons written with the benefit of hindsight. It is important to note that Got is not Git and while I took inspiration from several other VCS systems I don't see any reason to write up detailed comparisons between Got and any other systems. Taking over users from other systems is not a goal. Those users already have the tools they need. I am writing this tool so I can use it to hack on OpenBSD for which I have already used and considered many VCS over years, including fossil: $ ls -l *.fossil -rw-r--r-- 1 stsp users - 368K Jan 31 2017 athn.fossil -rw-r--r-- 1 stsp users - 180K Jan 17 2014 avr32.fossil -rw-r--r-- 1 stsp users - 912K Dec 25 2017 bgscan.fossil -rw-r--r-- 1 stsp users - 348K Jul 18 2014 bwi.fossil -rw-r--r-- 1 stsp users - 86.0K Jul 31 2014 dolphin.fossil -rw-r--r-- 1 stsp users - 1005K Feb 7 2015 iwm.fossil -rw-r--r-- 1 stsp users - 908K Jun 4 2016 iwm8k.fossil -rw-r--r-- 1 stsp users - 736K Nov 12 2016 mira.fossil -rw-r--r-- 1 stsp users - 117K Aug 27 2013 omedma.fossil -rw-r--r-- 1 stsp users - 100K Oct 21 2013 omsdma.fossil -rw-r--r-- 1 stsp users - 97.0K Dec 16 2013 rsu.fossil -rw-r--r-- 1 stsp users - 228K May 18 2014 run.fossil -rw-r--r-- 1 stsp users - 207K Jun 5 2015 urtwn.fossil $ > (GIT has the repository inside the checkout). This is not the case with Got. By the way, thank you for trimming the list of recipients down to misc@,
Re: Boot fail using internal SATA port, success using USB port.
On 2020-01-05 12:29, hkew...@cock.li wrote: > summary: OpenBSD installs to internal HDD from external USB but fails > to load after the first reboot. If the HDD is removed from the internal > port and is connected via a "SATA to USB" cable it boots succesfully. > > I am a new and inexperienced user, excuse my ignorance. > > All the details and things I have tried so far: > > -All relevant UEFI options configured to legacy mode. careful with this. Just because it says it supports legacy mode doesn't mean the BIOS was extensively tested in legacy mode. I'd try both modes, just for giggles. > -minirootXX.fs copied to USB using rufus. > -USB boot using legacy mode. > -In install: whole disk mbr-auto config. see above. :) > -After reboot DELL logo is displayed 3 times. On the 3rd time it stays > static. > --Using gpt format instead results in an infinite boot loop. oh. you did try GPT. nevermind. > -Starting UEFI-menu(f2) or diagnostics(f5) or boot-menu(f12) appear to > initiate but then stay static. The UEFI appears to be completely > "bricked". There is no way to proceed. > --Resetting UEFI using CMOS and booting with the HDD in internal port > still renders UEFI "bricked" although it gives a PXE option because it > is enabled by default in the now reset UEFI. > --Merely performing a "clean" on diskpart(win7) to the HDD and plugging > it back "unbricks" the UEFI. > --Merely removing the HDD "unbricks" the UEFI. > -Connecting HDD using "SATA to USB" cable(even without CMOS reset) > works and OpenBSD boots. > -Installing Windows 7(in the same manner OpenBSD was) works and boots > from the internal SATA port. > > Deduction: There seems to be something not allowing OpenBSD to boot > from the internal SATA port, in addition to it rendering the laptop > unusable until the HDD is removed, cleaned or connected via USB port. > > I have taken the time to write all the UEFI configuration I use. Please > check it if you think the problem stems from there. ouch. However, the effort is appreciated. > hardware: DELL Latitude e5440 Pretty sure I've tested one of those, they work. As I recall, the E5440 is a few years old, and if I recall properly, the battery wasn't very long-lived in it. And the Dells of that vintage had a really wacked default -- someone decided it would be best to default to "RAID" for disk mode. Yes, on a one drive laptop. For safety reasons, OpenBSD (and many other non-windows OSs) disable disk access if the disk controller is in RAID mode rather than ACHI or "legacy" mode. So ... is it possible the CMOS battery is bad on your machine? This would explain a "Power up, set up machine, install, reboot -- ok". "power off, power back on later, won't successfully boot" (the kernel would load, but be unable to access the disks and then panic). I'm not convinced this is the problem, but might be. Nick.
Re: But there is Fossil...
On Mon, 6 Jan 2020, Sean Kamath wrote: > Having said that, I use whatever repo projects provide. I’m not here to > say VCS “A” is better than VCS “B”, just saying installing various > VCS’s under OpenBSD is pretty damn simple. It seems to be like the wars perl vs python, emacs vs vi, etc. But no, there are differences: it is groupware, about workflow. The appropriate VCS may depend on the way people works, see for example: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki BTW, I like that the fossil repository may be everywhere, may easily created be moved to everyhere, that many checkouts may be easily open (GIT has the repository inside the checkout). It is indeed the VCS for "solo-repo people". And I like the simple format (RCS files) of CVS. Perhaps these things are les dependent from the workflow. It is an interesting thema, but perhaps off topic. Rodrigo
"no _STA method" 128 times in dmesg?
Hi, I'm running OpenBSD 6.5/amd64 in a qemu VM (host is Linux Debian). I see multiple lines of "no _STA method" in dmesg. (Full log: https://termbin.com/5ccz) I've asked the qemu developers on their irc channel what it might mean and they said it's ACPI related but they can't determine exactly what it is about. qemu-system-x86_64 -drive if=ide,file=/home/oc/VM/img/openbsd.image \ -M q35,accel=kvm -m 400M -cpu host -smp $(nproc) \ -net user,hostfwd=tcp::-:22 -net nic -nographic This is the command I use to boot OpenBSD: It's probably harmless but I'd like to have your opinion about it. Thanks -- Ottavio Caruso
