Re: dhcpleased(8) not renewing leases
On Freitag, 5. November 2021 16:33:11 -03 Sebastian Benoit wrote: > Eike Lantzsch ZP6CGE(zp6...@gmx.net) on 2021.11.04 18:07:57 -0300: > > On Mittwoch, 3. November 2021 14:41:08 -03 Zack Newman wrote: > > > dhcpleased(8) is unable to renew DHCP leases from my ISP, > > > Xfinity/Comcast. This in turn is causing leases to expire leading > > > to > > > IPv4 drops that last between 15 and 20 seconds until a new lease > > > can > > > be binded. Note that lease binding does succeed. > > > > Hi Zack, > > Similarily here. Did you specify a lladdr in your hostname.if after > > "dhcp"? > > I get a lease with my hardware MAC address without specifying > > lladdr, > > but it is not the right one of course. If I force the fake MAC > > address and then I ask for a new lease I get nothing. > > I'm going to write about it later together with all the pertinent > > infomation. Just now I am too busy with other disasters. > > please include tcpdump of both the non-working attempts and the > working attempts (if it is indeed successful with dhclient), with a > command like this: > > tcpdump -enlp -i iwm0 port 67 and port 68 > > Also include your hostname.if file and dhclient.conf and > dhcpleased.conf if any. > Thank you Sebastian Benoit! I think I figured it out now. There is no problem with 7.0 here. I read all the release notes but didn't readily understand which implications they have with hostname.if; dhclient and dhcpleasectl. I got now: hostname.em0 lladdr my-mac-address published to thmy ISP inet autoconf up and it works as intended. Before I had: hostname.em0 dhcp lladdr my-mac-address published to thmy ISP and that does not work anymore. Further my ISP had a bunch of network problems the day on which I upgraded and so I had several imponderabilities to deal with and to sort out. Thank for all to you and to Zack Newman and also apologies for breaking into his thread with something not related. Chees Eike > > > For about a month before the release of OpenBSD 7.0, I had been > > > using > > > dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to > > > be > > > "ahead of the curve" before the eventual release of OpenBSD 7.0. > > > During that time, there were no problems with lease renewals. I > > > have > > > not made any hardware or software changes other than the upgrade > > > to > > > 7.0. > > > > > > I've factory reset my bridge modem about a dozen times, I've > > > changed > > > the MAC address of the interface connected to the modem, I've > > > experimented using different NICs altogether, and nothing has > > > worked. > > > At the time, I "knew" it was Xfinity; so I demanded that a tech > > > come > > > over and inspect the cable lines and modem. They said it was fine; > > > although based on Internet reviews, that doesn't say much as they > > > are > > > often wrong. It wasn't until I had a slice of humble pie and > > > actually > > > considered that the problem was indeed my router that I was able > > > to > > > fix the problem by switching to dhcpcd which I have been already > > > using for DHCPv6. Sure enough, I have had no issues with IPv4 > > > renewals since then. > > > > > > I do know that Xfinity, at least where I am, does NOT respond to > > > unicast renewals for both DHCP and DHCPv6, but I am unsure if that > > > is > > > relevant. Before I successfully switched to dhcpcd, I made sure to > > > > > log dhcpleased(8) over night. Here are the results: > > [snip] -- Eike Lantzsch ZP6CGE Ag. Molas Lopez Casilla de Correo 13005 01726 Asuncion / Paraguay SIPgate: +49-4131-9279632 Land-line: +595-21-553984 Cell-phone: +595-971-696909 Skype: eikelan Signal: zp6cge Eike Lantzsch WIRE: @eikelantzsch
Re: "ERR M" on booting installation USB on Athlon
On Mon, Nov 08, 2021 at 08:25:24PM +0200, u...@mailo.com wrote: > Tried to install amd64 "install70.img" from a microSD on an old PC: > CPU: Athlon 64 X2 4200+ > Motherboard: Asus M2N-E > Chipset: nVIDIA nForce 570 SLI, AMD Hammer > USB1 controller: nVIDIA nForce 570 SLI (MCP55P) - OHCI USB 1.1 Controller > USB2 controller: nVIDIA nForce 570 SLI (MCP55P) - EHCI USB 2.0 Controller > > The "install70.img" was checked with both `sha256sum` and `signify-openbsd` > (a Debian package). > BTW, do I need `sha256sum` or does `signify` check the SHA sums as well? If you used something like: signify -C -p openbsd-70-base.pub -x SHA256.sig install70.img then signify would have checked the signature on the SHA256.sig file, and if and only if it's valid, then proceeded to check the checksums of the files listed in it. > At the very beginning of the boot, I get: > > > Loading;.. > ERR M The semi-colon indicated that the device is being read with CHS reads rather than LBA. I'm guessing that your BIOS is enumerating the flash drive as a floppy disk device rather than a hard disk. You might be able to change this behaviour in the BIOS. The ERR M suggests that the wrong blocks were read from the device, as you have tried a different card and reader with the same results, I'm assuming that it's not a bad card, or badly written image.
"ERR M" on booting installation USB on Athlon
Tried to install amd64 "install70.img" from a microSD on an old PC: CPU: Athlon 64 X2 4200+ Motherboard: Asus M2N-E Chipset: nVIDIA nForce 570 SLI, AMD Hammer USB1 controller: nVIDIA nForce 570 SLI (MCP55P) - OHCI USB 1.1 Controller USB2 controller: nVIDIA nForce 570 SLI (MCP55P) - EHCI USB 2.0 Controller The "install70.img" was checked with both `sha256sum` and `signify-openbsd` (a Debian package). BTW, do I need `sha256sum` or does `signify` check the SHA sums as well? At the very beginning of the boot, I get: Loading;.. ERR M 6 dots after Loading, blinking cursor below ERR M and nothing more. I have found "ERR M" at http://man.openbsd.org/biosboot Frankly, my knowledge level is insufficient to comprehend the info. I did sudo dd bs=1M if=install70.img of=/dev/sdb anew with another card (SD this time), another SD-to-USB adapter and another USB port — got the same "ERR M" Then I successfully installed from a USB-pluggable external DVD drive from "install70.iso" I wonder what was wrong with microSD & SD way
Re: clang performance bug is worse on openbsd than freebsd
Sorting an array of around 300 (or 3) randomly created unsigned characters sounds like a task tailor made for binsort. (Which seems plausibly worth mentioning in this context.) That said, the key openbsd issues might not include performance on this particular benchmark. Thanks, -- Raul On Sun, Nov 7, 2021 at 9:16 PM Luke Small wrote: > > https://bugs.llvm.org/show_bug.cgi?id=50026 > > I reported it to the llvm people. it is two slightly different quicksort > algorithms which perform radically differently. The one which you could > assume would take more time, performs MUCH better. > > I made a custom quicksort algorithm which outperforms qsort by A LOT for > sorting an array of around 300 randomly created unsigned characters, which > is what I use it for. > > if you read the report a guy said there's a 10% difference for sorting 3 > million characters on freebsd, but there's about 40% performance difference > on OpenBSD. maybe it's also how the OpenBSD team modified clang to prevent > rop chain stuff or something? I'm using a westmere based intell server. > > it's the same for clang 11. > > What's the deal? > > -Luke sort_test2r.c Description: Binary data
Re: clang performance bug is worse on openbsd than freebsd
On 2021-11-08, Theo de Raadt wrote: > Stuart Henderson wrote: > >> On 2021-11-08, Otto Moerbeek wrote: >> > On Sun, Nov 07, 2021 at 08:13:36PM -0600, Luke Small wrote: >> > >> >> https://bugs.llvm.org/show_bug.cgi?id=50026 >> >> >> >> I reported it to the llvm people. it is two slightly different quicksort >> >> algorithms which perform radically differently. The one which you could >> >> assume would take more time, performs MUCH better. >> >> >> >> I made a custom quicksort algorithm which outperforms qsort by A LOT for >> >> sorting an array of around 300 randomly created unsigned characters, which >> >> is what I use it for. >> >> >> >> if you read the report a guy said there's a 10% difference for sorting 3 >> >> million characters on freebsd, but there's about 40% performance >> >> difference >> >> on OpenBSD. maybe it's also how the OpenBSD team modified clang to prevent >> >> rop chain stuff or something? I'm using a westmere based intell server. >> >> >> >> it's the same for clang 11. >> >> >> >> What's the deal? >> > >> > 1. Your test is too small. I increased the test size to get less error >> > in measurement. I also changed the code to either run quicksort or >> > quicksort depending on an argument. >> > >> > 2. I confirmed your observation using time on amd64, arm64 however >> > shows a difference more in line with expectations: >> > >> > [otto@mc:8]$ time ./a.out A >> > quicksort >> > time = 0.335777021 >> > 0m00.35s real 0m00.35s user 0m00.01s system >> > [otto@mc:9]$ time ./a.out B >> > quicksort1 >> > time = 0.345703033 >> > 0m00.36s real 0m00.36s user 0m00.01s system >> > >> > >> > I suspect some non-optimal decision of the optimizer on amd64 for the >> > first quicksort. >> > >> > A next step could be somebody looking at the code produced by the >> > compiler. That is not going to be me. >> >> This is another example of code quite badly affected by fixup-gadgets. >> With an increased test size and building separate objects for each of >> the two tests and with/without CFLAGS=-fno-fixup-gadgets: >> >> $ for i in quicksort*; do echo $i; time ./$i; done >> >> quicksort >> 0m02.33s real 0m02.32s user 0m00.00s system >> quicksort-no-fixup-gadgets >> 0m01.29s real 0m01.27s user 0m00.00s system >> quicksort1 >> 0m01.06s real 0m00.94s user 0m00.02s system >> quicksort1-no-fixup-gadgets >> 0m01.08s real 0m00.87s user 0m00.01s system >> >> > > The word everyone is looking for is "tradeoff", meaning this is intentional. Yes. But we have seen fixup-gadgets making a suboptimal choice before and it was improved. Maybe there's nothing more that can be done, maybe someone proficient in X86 asm will spot something - much easier to compare the two now we know exactly what's affecting this particular code and that it can be toggled with a compiler flag.
Re: clang performance bug is worse on openbsd than freebsd
Stuart Henderson wrote: > On 2021-11-08, Otto Moerbeek wrote: > > On Sun, Nov 07, 2021 at 08:13:36PM -0600, Luke Small wrote: > > > >> https://bugs.llvm.org/show_bug.cgi?id=50026 > >> > >> I reported it to the llvm people. it is two slightly different quicksort > >> algorithms which perform radically differently. The one which you could > >> assume would take more time, performs MUCH better. > >> > >> I made a custom quicksort algorithm which outperforms qsort by A LOT for > >> sorting an array of around 300 randomly created unsigned characters, which > >> is what I use it for. > >> > >> if you read the report a guy said there's a 10% difference for sorting 3 > >> million characters on freebsd, but there's about 40% performance difference > >> on OpenBSD. maybe it's also how the OpenBSD team modified clang to prevent > >> rop chain stuff or something? I'm using a westmere based intell server. > >> > >> it's the same for clang 11. > >> > >> What's the deal? > > > > 1. Your test is too small. I increased the test size to get less error > > in measurement. I also changed the code to either run quicksort or > > quicksort depending on an argument. > > > > 2. I confirmed your observation using time on amd64, arm64 however > > shows a difference more in line with expectations: > > > > [otto@mc:8]$ time ./a.out A > > quicksort > > time = 0.335777021 > > 0m00.35s real 0m00.35s user 0m00.01s system > > [otto@mc:9]$ time ./a.out B > > quicksort1 > > time = 0.345703033 > > 0m00.36s real 0m00.36s user 0m00.01s system > > > > > > I suspect some non-optimal decision of the optimizer on amd64 for the > > first quicksort. > > > > A next step could be somebody looking at the code produced by the > > compiler. That is not going to be me. > > This is another example of code quite badly affected by fixup-gadgets. > With an increased test size and building separate objects for each of > the two tests and with/without CFLAGS=-fno-fixup-gadgets: > > $ for i in quicksort*; do echo $i; time ./$i; done > > quicksort > 0m02.33s real 0m02.32s user 0m00.00s system > quicksort-no-fixup-gadgets > 0m01.29s real 0m01.27s user 0m00.00s system > quicksort1 > 0m01.06s real 0m00.94s user 0m00.02s system > quicksort1-no-fixup-gadgets > 0m01.08s real 0m00.87s user 0m00.01s system > > The word everyone is looking for is "tradeoff", meaning this is intentional.
Re: clang performance bug is worse on openbsd than freebsd
On 2021-11-08, Otto Moerbeek wrote: > On Sun, Nov 07, 2021 at 08:13:36PM -0600, Luke Small wrote: > >> https://bugs.llvm.org/show_bug.cgi?id=50026 >> >> I reported it to the llvm people. it is two slightly different quicksort >> algorithms which perform radically differently. The one which you could >> assume would take more time, performs MUCH better. >> >> I made a custom quicksort algorithm which outperforms qsort by A LOT for >> sorting an array of around 300 randomly created unsigned characters, which >> is what I use it for. >> >> if you read the report a guy said there's a 10% difference for sorting 3 >> million characters on freebsd, but there's about 40% performance difference >> on OpenBSD. maybe it's also how the OpenBSD team modified clang to prevent >> rop chain stuff or something? I'm using a westmere based intell server. >> >> it's the same for clang 11. >> >> What's the deal? > > 1. Your test is too small. I increased the test size to get less error > in measurement. I also changed the code to either run quicksort or > quicksort depending on an argument. > > 2. I confirmed your observation using time on amd64, arm64 however > shows a difference more in line with expectations: > > [otto@mc:8]$ time ./a.out A > quicksort > time = 0.335777021 > 0m00.35s real 0m00.35s user 0m00.01s system > [otto@mc:9]$ time ./a.out B > quicksort1 > time = 0.345703033 > 0m00.36s real 0m00.36s user 0m00.01s system > > > I suspect some non-optimal decision of the optimizer on amd64 for the > first quicksort. > > A next step could be somebody looking at the code produced by the > compiler. That is not going to be me. This is another example of code quite badly affected by fixup-gadgets. With an increased test size and building separate objects for each of the two tests and with/without CFLAGS=-fno-fixup-gadgets: $ for i in quicksort*; do echo $i; time ./$i; done quicksort 0m02.33s real 0m02.32s user 0m00.00s system quicksort-no-fixup-gadgets 0m01.29s real 0m01.27s user 0m00.00s system quicksort1 0m01.06s real 0m00.94s user 0m00.02s system quicksort1-no-fixup-gadgets 0m01.08s real 0m00.87s user 0m00.01s system
