From nobody Wed Jan 25 23:34:18 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P2KtL2vDRz3bn2r; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P2KtL1xRyz4JXb; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674689658; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s+b1IDJwrBhAD/HexYFAHOcN+juSI+cmVtxpKcW9cjQ=; b=CbgDhZ5lNe4U4z0+sQBEhfvZyDq23oMqlG4d3Q30ucj+Smai30aFN9GK6vwut9+USKsJRt qLK4o4TmVOUCfHGR90chbwBjzlojqE4AHQrUlgkH9zCOVQb+iREnVd5zKWapYCk7FMlxTw 7AmGtEwijhOIX98cfEMXFoUmWJVLIZ/AbTgUi1lt26Sd853FNG9QW3a1w3p+HlmJb00rjp y5toaefRi8tObEuUWKncUytz+xSSHx8K74pXQaxswX9VR/BVEAF9JnqyVWKr5qL/4WD6+C BbcV61DW4YCtQ8ooElejJUQpYLT2vgXkxHNGPfBCnqYbKgJZ7OuqTqxjbtkUCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674689658; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s+b1IDJwrBhAD/HexYFAHOcN+juSI+cmVtxpKcW9cjQ=; b=mVeusdtEtNTECdqV9qEMFYrBuqq+UZPwnwjuQmgAC1IC0vFqGQw5wDfXhoWnWoEilLLnnz iBrGUwEc2R8krIuq2sNERRG5YzCl633IgWId8zWffnzOsgwllgqFOxqU+0cWSunHWKksJn sKlsxtrql4A8FpBWr4/5K7JZMMQICvyKsNpQHOQSvSyDBOAm1zNKoQ4RDAD/jPWukzfcp7 bylaSmXu5QXWyvDTQe4lsKdbmmebN0XEfuujxOjie+69uhyY5BB5o8plh43aBOfpsRgpq2 F7tHASF08A+kBVD5URmPma081xyQ+ItBT37qFjBaKVHwsh+Coo5gPRhpnmNNnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674689658; a=rsa-sha256; cv=none; b=UGR38/LNH44L5fy3YNZEczLvficNeRJugKDaz+ossii6Rv9DBcNPNinAtXWi6a5+R80LXc MYprimCPy8Nj90lrxoiCvgZu1qFoooA6cIZmAU63e6hnQfE66fmfsacG2t5wb9wizdY/I1 9IjwjRczWCqgwqG/zl7ZcQzvsHrIo/JN++cJzlwaD2c8ginfZ8vGhz/gfX7Sq2m1Udmgcj RGJhh7Ux22XYhMwGebasNkqmlJnT+6PKJ94S6GVfE5HcsK1G/SRdYKKWfpw1fhYlS2o9Mj 6uWBtvvKeeSCo42Jpe6l7zDRvi2amHqfrvRtcIIiLVv0FtpTpdRh7x1oCaR73Q== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 22A1E9F3D; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) Date: Wed, 25 Jan 2023 23:34:18 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Fourth Quarter 2022 Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N FreeBSD Status Report Fourth Quarter 2022 The New Year has started and here is the last status report of 2022, including 34 reports. You will also notice that for the first time a new category has been introduced: the Cloud category. As FreeBSD keeps up to date with the latest technologies in IT, projects dealing with the cloud make steady improvements, and thus it has been judged that they deserve their own category in the status reports. The new category is not the only change about status reports. Indeed, the status team is revisiting its own workflow to become more efficient. If you are a report submitter, please ensure to read carefully the report authored by the status team as well as the next Call for Reports emails to keep up with the most recent changes. Have a nice read. Lorenzo Salvadore, on behalf of the status team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2022-10-2022-12/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection □ Status reports: New workflow • Projects □ Console screen reader infrastructure □ Vessel - Integrated Application Containers for FreeBSD □ Enable the NFS server to run in a vnet prison □ Pytest support for the FreeBSD testing framework • Userland □ Base System OpenSSH Update • Kernel □ Enabling Snapshots on Filesystems Using Journaled Soft Updates □ Wireless updates □ Netlink on FreeBSD □ Adding basic CTF support to ddb • Architectures □ CheriBSD 22.12 release □ FreeBSD/riscv64 Improvements □ go on FreeBSD riscv64 □ FreeBSD/ARM64 on Xen • Cloud □ FreeBSD on Microsoft HyperV and Azure □ FreeBSD as a Tier 1 cloud-init Platform □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team □ FreeBSD Presentations and Papers • Ports □ FreshPorts - help wanted □ PortsDB: Program that imports the ports tree into an SQLite database □ KDE on FreeBSD □ Xfce on FreeBSD □ Pantheon desktop on FreeBSD □ Budgie desktop on FreeBSD □ GCC on FreeBSD □ Another milestone for biology ports • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Items Core Team Charter A delegation of the current core team is working together with some members of the previous Core Team to draft a core team charter. There was a face-to-face meeting in the US on December 3 - 4 to discuss the new charter. The delegation will present to the rest of the core team and discuss the details in the first quarter of 2023. The same delegation also had a meeting with the FreeBSD Foundation board on December 5th to discuss the collaboration details. Experimental Matrix IM solution The core team is working on evaluating Matrix as an instant messaging tool for the project. This will make the project’s communication channels less dependant on third parties. The service will be made available to the FreeBSD community to test and evaluate its validity at a later date. Committer’s Guide Deprecate BSD-2-Clause-FreeBSD and use BSD-2-Clause. For more information please refer to the commit. Commit bits • Core approved the src commit bit for Zhenlei Huang (zlei@) • Core approved the src commit bit for Corvin Köhne (corvink@) • Core approved the src commit bit for Sumit Saxon (ssaxena@) • Core approved the restore of the source commit bit for Paweł Jakub Dawidek (pjd@). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.freebsdfoundation.org Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://www.freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://www.freebsdfoundation.org/journal/ Foundation News and Events URL: https://www.freebsdfoundation.org/news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Fundraising Efforts Thank you to everyone who made a financial contribution in 2022! We’re still tallying up the totals and will have final numbers soon. Unfortunately, we did not meet our fundraising goal, which reinforced our need of having someone who can focus on encouraging organizations to invest in FreeBSD. We will bring someone on board soon to help with that effort. In this Quarterly Status report you’ll read about many of the areas we funded in Q4 to improve FreeBSD and advocate for the Project (the two main areas we spend money on). Check out reports on the internally and externally funded projects like Openstack on FreeBSD, Enabling Snapshots on Filesystems Using Journaled Soft Updates, FreeBSD as a Tier 1 cloud-init Platform, and FreeBSD/ riscv64 Improvements. In addition, we provided tons of community engagement and education opportunities virtually and in-person! If you want to help us continue our efforts, please consider making a donation towards our 2023 fundraising campaign! https://www.freebsdfoundation.org/donate/ We also have a Partnership Program for larger commercial donors. You can read about it at https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. OS Improvements During the last quarter of 2022, 218 src, 45 ports, and 12 doc tree commits identified the Foundation as a sponsor. Work was committed under Foundation sponsorship to repositories outside of FreeBSD as well, e.g., to the cloud-init project. Some of this sponsored work is described in separate report entries: • FreeBSD as a Tier 1 cloud-init Platform • OpenStack on FreeBSD project update • Wireless Report • Enabling Snapshots on Filesystems Using Journaled Soft Updates Other Foundation work in the src tree included: • a variety of additions and fixes from Konstantin Belousov including commits to the virtual memory system (e.g., ec201dd, cd08669, and d537d1f), and file systems (e.g., 37aea26, 83aff0f, 860399e, and 4d903a1) • work from Andrew Turner on arm64 such as an implementation of per-superpage locks and the addition of support for an array of hwresets • more RISC-V improvements from Mitchell Horne, including improvements to parsing of ISA property strings, optimizations to memory allocation, and various documentation additions and improvements • follow-up commits to Mark Johnston’s work to add ZFS Support to makefs(8) (e.g., work to easily provide ZFS-based VM and cloud images and automation for better defaults from Li-Wen Hsu) • a variety of work from Ed Maste, including an ssh update and a switch to LLVM objdump. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. You can read about the latest activity for that work in a separate report entry. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature and video tutorials, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are continuing to attend events both in person and virtual as well as planning the November Vendor Summit. In addition to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: • Sponsored the OpenZFS Developer Summit, October 24-25, 2022 in San Francisco, CA • Sponsored All Things Open, October 30-November 2, 2022 in Raleigh, NC • Sponsored and helped organize the November 2022 FreeBSD Vendor Summit. Videos from the Summit are available. • Held a new FreeBSD Friday: An Introduction to FreeBSD Services by Drew Gurkowski • Published the Fall and Winter Newsletter updates • New Blog Posts □ Meet the 2022 FreeBSD Google Summer of Code Students: Koichi Imai □ Meet the 2022 FreeBSD Google Summer of Code Students: Bojan Novković □ Keeping FreeBSD Secure: Learn the Whys and Hows with the FreeBSD Sec Team □ The FreeBSD Journal is still Free! □ EuroBSDCon 2022 Trip Report: Muhammad Moinur Rahman □ EuroBSDCon 2022 Trip Report: Patrick McEvoy □ Fall Foundation Software Development Update □ Invest in FreeBSD □ 2022 in Review: Advocacy □ Foundation Sponsors Update to WireGuard Kernel Port for FreeBSD □ 2022 in Review: Fundraising Update □ 2022 in Review: Software Development □ 2022 in Review: Continuous Integration and Quality Assurance Update • FreeBSD in the news: □ Ampere: Getting Cloud-Native with FreeBSD on OCI Ampere A1 with Terraform □ FreeBSD is Well Supported on 4th Gen AMD EPYC™ Processors • For a quick review of all the Foundation efforts in 2022, check out our 2022 Thank You Video. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.freebsdfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.freebsdfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 12.4-RELEASE schedule URL: https://www.freebsd.org/releases/12.4R/schedule/ FreeBSD 12.4-RELEASE announcement URL: https://www.freebsd.org/releases/12.4R/announce/ FreeBSD 13.2-RELEASE schedule URL: https://www.freebsd.org/releases/13.2R/schedule/ FreeBSD 14.0-RELEASE schedule URL: https://www.freebsd.org/releases/14.0R/schedule/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the fourth quarter of 2022, the Release Engineering Team completed work on the 12.4-RELEASE cycle. This is the final release from the stable/12 branch. During the release cycle, only one BETA build and two RC (release candidate) builds were needed; overall the release cycle went very smoothly and the release took place on December 5th. During the fourth quarter of 2022, the Release Engineering Team continued providing weekly development snapshot builds for the main, stable/13, and stable/12 branches. In the first quarter of 2023, the Release Engineering Team will start work on the upcoming 13.2-RELEASE. Sponsors: Rubicon Communications, LLC ("Netgate") The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: • Regular cluster-wide software upgrades Two full upgrades to fix and prevent some impacting issues (FreeBSD-EN-22:25.tcp and FreeBSD-EN-22:28.heimdal). • Regular support for FreeBSD.org user accounts • Regular disk and parts support (and replacement) for all physical hosts and mirrors. • Site audit at our primary site □ Inventory of spares and other miscellanea occupying space in our cabinets. □ Inventory of PDUs/power outlet usage and identifying faulty PSUs. • Identify and fix major DNS issue impacting the project The primary DNS servers hosted on HE.net suffered outages for a few days, and new DNS servers were deployed worldwide. We thank our sponsor Metapeer for providing anycast infrastructure. • Deploy a new mirror in Frankfurt, Germany A replacement for our mirror in Amsterdam (site decommissioned). Former and new mirror hosted and sponsored by Equinix. • Reuse parts of three broken CI machines No replacements for these at this moment, awaiting a cluster refresh soon. • Work with the PowerPC team to improve the PowerPC cluster machines □ Parts like mainboard, NVMe and Power 9 CPU bought through the FreeBSD Foundation. □ Former package builder fixed, and re-deployed as powerpc and powerpc64 package builder. □ Former devref machine reinstalled as a new powerpc64le package builder. □ The cluster has now only these two PowerPC machines in operation. • Several rounds to free up disk space usage in the cluster machines • Setup of an experimental search engine for the mailing lists: https://lists.freebsd.org/search • Fix a bug in the mailing lists archiver, which resulted in some broken links All mailing lists archives have been regenerated. Work in progress: • Large-scale network upgrade at our primary site New Juniper switches arrived at our primary site to replace the former ones. We thank Juniper for the donation. • Replace old servers in our primary site and a few mirrors Besides the broken CI servers, we have a few old servers with broken disks and faulty PSUs. This task is in conjunction with the FreeBSD Foundation and donors/sponsors. • Create a new database for the mailing list search engine to allow searching for mail in the archives from mailman’s time FreeBSD Official Mirrors Overview: Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Taiwan, United Kingdom (full mirror site), United States of America (California, New Jersey [the primary site], and Washington). The hardware and network connection have been generously provided by: • Bytemark Hosting • Cloud and SDN Laboratory at BroadBand Tower, Inc • Department of Computer Science, National Yang Ming Chiao Tung University • Equinix • Internet Association of Australia • Internet Systems Consortium • INX-ZA • KDDI Web Communications Inc • Malaysian Research & Education Network • Metapeer • New York Internet • Nic.br • Your.org The Frankfurt single server mirror is now the primary Europe mirror in bandwidth and usage. We are still looking for an additional full mirror site (five servers) in Europe to replace old servers in the United Kingdom full mirror site. We see a good pattern in having single mirrors in Internet Exchange Points worldwide (Australia, Brazil, and South Africa); if you know or work for some of them that could sponsor a single mirror server, please get in touch. United States (West Coast) and Europe (anywhere) are preferable places. See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.FreeBSD.org/Jenkins Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. During the fourth quarter of 2022, we continued working with the contributors and developers in the project to fulfill their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important completed tasks: • FreeBSD-main-amd64-gcc9_build now sends failing reports to the committers whose commits may be related. • FreeBSD-main-amd64-gcc12_build has been added. • FreeBSD-main-powerpc64-images now also builds bootable APM disk image for Apple G5 baremetal and QEMU -M mac99 (by alfredo@) Work in progress tasks: • Designing and implementing pre-commit CI building and testing (to support the workflow working group) • Designing and implementing use of CI cluster to build release artifacts as release engineering does • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Organizing the scripts in freebsd-ci repository to prepare for merging to src repository • Improving the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Adding more external toolchain related jobs • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don’t hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages (through its subsidiary pkgmgr), and personnel matters. Below is what happened in the last quarter. Currently we have just over 31,000 ports in the Ports Tree. There are currently close to 2900 open ports PRs of which almost 800 are unassigned. The last quarter saw 8194 commits by 159 committers on the main branch and 657 commits by 53 committers on the 2022Q4 branch. Compared to the quarter before, this means a small increase in the number of available ports but also in the number of open PRs and a decreasing number of commits made. On the personnel front, we welcomed Ronald Klop (ronald@) and said goodbye to bar@ and bhughes@. We welcomed pizzamig@ as a new official member after a successful lurking period. We also welcomed three new lurkers: bofh@, ler@, and ygy@. Portmgr split itself up into portmgr and pkgmgr. The new pkgmgr team, currently consisting of antoine@ and bdrewery@, is responsible for building packages and maintaining the package building cluster. Four new USES were introduced: • llvm to canonicalize ports dependencies on LLVM • luajit to select a LuaJIT runtime • octave to help ports depend on Octave and Octave-Forge • tex to define dependencies on TeX and its various components. The following default versions were bumped: • Firebird to 3.0 • GCC to 12 • Lazarus to 2.2.4 • Lua to 5.4 • PHP to 8.1 • Samba to 4.13 • Varnish to 6 • LuaJIT is new and set at "luajit-openresty" for PowerPC64 and "luajit-devel" for all other architectures. Three new features were introduced, PIE, RELRO, and BIND_NOW. Each port can opt out of them by setting the _UNSAFE variable. Users can activate or deactivate them globally by setting WITH_ or WITHOUT_. The following major ports were updated to new versions: • Chromium 108.0.5359.124 • Electron 18.3.11, 19.0.15, and 21.2.0 • Firefox 108.0.1 • Firefox-ESR 102.6.0 • gcc 12 • KDE Plasma 5.24.7, Frameworks 5.101.0, Applications 22.12.0 • Qt 5.15.7 and 6.4.1 • Rust 1.66.0 • SDL 2.26.1 • Sway 1.8 • wlroots 0.16.1 • Wine 7.0.1. The exp-run reports are available again. During the last quarter, antoine@ ran 38 exp-runs to: • test port updates • change default versions • identify use of IPPROTO_DIVERT in ports • support PF_DIVERT in Python for FreeBSD 14. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Status reports: New workflow Links: FreeBSD status reports URL: https://www.freebsd.org/status/ Status reports GitHub repository URL: https://github.com/freebsd/freebsd-quarterly Contact: Goals of the new workflow This quarter the status team has been discussing with doceng@ some improvements to its workflow. In particular, the team is attempting to merge its GitHub repository into the FreeBSD doc/ repository. Here are the reasons for such a change: • having two independent repositories requires spending some time to make sure that both are in sync, which is being done manually. See for example commits such as https://github.com/freebsd/freebsd-quarterly/commit/4b8255e604dd0513e841aa8f3dce7741e78b999c, which are not immediately clear in their commit messages about what is being done unless more time is invested to copy commit messages properly; • the FreeSD doc/ repository is self-hosted, while the status repository is hosted on GitHub. Since the contents of the self-hosted repository are mirrored, nothing is being lost in visibility with the repository merging. Some inconsistencies about the name of the team have also been found: the team has been referred to as "quarterly", "quarterly status team", "status", "status team", "monthly" etc. So this issue is also being addressed. Please note that we are still working on these changes and that they might not be completed within the next quarter. The status team will take care to keep all information about report submissions up to date so that you always know how to submit your reports. Team naming Since "quarterly" might refer to quarterly reports but also to quarterly branches, using "quarterly" only could cause some confusion in some contexts. "quarterly-status" is likely a bad idea as well, as the frequency of reports publication might need to change in the future. Thus just "status" has been chosen: this is correct as quarterly status reports contain information about the status of the development of FreeBSD, it is frequency-agnostic and consistent with its FreeBSD website section. The following email addresses have been created: • the main contact address for the status team is now . Mails sent to quarterly@FreeBSD.org will still reach the team, but you are encouraged to use the new address; • the email address for the status report submissions is now < status-submissions@FreeBSD.org>. Mails sent to quarterly-submissions@FreeBSD.org will still reach the team, but you are encouraged to use the new address; • the quarterly-calls mailing list has been renamed to status-calls. If you were already subscribed to quarterly-calls, you do not need to resubscribe. Report submission Three different ways to submit reports will be provided: • submitting a review on Phabricator. A new Phabricator group called "status" has been created. If you would like to give a hand to the team by reviewing reports we suggest you add yourself to the group 'watchers'; • submitting a pull request at https://github.com/freebsd/freebsd-doc/pulls; • sending an email to status-submissions@FreeBSD.org. Reviewing processes will proceed as they usually do on each of these channels. Other changes • The repository merging will require reworking some of the existing tools to better integrate with the existent structure of the FreeBSD doc/ repository. • The status reports GitHub repository will be archived once the new workflow implementation is completed. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Console screen reader infrastructure Links: console speaker daemon URL: https://reviews.freebsd.org/D35776 kernel support for console screen reader URL: https://reviews.freebsd.org/D35754 base system accessibility wishlist URL: https://wiki.freebsd.org/Accessibility/Wishlist/Base Contact: Hans Petter Selasky Contact: FreeBSD accessibility discussions This project aims at providing a very basic screen reader usable in console mode (without a GUI) for FreeBSD. This is an important first step for system administrators using speech to access computers, who previously would have needed a second computer running a terminal emulator to install or configure a FreeBSD server or character-based desktop computer. The third and fourth quarters of 2022 saw basic design and some feature testing which looks promising, and a detailed call for testing with installation procedure posted. This project needs help with the following: • Code reviewing • Usability testing • Integrating with the FreeBSD installer. Sponsor: NVIDIA Networking (for the kernel development part) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Vessel - Integrated Application Containers for FreeBSD Links: Vessel URL: https://github.com/ssteidl/vessel Contact: Shane Steidley What is Vessel? The goal of vessel is to expose the many powerful features of FreeBSD to application developers. Vessel accomplishes this goal by: • Providing a "Docker-like" interface familiar to most application developers for building, running, publishing and pulling container images. • Tightly integrating with FreeBSD system level interfaces (kqueue process tracing, signal handling, devd.seqpacket, rctl, cpuset) to manage running jails. How is Vessel different from other jail management systems? There are some awesome jail management systems already. These existing systems do a great job of configuring the jail runtime environment (ZFS dataset, networking, resource control, etc). After the environment is configured though, it is just handed off to the jail program via an exec call. In addition to jail configuration and creation, Vessel aims to take the next step and implement an event loop to manage jails based on system events. An instance of vessel runs alongside each jail to assist with management. This allows "Fat Jails" and single process jails to run in the foreground and be managed by the vessel-supervisor. Why make Vessel? Vessel has been a side project for a few years. I initially started it because it was a fun hobby project and I was surprised something similar did not already exist. It has now become a viable tool that I use for all of my projects. I believe it will be useful to others as well. Is help needed? Help is always appreciated. It’s a fun project to work on because it can touch on so many portions of FreeBSD. • Just using it and reporting any bugs on GitHub would be very useful. • Whatever sounds fun. I’m happy to help get people started. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Enable the NFS server to run in a vnet prison Links: Source patch for main URL: https://people.freebsd.org/~rmacklem/vnet.patch Simple Setup Doc URL: https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt Contact: Rick Macklem Several users of FreeBSD identified a need to run the NFS server inside a vnet prison. This turned into a small project, where I now have a patch that does this. It is currently available at the above link for testing or on Phabricator as D37519. Without this patch, the NFS server cannot be run in a prison. Not included in the above patch is the ability to run the rpc.tlsservd(8) and nfsuserd(8) daemons within the vnet prison. I do now have patches that allow these daemons to run in the vnet prison along with mountd(8) and nfsd(8), but I would like to get the above patch into main before adding support for rpc.tlsservd(8) or nfsuserd(8). At this time, the code needs reviewing and testing. Hopefully this can be completed in the next few weeks, so that the patch can be committed to main and possibly also MFC’d to stable/13. To do • Testing the above patch. • Reviewing the above patch. • Doing the same for the rpc.tlsservd(8) and nfsuserd(8) patches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pytest support for the FreeBSD testing framework Links: Initial review URL: https://reviews.freebsd.org/D31084 Test examples URL: https://cgit.freebsd.org/src/tree/tests/examples/test_examples.py Contact: Alexander Chernikov Native pytest support for atf(7) enhances the capabilities of the FreeBSD test suite. Pytest simplifies test writing by reducing the amount of boiler-plate code. It offers several advantages over the existing atf-c and atf-shell bindings. One of the most important ones is the test parametrization, which allows improving coverage with writing nearly no code. The other is a rich assert system, offering detailed errors description. Python atf(7) support comes with a number of libraries that abstract a number of commonly-used tasks. For example, running a test within a VNET jail with epair(4) requires adding a single line of code. Such helpers are especially handy in the networking area, where tests with complex VNET setups are not uncommon. Current status Python support has been committed to HEAD. Currently, ~80 tests use the Python framework and the number is rising. Example tests have been committed to show the handling of the typical cases. Next steps • Work on increasing the adoption of the framework • Rewrite some of the older Python/shell tests in the netinet[6] to pytest (help is appreciated) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Base System OpenSSH Update Links: OpenSSH URL: https://www.openssh.com/ OpenSSH 9.1 release notes URL: https://www.openssh.com/txt/release-9.1 Contact: Ed Maste OpenSSH, a suite of remote login and file transfer tools, was updated from version 9.0p1 to 9.1p1 in the FreeBSD base system. It has been merged to the stable branches, is available in FreeBSD 12.4, and will be in the upcoming FreeBSD 13.2. A number of bug fixes and minor improvements have been submitted upstream to OpenSSH, and this process will continue with subsequent updates. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. Enabling Snapshots on Filesystems Using Journaled Soft Updates Links: Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491 Contact: Kirk McKusick The goal of this project is to make UFS/FFS filesystem snapshots available when running with journaled soft updates. First a bit of background. Soft updates have been available for UFS/FFS since the mid 1990s. They eliminate the need for most synchronous disk writes and keep the state of the filesystem sufficiently consistent that it can be put back online after a crash without the need to run fsck(8). However, it may incorrectly assume that some of its blocks are still in use when in fact they are free. So, eventually it is necessary to take the filesystem offline to run fsck(8) to reclaim these lost blocks. The time to run fsck(8) is a function of the number of files in the filesystem and the size of the filesystem. Large filesystems may take hours to complete an fsck(8). Enabling journaling reduces the time spent by fsck(8) cleaning up a filesystem after a crash to a few seconds. With journaling, the time to recover after a crash is a function of the amount of activity in the filesystem in the minute before the crash. Journaled recovery time is usually only a few seconds and never exceeds a minute. The drawback to using journaling is that the writes to its log add an extra write load to the media containing the filesystem. Thus a write-intensive workload will have reduced throughput on a filesystem running with journaling. Like all journaling filesystems, the journal recovery will only fix issues known to the journal. Specifically if a media error occurs, the journal will not know about it and hence will not fix it. Thus when using journaling, it is still necessary to run a full fsck every few months or after a filesystem panic to check for and fix any errors brought on by media failure. A full fsck(8) is normally done on an offline filesystem. However, it can be done by running fsck(8) on a snapshot of a live filesystem. When running fsck (8) in the background on a live filesystem, the filesystem performance will be about half of normal during the time that the background fsck(8) is running. Running a full fsck on a UFS filesystem is the equivalent of running a scrub on a ZFS filesystem. The first milestone of this project has been completed. It is now possible to take snapshots when running with journaled soft updates and they can be used for doing background dumps on a live filesystem. The second milestone of this project is to extend fsck(8) to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. This milestone is expected by Q3 of 2023. Sponsored by: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless updates Links: Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org/~bz/wireless/ Contact: Bjoern A. Zeeb During the quarter not much work was publicly visible and admittedly slightly slow. Behind the scenes wireless work was happening on two fronts: • 11n, 11ac, and wpa, • more drivers and firmware, problems, testing, and filling gaps for these. While the main development for newer standards and the Intel iwlwifi driver is sponsored by the FreeBSD Foundation, I find myself spending a lot of private time with Realtek rtw88 and rtw89, Atheros, and Mediatek mt76 (7921 and 7915) drivers now as well. Testing changes on bare metal and using bhyve VMs using passthru has become more time-consuming, with the amount of supported chipsets increasing, in order not to break other drivers. Even different (generations of) chipsets supported by the same driver, at times, behave differently with the same change. A separate discussion was brought to me about the size of firmware added to the tree for the already existing drivers and the firmware for more drivers coming. The chicken-egg problem to solve is having firmware available on the release media; without firmware, a lot of modern laptops will not have any sort of outside communications available at the time of install in their default configuration. This will be a larger discussion to have to also solve firmware for other drivers, but that discussion will be for another day and place. Slightly belatedly I have started to push LinuxKPI and 802.11 changes into the tree at the end of the year and that work will continue into early 2023 at which point more of the aforementioned remaining drivers will also hit the tree. One of the main remaining problems to solve is the firmware crashes on interface down/up cycles currently experienced with at least two drivers. Thankfully during the last weeks, after my call for help, multiple people have stood up wanting to help with various drivers (especially Realtek and Mediatek). I hope that after me catching up and pushing things out this can accelerate progress again. Thanks again to everyone doing testing, providing debug output, sending in feedback, or using the drivers at this point. For the latest state of the development, please use the freebsd-wireless mailing list, and check the landing page, which has links to all wiki pages for each driver status. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Netlink on FreeBSD Links: Initial review URL: https://reviews.freebsd.org/D36002 Netlink talk URL: https://static.ipfw.ru/files/netlink.pdf Contact: Alexander Chernikov Netlink is a communication protocol defined in RFC 3549. It is an async, TLV-based protocol, providing 1-1 and 1-many communications between kernel and userland. Netlink is currently used in the Linux kernel to modify, read and subscribe for nearly all networking states. Interface state, addresses, routes, firewall, rules, fibs, etc, are controlled via Netlink. Why is Netlink important for FreeBSD? POSIX defines an API for base functions/system calls. There is no such standard for the plethora of protocol/device-level/subsystem-level ioctls. Each subsystem/driver invents its own protocol, handling format and compatibility. Extendability is a notable problem in the networking control plane. For example, it is extremely hard to add properties to the routing socket messages without breaking compatibility. Netlink offers unification by providing a standard communication layer and basic easily-extendable message formatting. It can serve as a "broker", automatically combining requested data from different sources in a single request (example: interface state dump). Netlink APIs lower the bar for application developers to support FreeBSD, while providing the desired extendability. Current status Netlink has been committed to HEAD. The code implements a subset of the NETLINK_ROUTE subsystem and NETLINK_GENERIC framework. NETLINK_ROUTE supports add/delete/replace operations for routes, nexthops and link-level addresses. Partial support exists for the interface addresses and interfaces. Linuxulator support for Netlink has been committed to HEAD. It is possible to use the unmodified ip from iproute2 with routes, nexthops, addresses and interfaces. The simple userland library, snl(3), that provides convenient abstractions on the netlink socket, has been committed to HEAD. The first third-party software, BIRD, added experimental FreeBSD Netlink support. Next steps • Add Netlink to GENERIC • Make netstat/route/arp/ndp/ifconfig use Netlink interfaces (help is appreciated) • Add FreeBSD Netlink support to ports of FreeRangeRouting (FRRouting (FRR)). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Adding basic CTF support to ddb Links: Differential 1 URL: https://reviews.freebsd.org/D37898 Differential 2 URL: https://reviews.freebsd.org/D37899 Contact: Bojan Novković The goal of this project was to extend the ddb kernel debugger to use the kernel’s Compact C Type Format (CTF) data and use the newly added features to implement a pretty-printing command in ddb. Due to a restrictive execution environment (no IO or memory allocation), ddb can not use existing kernel linker methods to retrieve the kernel’s CTF data. Instead, the first patch adds the ability to load the kernel’s CTF data during boot and adds a new kernel linker method used for accessing CTF data from ddb. The second patch adds a basic interface for using CTF data in ddb and a pretty-printing command built using the newly added interfaces. Any feedback, comments, and reviews are welcome and would be greatly appreciated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for the new hardware platform. CheriBSD 22.12 release Links: CheriBSD URL: https://www.cheribsd.org CheriBSD Announcements list URL: https://lists.cam.ac.uk/sympa/info/cl-cheribsd-announce Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: George Neville-Neil Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction-set extensions. There are two active architectural implementations of the CHERI protection model: CHERI-RISC-V and Arm’s Morello. A sketch of CHERI-x86 is also under development. CheriBSD is a research operating system with a stable baseline implementation into which various new research features have been, or are currently being, merged. We have published the 22.12 release of CheriBSD including: • A general update of the baseline FreeBSD OS to August 2022. • Memory-safe adaptation of Direct Rendering Manager (DRM) and Panfrost device driver, which enable a Morello-based desktop system using on-board GPU and HDMI. These drivers may be used with hybrid or pure-capability kernels. • An initial set of graphics and desktop CheriABI software packages such as Wayland and portions of KDE to get you up and running with a memory-safe desktop environment. These components remain under active development, and we anticipate continuing package updates after the CheriBSD release. • An early research prototype of library-based compartmentalization, which implements an alternative run-time linker running shared objects in libraries. This implementation is very much a work-in-progress, and is provided to enable research at other collaborator institutions needing easy access to the prototype. It is neither complete nor intended to be secure. • Improved pluggability of experimental heap temporal memory-safety support, which is not yet merged into the main development branch, but will now be easier to use by downloading an alternative kernel and heap allocator libraries provided by Microsoft. • An updated version of GDB with support for Morello instructions and inspecting memory tags. • Alpha support for ZFS file systems including support for boot environments. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD/riscv64 Improvements Links: Wiki Homepage URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. This quarter I resumed work on improvements to FreeBSD’s RISC-V architecture support (riscv64). Work was focused primarily on small bug-fixes and improvements, and tooling. A handful of known panics and bug reports were fixed and closed. On the performance tooling side, some issues with the use of DTrace on riscv64 were found and addressed. Specifically, backtraces produced by the stack() function were not being captured correctly. First, a change was made to the compiler flags to ensure that kernel modules always make use of the frame pointer, so that unwinding the kernel stack works as expected. Second, some tweaks were made to machine-dependent DTrace code in the profile and fbt providers, making the correct number of frames appear in each backtrace. Now, DTrace can be used to accurately capture profiling data on this platform, enabling the generation of flamegraphs. I also began porting the hwpmc(4) driver to run on this platform. Unlike other ISAs, RISC-V does not standardize the set of counter events that a CPU must support, nor are the programmable event selection registers accessible to the kernel. To work around this, there is an SBI "Performance Monitoring Unit" extension which provides an abstracted interface for managing such functionality. The new hwpmc(4) class is written to use this interface. Current generation RISC-V hardware supports incrementing performance counters, but lacks the counter overflow interrupts required to enable sampling PMCs. Work is expected to continue next quarter. Aside from the in-progress items mentioned, focus will be given to the following areas: • Support for newer OS-level extensions such as Page-Based Memory Types (Svpbmt) • Profiling system performance. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ go on FreeBSD riscv64 Links: golang Home Page URL: https://github.com/golang/go FreeBSD riscv64 github repo URL: https://github.com/MikaelUrankar/go/tree/freebsd_riscv64 FreeBSD riscv64 golang issue URL: https://github.com/golang/go/issues/53466 Contact: Mikaël Urankar Contact: Dmitri Goutnik The proposal to add support for FreeBSD riscv64 has been accepted and the patches merged. golang on FreeBSD riscv64 will be available in golang v1.20 (to be released in February 2023). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD/ARM64 on Xen Links: Xen Project URL: https://www.xenproject.org/ FreeBSD wiki page on Xen URL: https://wiki.freebsd.org/Xen Contact: Elliott Mitchell Xen is an open source hypervisor. Xen is one of the earliest hypervisors and has support for many OSes. Since FreeBSD 8.0, GENERIC FreeBSD/x86 has been able to run on Xen. Near the time FreeBSD was ported to run on Xen, work was started on running Xen on ARM. For a number of years Linux has run fine on Xen/ARM, but FreeBSD hasn’t been available. Having FreeBSD/ARM64 on Xen means any system capable of having Xen can also have FreeBSD in operation. Of note, the Raspberry PI 4B has hardware (GICv3) which Xen works with. If you’re okay with Linux handling the hardware, you can use all the hardware of a Raspberry PI 4B. In 2014 a proof of concept of running FreeBSD/ARM64 on Xen was done by Julien Grall, but this was never polished for release. During the past 2 years I’ve been working towards having this in FreeBSD’s tree, so released versions of FreeBSD/ARM64 would run on Xen. At this point all changes which need to be shared with the x86 Xen source code have been reviewed (not all reviews are on Phabricator). This now awaits testing by Roger Pau Monné before being committed to FreeBSD’s tree. I now urgently need someone with a high level of familiarity with the interrupt subsystem of FreeBSD on ARM64 to review (and commit) the ARM-specific portions. My builds are functional far more often than they fail, and most failures are temporary problems in FreeBSD’s tree. Some significant issues will need to be addressed regarding FreeBSD’s interrupt subsytem. There is substantial hope of having FreeBSD/ARM64 available for "DomU" (unprivileged) operation for FreeBSD 14.0. There is potential for FreeBSD/ARM and FreeBSD/RISC-V to run on Xen in short order. No plans currently exist for having FreeBSD/ARM64 operating as the controlling VM (someone could try to sponsor this). Thanks Thanks to Julien Grall for the Proof of Concept. Thanks to Roger Pau Monné for reviewing changes involving x86. Thanks to Mitchell Horne for helping with various FreeBSD/ ARM64 issues and addressing a key problem with FreeBSD/ARM64. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Li-Wen Hsu In this quarter, the 12.4-RELEASE image has been published to Azure Marketplace. Work in progress tasks: • Automating the image building and publishing process and merge to src/ release/. • Building and publishing ZFS-based images to Azure Marketplace □ All the required codes are merged to main branch, and can create ZFS-based images by specifying VMFS=zfs. □ Need to make the build process more automatic and collaborating with release engineering to start generating snapshots. • Building and publishing Hyper-V gen2 VM images to Azure Marketplace □ Blocked by https://bugs.freebsd.org/264267 The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft. Wei Hu and his colleagues in Microsoft are working on several tasks sponsored by Microsoft: • Fixing booting issue on Hyper-V gen2 VM in Azure □ https://bugs.freebsd.org/264267 • Porting Hyper-V guest support to aarch64 □ https://bugs.freebsd.org/266248 □ https://bugs.freebsd.org/267654 Open tasks: • Update FreeBSD related doc at https://docs.microsoft.com • Support FreeBSD in Azure Pipelines • Update Azure agent port to the latest version • Upstream local modifications of Azure agent Sponsor: Microsoft for work by Wei Hu and others in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD as a Tier 1 cloud-init Platform Links: cloud-init Website URL: https://cloud-init.io/ cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/ cloud-init ongoing refactorization URL: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux is rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs. The first milestone has been delivered. Along with many bug fixes, we now have merged an ifconfig(8) parser, which allows us to retrieve all the information of all network devices, similarly to how on Linux this is done by parsing the contents of /sys/class/net//. In the coming weeks, this project will align itself with the Azure developers to do some crucial refactoring. This will move our new parser further into cloud-init’s main execution paths. People interested in helping with the project can help with testing new features and fixes through net/cloud-init-devel, which will be updated whenever we make significant commits. Further, people with access to, and experience with, OpenBSD and NetBSD are also highly welcome to help. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu OpenStack is an open-source cloud operating system for different resource types like virtual and bare-metal machines. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible to run the OpenStack control plane on FreeBSD hosts. This project aims to port key OpenStack components so that FreeBSD can function as an OpenStack host. In 2022 Q4, we have almost completed the porting work regarding the crucial OpenStack components. Most of the components/services composing an essential OpenStack cluster are now able to run on FreeBSD hosts, including: • Keystone (identity service) □ keystone server • Glance (image service) □ glance-api • Placement (resource tracking and inventory service) □ placement-api • Neutron (networking service) □ neutron-server □ neutron-metadata-agent □ neutron-dhcp-agent □ neutron-openvswitch-agent • Nova (compute service) □ nova-api □ nova-conductor □ nova-scheduler □ nova-compute □ nova-novncproxy The step-by-step documents for constructing a POC can be found in the docs repository. In its design, most of the OpenStack components provide an abstraction layer for the underlying implementations. For nova, we choose the combination of the libvirt driver with the bhyve virtualization type enabled. For neutron, it is the openvswitch mechanism driver. We solved several runtime dependencies and porting issues against the Libvirt, bhyve, and Open vSwitch combinations with minimal effort. We still have lots of work to undertake to make the changes back to OpenStack upstream. TODOs include: • Develop a proper alternative execution path in the oslo_privsep module for FreeBSD environments • Develop a new virtualization type, bhyve, for nova-compute’s libvirt driver • Develop the IP library for FreeBSD under neutron/agent/freebsd In the first few weeks of 2023, we will focus on breaking through the last mile of the instance spawn path and wrapping up the documentation regarding POC site construction. We will also try rebasing the porting work to the master branch of OpenStack (now Xena). People interested in helping with the project can first help check the documentation by following the installation guide. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter: • crees@ and zeising@ doc bits were taken in for safekeeping. Items pending and in the discussion: • A new document about licensing has been added to the documentation set. Porter’s Handbook: Two new USES knobs have been added to the Handbook: • New USES = luajit. • New USES = llvm. Also: • Erlang facilities have been documented • The new CABAL_REVISON knob has been documented. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate Link: FreeBSD Weblate Instance Q4 2022 Status • 12 languages • 150 registered users Languages • Chinese (Simplified) (zh-cn) (progress: 8%) • Chinese (Traditional) (zh-tw) (progress: 4%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 4%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Portuguese (pt-br) (progress: 16%) • Spanish (es) (progress: 19%) • Turkish (tr) (progress: 2%) We want to thank everyone who contributed by translating or reviewing documents. And please, help promote this effort on your local user group; we always need more volunteers. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Complete) Public instance on https://man-dev.FreeBSD.org 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Work in progress) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Work in progress) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Presentations and Papers Links: FreeBSD Presentations and Papers URL: https://papers.FreeBSD.org Contact: Allan Jude Contact: Greg White Contact: Li-Wen Hsu Contact: Philip Paeps In this quarter, the presentations and papers from those events have been added: • BSDCan 2022 • EuroBSDCon 2022. Open tasks: • Find and upload missing FreeBSD related presentations and papers • Issues listed at Open Issues. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreshPorts - help wanted Links: FreshPorts URL: https://freshports.org/ FreshPorts blog URL: https://news.freshports.org/ Contact: Dan Langille FreshPorts and FreshSource have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port maintainers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of the acme.sh port, back to its creation in May 2017. Converting the backend repository This topic deals with the FreshPorts code repository. The front end (website) was converted from Subversion to Git several years ago. The back end, which processes FreeBSD commits and updates the database, is still on Subversion. I have wanted to convert these repositories to Git for some time. I would like help with this please. I’ll give you a copy of the repositories and you give me back several Git repos (one for each). They will be uploaded to https://github.com/FreshPorts (our project on GitHub). These are the existing Subversion repos: • ingress (code for the back end) • database schema • backend - monitoring code • packaging - scripts for cutting new tarballs - deprecated via Git • daemontools - now misnamed, because the scripts use daemon(8) • periodics - scripts started by periodic(8) • ports - for the FreeBSD packages which install the above. I won’t be running FreshPorts forever It’s been over 22 years and I know others must take over eventually. I’d like to start that process now. There are several aspects to FreshPorts: • FreeBSD admin (updating the OS and packages) • front end code (website - mostly PHP) • back end code (commit processing - Perl, Python, shell) • database design (PostgreSQL). The database does not change very often and requires little maintenance compared to the applications and OS. The website pretty much runs itself. From time to time, a change to the FreeBSD ports infrastructure breaks something or requires a modification, but there is rarely any urgency to fix that. This is not a huge time commitment. There is a lot of learning. While not a complex application, FreshPorts is also not trivial. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PortsDB: Program that imports the ports tree into an SQLite database Links: PortsDB URL: https://github.com/yurivict/freebsd-portsdb/ Contact: Yuri Victorovich I developed the PortsDB project that imports FreeBSD ports into an SQLite database. The port is ports-mgmt/portsdb. The database can be fully rebuilt in around 20 minutes, after which it can be quickly (in seconds) updated with new commits. The database is currently updated hourly: https://people.freebsd.org/~yuri/ports.sqlite. PortsDB can be used to query ports using SQL, as a relational database. External services like Repology, FreshPorts, Portscout, and other similar services can use PortsDB to access information in the ports tree. Users can, for example, easily find their broken ports, or port duplicates, or all ports that they maintain that use gmake, among many other possible queries. Such queries aren’t easy to perform by grepping the ports tree. Cross-DB queries are also easy to do. They can combine PortsDB, /var/db/pkg/ repo-FreeBSD.sqlite, and /var/db/pkg/local.sqlite. All that needs to be done to run PortsDB is ./import.sh, and then ./update.sh after more commits are pulled into the ports repository. The periodic script is provided that can simplify integration with cron. Multiple ready to use SQL queries are also included. One particular immediate problem that PortsDB aims to solve is to fix incorrect FreeBSD port versions displayed by Repology. Repology uses ports INDEX which is missing some required information. This leads to Repology not being able to distinguish between real versions, and intermediate and made-up versions. PortsDB should allow Repology to solve this problem. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items that are important for the entire desktop stack. Infrastructure • CMake ports now share a single version number. Various build-flags have been updated for FreeBSD ports builds: under some circumstances, release-flags were ignored and debug-flags applied, which is undesirable. CMake now also refuses to fetch remote sources during a ports build. • Qt versions are now Qt 5.15.7 (used by KDE) and Qt 6.4.1. Some applications in the ports tree are now "flavored" for Qt5 and Qt6. KDE Stack KDE Gear releases happen every quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release every month as well. These (large) updates land shortly after their upstream release and are not listed separately. • KDE Frameworks 5 is now at version 5.101 (latest monthly release from December 2022). This is likely one of the last "Frameworks 5" releases, as the next major series comes closer. • KDE Gear is now version 22.12.0 (update for December 2022). • KDE Plasma is now version 5.24.7 (update for October 2022). Note that KDE Plasma 5.25 has been released upstream, but is still waiting on fixes before it can land in the ports tree (for example, this KActivityManager bug in KDE’s bug-tracker). Related Ports • graphics/krita is now version 5.1.3. • graphics/poppler was updated multiple times, now at version 22.11. It supports Qt5 and Qt6 through separate ports. • net-im/telegram-desktop was now supports Qt5 and Qt6 through flavors. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Xfce on FreeBSD Links: Xfce 4.18 Upstream Release Announcement URL: https://xfce.org/about/news/?post=1671062400 Xfce meta-port on FreshPorts URL: https://www.freshports.org/x11-wm/xfce4 Contact: Xfce team Contact: Guido Falsi The FreeBSD Xfce team (xfce@) works to ensure the Xfce desktop environment is maintained and fully functional on FreeBSD. This quarter the Xfce team members are pleased to welcome Xfce 4.18 to the FreeBSD ports tree! This new release includes many improvements in various parts of the environment, especially in the Thunar file manager. Also various upstream packages now include patches that were present in the ports tree. For further details, refer to the Xfce 4.18 Upstream Release Announcement. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pantheon desktop on FreeBSD Links: elementary OS URL: https://elementary.io Development repository URL: https://codeberg.org/olivierd/freebsd-ports-elementary Contact: Olivier Duchateau The Pantheon desktop environment is designed for elementary OS. It builds on GNOME technologies (such as Mutter, GTK 3 and 4) and it is written in Vala. The goal is to have a new desktop for users. 13.1-RELEASE or higher is required, because several core components depend on deskutils/xdg-desktop-portal. The repository contains Mk/Uses framework elementary.mk, official applications, and curated ports which depend on x11-toolkits/granite. Since the previous report, we have been updating its related ports, especially: • deskutils/elementary-calendar update to 6.1.2 • deskutils/iconbrowser • graphics/elementary-photos • math/elementary-calculator • multimedia/elementary-videos • x11/elementary-terminal • x11-themes/gnome-icons-elementary • x11-toolkits/granite7. Power manager plugins for top panel (wingpanel) and control center (switchboard) are finished. A new switchboard plugin is also available, net/switchboard-plug-sharing. Ported Rygel, GNOME UPnP/DLNA services. Submitted other patches for low level libraries such as: • print/cups-pk-helper update to 0.2.7 required by print/ switchboard-plus-printers • devel/libgee update to 0.20.6 heavily used by the desktop • sysutils/polkit update to 122 (D37137) • sysutils/accountsservice update to 22.08.8 (D37679). Open tasks • Improve documentation. • Continue to work on user settings. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Budgie desktop on FreeBSD Links: Buddies of Budgie news URL: https://blog.buddiesofbudgie.org/ Development repository URL: https://codeberg.org/olivierd/freebsd-ports-budgie Contact: Olivier Duchateau Budgie initially developed as the default desktop environment for the former Evolve OS. Since the 10.6.x releases, improvements have been made to be "agnostic". It is built on top of GNOME technologies such as GTK >= 3, GLib, Mutter, libpeas. The goal is to have a new desktop for end users. I have submitted 2 reviews ( D37224 and D37286 for The FreeBSD Porter’s Handbook) so committers can import it. These reviews include: • Mk/Uses framework budgie.mk • new virtual category (budgie) • 6 applications • icon theme x11-themes/tela-icon-theme. During this quarter, I have also submitted several patches (related to this desktop) especially: • x11/gnome-terminal update to 3.44.2 bug #267928 • x11-wm/mutter update to 42.6 bug #267899 • x11-toolkits/libwnck3 update to 40.1 bug #267898. These bugs are also still open: • devel/libpeas bug #267420 • sysutils/gnome-settings-daemon bug #265107. Open task • Add support of LightDM in FreeBSD Handbook ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ Contact: Lorenzo Salvadore Update GCC default version to 12 Thank you very much to antoine@ for running the necessary exp-runs and to all the contributors, maintainers and committers involved in the process. As was noted last quarter, for every major version of GCC, FreeBSD usually awaits the release of the second minor version to update GCC default version. However next time I would like to attempt to update the default version as soon as the first minor version of GCC 13 is out. The rationale for awaiting the second minor release was to wait for other operating systems (in particular Linux distributions) to find, report, and fix bugs, so that FreeBSD could focus mainly on FreeBSD-specific cases. But this also meant that upstream software developers only heard from FreeBSD rarely, and mostly when it concerned FreeBSD only, thus our operating system risks being considered minor and unimportant for them. My hope is that software authors can value supporting FreeBSD more as the number of its contributions to other projects also increases. Of course I understand that this will imply more work for all ports maintainers and I will do my best to help them as much as I can. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2659548 Resolution of a conflict preventing the installation of multiple GCC versions simultaneously Now, lang/gcc11 and lang/gcc12 can be installed at the same time. This was particularly important for the update of the GCC default version, since a few ports have been kept to compile with GCC 11 for now. Note however that at the moment only one -devel GCC port at the time can be installed on your system. This is because I have patched the standard ports only: for the -devel port I expect upstream to fix the issue soon, by using a patch submitted by a FreeBSD user or my own patch, or using some other solution. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060 D language D is now enabled in lang/gcc11 and lang/gcc11-devel, thanks to diizzy. I plan to include D support for higher versions of GCC too, but this cannot be done as easily as for GCC 11 due to bootstrapping issues: starting from GCC 12, the D compiler GDC needs a working GDC to be built. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266825 Crashes with -fsanitize=address Software compiled with GCC using the -fsanitize=address switch has been reported to crash. I have fixed the issue for lang/gcc11, lang/gcc11-devel, lang/gcc12, and lang/gcc12-devel. I am still working on lang/gcc13-devel. Use of the address sanitizer requires ASLR to be disabled. As GCC gets the code that I am modifying from LLVM, and LLVM is also included in the FreeBSD src repository with some patches that improve ASLR detection and automatically re-run programs with ASLR disabled when necessary, I am also merging those patches. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267751 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Another milestone for biology ports Links: Biolibc-tools URL: https://github.com/auerlab/biolibc-tools Fast And Simple Differential Analysis URL: https://github.com/auerlab/fasda Contact: Jason Bacon The biology category in ports continues to grow and mature, and reached another milestone in 2022q4 with the introduction of the rna-seq metaport. The fields of genomics, and more generally, bioinformatics, are often referred to as the "wild west" of computational science. Analyses are typically mired by a lack of clear documentation, and difficulties deploying and using software. Many scientific software developers do not understand the potential of package managers to simplify their lives and the lives of their users. As a result, much scientific software is deployed using ad hoc "caveman" installations involving overly complicated and unreliable build systems that either bundle dependencies or attempt to work with random installations thereof. Work has been ongoing to make FreeBSD ports a model of how easy scientific software deployment should be. It now contains a solid core of many of the most commonly used open source applications in biological research. This quarter saw the completion of a tool chain for one of the most important types of analysis, known as RNA-Seq. RNA-Seq measures the abundance of RNA, and hence gene activity, in tissue samples. All of the tools needed to perform a typical RNA-Seq analysis can now be installed on FreeBSD using: pkg install rna-seq This includes many mature existing tools as well as new tools developed on FreeBSD, such as FASDA and biolibc-tools, easy-to-use replacements for some of the more troublesome tools traditionally used in an RNA-Seq pipeline. Software deployments for RNA-Seq that traditionally have taken weeks or longer can now be performed on FreeBSD in a few minutes with a single command. Scientists can spend their time doing science rather than struggling with IT issues. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. During the last quarter, pot 0.15.4 was released. It again contains a number of improvements like signing pot images as well as many bug fixes. Also, we welcome two new pot contributors: @zilti and @reezer. Additionally, there is a new Ansible pot collection available. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a repository of pot flavours and complete container images for usage with pot and in many cases Nomad. As you can see, we had a busy quarter again, this time including improvements to the Nextcloud as well as Jitsi images. Furthermore, we landed pot-based FreeBSD support for sccache-dist server (the server component for distributed compilation of rust and C++ using sccache) and it will be part of the upcoming sccache 0.4.0, see mozilla/sccache#1184. Once released, this will become available through devel/sccache. This means one can build rust projects on FreeBSD targeting a cluster of machines, something that could potentially be integrated into poudriere as well. Last but not least, Luca’s EuroBSDCon 2022 talk is now available on YouTube. As always, feedback and patches are welcome. From nobody Mon Jan 30 10:58:10 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P54sd2qGhz3cFxj for ; Mon, 30 Jan 2023 10:58:13 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P54sc2SQLz438d for ; Mon, 30 Jan 2023 10:58:12 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of nvass@gmx.com designates 212.227.15.15 as permitted sender) smtp.mailfrom=nvass@gmx.com; dmarc=pass (policy=none) header.from=gmx.com Received: from [5.203.213.109] ([5.203.213.109]) by web-mail.gmx.net (3c-app-mailcom-bs08.server.lan [172.19.170.176]) (via HTTP); Mon, 30 Jan 2023 11:58:11 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: freebsd-stable@freebsd.org Subject: test Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Jan 2023 11:58:10 +0100 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K1:tdZLz1qKEIW+uIjTgqb0AdWOELIn+/7SkLqj27IuamOsESktOToLo5Lt50HqCa8T8+h71 TBqHvClnMHUIFUmRfyM9ccAn82OfkRyXpNKfQ6bLMEtw5QRdlN13OKHqfdLg2pfpdYLGszbDUWl5 pt5rBTUYmPYx9CG4r7i+BaNoxmFMLwHPH/Nh1NPdEPBKmYJeWCEZSmLYQcKx6W1vvftAfNBCzMoL us3RXzToJrgJMLdfKwxJSLstKe7bBGkJ3ndM/ABGHwNEFXXhFUZvkHU3UqSgaSvxoErQWM20VHIB mc= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ygx2nefDglo=;lL3EgtZUZUHgc8fKv+6vzmB+lIX IHNOhHudSYv1BJtsLO4fNGK8InB5QYbu3zv0hcYjokmakFxO6AfOPkG5DlcU3un20plkxL87k f2rzi0LTb/acvLjN9faOoimStioHhQpcqYge/DY13+ptcs4WGnZKtUR/gJjA6TPSaGY30hCAl byDeAJ2y2FDT/hSboNNkCfD7yD0zwpX/SFTTwvHUZC39aXXGkPYm0IkraYv1IiBeym84KI0CP REwgWGnhXJEBj4JNVn9B9JUEGpxvVesHXDPqE/s172MkqRJEAT12zUFn+AMdOpyqIGg+jCWP4 lR+56z1zw7V2tJX2CFxT67nVlumErARlLMpxVeQUPK9JEpt4E5CSuJeF5fYstRtdsZjvfOqt4 bthU9Jwli6Og+8wXLMgmIUDr4XZHxMEitddPC/UIJjbEAqoULZuyOgp/Qz3mKfdIJtMEDt58Q UtKf7NRg30LIB7R5+HIMH2ggNLT1gNzctuuJ/9DzAcFJyxr484wAOFtN/q9A35MwwGGqSaTar PW7vi50DcSmGx89oR40qQmt4FR5r3VCIeIUK9O2JYBpNzk9UOKv8PClOTl33YnjUAAOR93dV8 lSQlZPEGkMmlXI6ik83+2BUYfctnOh8kQie9RIO7oePHln3bqxgIQYn4CpUSfmseq7VbRsz82 1SLNxn/9ZQiu3DvYusNeydvq9QDeVqT86q+QgNYo6EF0HXjghB98Uix1iFsQe095eIkWPem6I WAkTyqnMEuy8FguGtj2M+a22a3c9OIPJEwrkRV+FDTVSmtash0fUrblNY0NUhlb3ChZTBwZVJ bGmFkb5UnIt0G4xDjf+NM0O27JCoQlOX9fNvh2s256YT+CNPPmuAjw8xkZnHo67nYNE58WCp4 sI2/U/fw04Ciltg== X-Spamd-Result: default: False [-2.62 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; NEURAL_HAM_LONG(-0.76)[-0.761]; DMARC_POLICY_ALLOW(-0.50)[gmx.com,none]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.49)[-0.490]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/24]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; FREEMAIL_ENVFROM(0.00)[gmx.com]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; HAS_X_PRIO_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmx.com]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P54sc2SQLz438d X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N Hi, I just rebooted a system of mine and it seems that the kernel is constantly doing something. How could I debug this? I am thinking of rebooting it tonight root@aurora:~ # top -S -b last pid: 2196; load averages: 1.00, 1.00, 1.00 up 0+01:54:34 12:41:35 72 processes: 2 running, 69 sleeping, 1 waiting CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle Mem: 46M Active, 171M Inact, 1429M Wired, 14G Free ARC: 919M Total, 354M MFU, 487M MRU, 6912K Anon, 8726K Header, 63M Other 234M Compressed, 610M Uncompressed, 2.60:1 Ratio Swap: 16G Total, 16G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 4 155 ki31 0B 64K RUN 0 345:06 314.31% idle 0 root 49 -16 - 0B 784K swapin 1 112:27 99.85% kernel 30 root 319 -16 - 0B 5120K spa->s 3 0:06 0.00% zpool-aurora-os 1157 root 1 20 0 176M 150M select 2 0:05 0.00% smbd 1154 root 1 20 0 175M 150M select 2 0:05 0.00% smbd This is a 12.4-RELEASE system. Thanks for any ideas, Nikos From nobody Mon Jan 30 11:03:03 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P54zF2SBSz3cGF0 for ; Mon, 30 Jan 2023 11:03:05 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P54zF07BGz44x4 for ; Mon, 30 Jan 2023 11:03:04 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; none Received: from [5.203.213.109] ([5.203.213.109]) by web-mail.gmx.net (3c-app-mailcom-bs08.server.lan [172.19.170.176]) (via HTTP); Mon, 30 Jan 2023 12:03:03 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: Nikos Vassiliadis Cc: freebsd-stable@freebsd.org Subject: Kernel is using a lot of CPU (was: Re: test) Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Jan 2023 12:03:03 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:MWCc6YrpiDmQWdlquqeXJ11xf31M2iUxn9jgobvwhH2QnC3Ji1nOSURxcz+g24tk4Jw7d BjPZC2FS+iwm5sOeMCXTiSVNL3duiVYhTq46gydmZ5s+HpEnt+3+9j4mxUOMyMs1uwGXE/UZN+JG kEUoL+7MCDqm4MJGdZM7g7vmhQzIUsUD7ampw4j1CU7MQF5xKxvj6MRWWx69h1EsDoq+Mzjf5UTQ EnuB46SDJM5RCBtiOrm4Iok62nXTp75pOdOewaEFLO7hqzV/TKtCK7GqCJXoS6nSNWegx0Zk3vtB +8= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:mYHOzpUAyoA=;qjaKfa7Pn7C3FqJNrjn/VQJjmvE EPAGGlPpxlUBetN7oBulC0ng/aVmoMugEvSXeqZaD9beVX0894ddRxA3760QybETv3kFB1+8C IZN093Nr9f5J0dFFs4kiAlH4C4Y7vfi87L0g06oHy5It4nNB0z29u+KBkcXcB0vsmSPnaD6PW 86FiBVWohyU2VSh9eS94GXeypO3i4H2i9p8+vIr7xmiRss+2QaEK7do+hO/e1uSxusCg8WwUD MhVF8yy/vafiSmo8WUHdSsVDoapUws7XvN70NZQ30Yxjol+Fwdpc3cogehgecL2J9WYdNCMNf v+Y7nKof2me5CniGXTBDuIinGQZS2GwCiAu+kcEyh7L8P20ALgjbvnIiYhstwHj81IifkEKRv +qtHj4IWclJoYFxn7l813jHKP9RTrlOwazGEy3RZhsiUka36pqGNyyl9N3E29+97oO7ZBTssz IcLNZLvwqk1Kj/74eq4e5mqEhTFAMr9SmhyqXiwrZDAsphzM00Uhdk8EsmieJJElRkoOgf55f AnlNEst46NGUgp6emdv8Po7p0dO2bXbyC5V676KjcoperwnUAlsxvTKD9IvIp2bOikLXLobAM DdGAz+LDFQf5ifHwfmo4YZ9TDJLYIJv/a/qia8eC43i7IUhYa4pqYyQz3f7mHBapch/LTOhRk rmubMnZPleKtjZoXFJZTy4ITYVSg42+vLjqVGCTZ7mwH9hZ0X9aB86jYLbs2hlLkmfCNNB0il cMKMoexy8YNBl1Ua98NNGmpIx2YnG5wC9UkntdnnYcOCU4uY/nFgkQ0Ad8RlqT6HjR5xlK0Lq I5Q3SpcLSeW62Pny2Ol04FoA== X-Rspamd-Queue-Id: 4P54zF07BGz44x4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Hi, > > I just rebooted a system of mine and it seems that the kernel is constantly doing something. How could I debug this? > I am thinking of rebooting it tonight > > root@aurora:~ # top -S -b > last pid: 2196; load averages: 1.00, 1.00, 1.00 up 0+01:54:34 12:41:35 > 72 processes: 2 running, 69 sleeping, 1 waiting > CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle > Mem: 46M Active, 171M Inact, 1429M Wired, 14G Free > ARC: 919M Total, 354M MFU, 487M MRU, 6912K Anon, 8726K Header, 63M Other > 234M Compressed, 610M Uncompressed, 2.60:1 Ratio > Swap: 16G Total, 16G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 4 155 ki31 0B 64K RUN 0 345:06 314.31% idle > 0 root 49 -16 - 0B 784K swapin 1 112:27 99.85% kernel > 30 root 319 -16 - 0B 5120K spa->s 3 0:06 0.00% zpool-aurora-os > 1157 root 1 20 0 176M 150M select 2 0:05 0.00% smbd > 1154 root 1 20 0 175M 150M select 2 0:05 0.00% smbd > > This is a 12.4-RELEASE system. > > Thanks for any ideas, > Nikos > > > Sending the email again with the correct subject From nobody Mon Jan 30 13:27:16 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P589m55R0z3cgQd for ; Mon, 30 Jan 2023 13:27:24 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P589m2mJSz3L9W for ; Mon, 30 Jan 2023 13:27:24 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 30UDRHEW087707; Mon, 30 Jan 2023 07:27:17 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id FzMLGLXF12OZVgEAs/W3XQ (envelope-from ); Mon, 30 Jan 2023 07:27:17 -0600 From: Mike Karels To: Nikos Vassiliadis Cc: freebsd-stable@freebsd.org Subject: Re: Kernel is using a lot of CPU (was: Re: test) Date: Mon, 30 Jan 2023 07:27:16 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4P589m2mJSz3L9W X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 30 Jan 2023, at 5:03, Nikos Vassiliadis wrote: >> Hi, >> >> I just rebooted a system of mine and it seems that the kernel is const= antly doing something. How could I debug this? >> I am thinking of rebooting it tonight >> >> root@aurora:~ # top -S -b >> last pid: 2196; load averages: 1.00, 1.00, 1.00 up 0+01:54:34 = 12:41:35 >> 72 processes: 2 running, 69 sleeping, 1 waiting >> CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle= >> Mem: 46M Active, 171M Inact, 1429M Wired, 14G Free >> ARC: 919M Total, 354M MFU, 487M MRU, 6912K Anon, 8726K Header, 63M Oth= er >> 234M Compressed, 610M Uncompressed, 2.60:1 Ratio >> Swap: 16G Total, 16G Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU= COMMAND >> 11 root 4 155 ki31 0B 64K RUN 0 345:06 314.31%= idle >> 0 root 49 -16 - 0B 784K swapin 1 112:27 99.85%= kernel >> 30 root 319 -16 - 0B 5120K spa->s 3 0:06 0.00%= zpool-aurora-os >> 1157 root 1 20 0 176M 150M select 2 0:05 0.00%= smbd >> 1154 root 1 20 0 175M 150M select 2 0:05 0.00%= smbd >> >> This is a 12.4-RELEASE system. >> >> Thanks for any ideas, >> Nikos >> >> >> > > Sending the email again with the correct subject You could add -H to the top command, which will show kernel threads withi= n the kernel process. Mike From nobody Mon Jan 30 13:37:59 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P58Q91VGhz3chd8 for ; Mon, 30 Jan 2023 13:38:09 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P58Q84mjVz3N1x for ; Mon, 30 Jan 2023 13:38:08 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; none Received: from [5.203.213.109] ([5.203.213.109]) by web-mail.gmx.net (3c-app-mailcom-bs12.server.lan [172.19.170.180]) (via HTTP); Mon, 30 Jan 2023 14:37:59 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: Mike Karels Cc: freebsd-stable@freebsd.org Subject: Re: Kernel is using a lot of CPU (was: Re: test) Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Jan 2023 14:37:59 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:sJe2GnGWCnDyVdsWrsojUg1sbZ+YEnQdJeNWq4g2PXBQ4QwK9ci6PtvQezQr8XWjMogHS H23IFVYaWHzdF5piQmJ2ek2yAghvnbFOFo1O//z7UUtkTM4OzQcjEc7ZjAoeLxGNCbfEWgJN/nE9 /yqVy4IgQubgePqhLzyph4hhYRMd50v6NTskCBjbzPinGXpFL1yiy3dZPXueLFeQg9a7zac/YdaO DhxIwHzMmCK9D1US/jMM0+N1D1bBU+oH24/1W+B/iPKJ/8hzPS64dsznfD6JHblAwswGyLG/otss ww= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:dbtF7kSVi7M=;KONkdr86JHMZZM9Ssh6WlsZcDp+ tC0ztAuETceDu5jBN/RnaoCYNnMenhAw5kEk0E4cNS/6o9+tPgLUp3dm2+4FHjvOZRWIlSZwf wscv6nZwazvUL7aBRKlY55wWZYXsg5qkBy/knpDteMvFjDmU4/P3G1oYJyy8uXSB6P5crOOf5 4Pd61VpluHhYDM5uk8odCYjIEY7yydFqrXXBCzJ4c/G6E4hgOwItLM1lpd0gmDCqR0qzDyHRR 7iY/OYW3IFE48IcKfJ25P+6yn3pjvwkFY085RjLQK8v7Y7m8/G7eUjhvXcthSwq269oYWxCmA EeF7qcD2QAA81rGAExcpnOcahT+Jv6uWGax2J5G74RZA9C9PyZf9REK9Nuv0R3CQSqd+Ucl/b ATdtJW96VD/uUSFI0AsYa0lqyJGDsn8NlxM+wAfkAuPZ7i29vEq1MH8K/Sgqatcr8cMk2Py1T 6F24XyqgCS5GHzCfpqHZslCn1KWoTTfbbaNI/pmHG4R0Mz2xlS1xRe1qxno0wEoNa58WzVz87 U3RGB3WeQ583DNmlIroeerzN/11ANrQuuAQXPib8JIt+cCHtiH84tgzz9ZOW9Yyv8HhHFSaRj ny+eiG7og53TdaeWpsmYCR9OYScMa4uwZHzoSlqWc3HC2xzhqHbW3PhDMxrDeHfzYUdCPGYKf 8lO/WSf6HNsl4APVQaBiJzeBcODhcloF7R7YiABUeKzsQDI7/GolouG2/SU6Wxh+x+94rb2lg ameGG/3HwHxXqUuc326vHdmPnqtZPfNl2PR/dnyek/gQTQq0TTa5Da6XiHRctBczPMj3aXQf/ 0iF+/d+6J3//KQcvC3FcApZ0co2CUGaA+nHktQwgQisuw= X-Rspamd-Queue-Id: 4P58Q84mjVz3N1x X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Sent: Monday, January 30, 2023 at 3:27 PM > From: "Mike Karels" > To: "Nikos Vassiliadis" > Cc: freebsd-stable@freebsd.org > Subject: Re: Kernel is using a lot of CPU (was: Re: test) > > On 30 Jan 2023, at 5:03, Nikos Vassiliadis wrote: > > >> Hi, > >> > >> I just rebooted a system of mine and it seems that the kernel is constantly doing something. How could I debug this? > >> I am thinking of rebooting it tonight > >> > >> root@aurora:~ # top -S -b > >> last pid: 2196; load averages: 1.00, 1.00, 1.00 up 0+01:54:34 12:41:35 > >> 72 processes: 2 running, 69 sleeping, 1 waiting > >> CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle > >> Mem: 46M Active, 171M Inact, 1429M Wired, 14G Free > >> ARC: 919M Total, 354M MFU, 487M MRU, 6912K Anon, 8726K Header, 63M Other > >> 234M Compressed, 610M Uncompressed, 2.60:1 Ratio > >> Swap: 16G Total, 16G Free > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > >> 11 root 4 155 ki31 0B 64K RUN 0 345:06 314.31% idle > >> 0 root 49 -16 - 0B 784K swapin 1 112:27 99.85% kernel > >> 30 root 319 -16 - 0B 5120K spa->s 3 0:06 0.00% zpool-aurora-os > >> 1157 root 1 20 0 176M 150M select 2 0:05 0.00% smbd > >> 1154 root 1 20 0 175M 150M select 2 0:05 0.00% smbd > >> > >> This is a 12.4-RELEASE system. > >> > >> Thanks for any ideas, > >> Nikos > >> > >> > >> > > > > Sending the email again with the correct subject > > You could add -H to the top command, which will show kernel threads within > the kernel process. > > Mike > > Thanks Mike, A kernel thread named acpi_task_n seems to be the source of the problem. This system is rather old and was ok running 12.2-REL. Maybe some update to the ACPI code?. What could I try next? nik@aurora:~ % top -H -S -b last pid: 2529; load averages: 1.03, 1.03, 1.00 up 0+04:43:45 15:30:46 840 threads: 6 running, 820 sleeping, 14 waiting CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle Mem: 29M Active, 192M Inact, 1717M Wired, 13G Free ARC: 1182M Total, 475M MFU, 608M MRU, 7744K Anon, 12M Header, 79M Other 312M Compressed, 782M Uncompressed, 2.51:1 Ratio Swap: 16G Total, 16G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0B 64K CPU3 3 272:53 100.00% idle{idle: cpu3} 11 root 155 ki31 0B 64K RUN 0 260:10 81.15% idle{idle: cpu0} 0 root 8 - 0B 784K - 3 141:30 76.76% kernel{acpi_task_2} 11 root 155 ki31 0B 64K CPU1 1 212:51 74.66% idle{idle: cpu1} 11 root 155 ki31 0B 64K RUN 2 108:52 51.86% idle{idle: cpu2} 0 root 8 - 0B 784K CPU2 2 116:25 24.27% kernel{acpi_task_0} 2324 root 20 0 177M 151M select 3 0:03 0.10% smbd{smbd} 0 root 8 - 0B 784K - 0 21:08 0.00% kernel{acpi_task_1} 0 root -16 - 0B 784K swapin 2 0:53 0.00% kernel{swapper} From nobody Mon Jan 30 14:27:30 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P59WN0PVhz3bL3r for ; Mon, 30 Jan 2023 14:27:44 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P59WM3bBVz3kJJ for ; Mon, 30 Jan 2023 14:27:43 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; none Received: from [5.203.213.109] ([5.203.213.109]) by web-mail.gmx.net (3c-app-mailcom-bs15.server.lan [172.19.170.183]) (via HTTP); Mon, 30 Jan 2023 15:27:30 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: Nikos Vassiliadis Cc: Mike Karels , freebsd-stable@freebsd.org Subject: Re: Kernel is using a lot of CPU (was: Re: test) Content-Type: text/plain; charset=UTF-8 Date: Mon, 30 Jan 2023 15:27:30 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:qQ7JCrxja3mRRL6LG6WnTSIPMOmlHthfJKQXZ1BiAbgdEniO6YBTEMKi+dxhbHUkyPbXZ fvaSgbHdl+CATnSi7oqi7KaYaE/BEPBim62xqL6ZLIUxJDNwsOw90j2dg8CsPsgKFbGJ0yoldLQ3 jymFWTxI6uUry+el83STJruMOr0r/JjwYXmBgL38alVsHW/XEUVUE9nNTCcHD06WhzWGqgPZ9FBt 6efs/Cz70DgIqFKgROxNbLBNRVsZHvaYa9UGFulmiSPTsCiz0hubpWrfJvxFn8rBGLKzDELAHUAB MY= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:+CSQBZAQ2MM=;ScIJrpLZwxOyEqEVB5XtPHQe37X cESrGEZ24fOy5LmFNr+E+nH5LjTrNOUoraZctqjbiZcF5lr+RTPj+DZZhibqPaK2WVFcHySv4 eZl0J+DCz8vpfuydePP1nGf1LYx4PZQIfkJbgWWT/ZToLy1x53wtZhy74PCjgKsG+ilK7jV9H +9kJdTZGVPgIkGa0hh00shV84x0WfxpWSd0ZE7nFF8a5WTHal8R41xShPLAmYko0N1twS6Zuf 7Dswgdhd19FPikH+JEEv8LONrSmrOM45q+Ewx87tne5avBFH91vaQAD7E3M0Tcw5Oeh/+p/ds cnOiY2nqXTYilHic8TOTLcq7IqPfDnNgpTonm9PLZQ7ZdYOaJYsGqyXkzUa+sF92djApH44SA oc+N6Cw1SDQxB6klZ5lY/dwreU3sI31neFcR05odvneTbRjSQH8ngpuQM2GzOOYGatzlXy2Pr H7knLxym/amO+bzHpu57v6X0kqEjwIggmmI0U66nta1PYs78rGrdahF7w+zNpz12/JxnizDq5 43Knx1j9n74GT1/wTJcA0IALlw/JmkyhnyvjsuTc+1fMlaUqv12eXsTLGETC/pSQsttRQgO02 3nT1VQrMmLn5ANBHPziFlgfz3AsFmRdBm1BoqhX7j8M8OrWKE2Pm7y+UILvX/x1ewW9r5ILZo 75eWrrQFWM349aU9Z2Z9nu6aE9PjBpA98n7It5wlJg89YXF81Jx7gw/xELayBeJusGaxZRRIP OHmJxPMaypKVe9ngPVMddP/jaiGnNRWIk9J4hPimhTTYPrmhhkPWRtd8Pd5ixaizQvDJE1FXK sTQnVzRPfQuP1diHEDiU0lCg== X-Rspamd-Queue-Id: 4P59WM3bBVz3kJJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Sent: Monday, January 30, 2023 at 3:37 PM > From: "Nikos Vassiliadis" > To: "Mike Karels" > Cc: freebsd-stable@freebsd.org > Subject: Re: Kernel is using a lot of CPU (was: Re: test) > > > > > Sent: Monday, January 30, 2023 at 3:27 PM > > From: "Mike Karels" > > To: "Nikos Vassiliadis" > > Cc: freebsd-stable@freebsd.org > > Subject: Re: Kernel is using a lot of CPU (was: Re: test) > > > > On 30 Jan 2023, at 5:03, Nikos Vassiliadis wrote: > > > > >> Hi, > > >> > > >> I just rebooted a system of mine and it seems that the kernel is constantly doing something. How could I debug this? > > >> I am thinking of rebooting it tonight > > >> > > >> root@aurora:~ # top -S -b > > >> last pid: 2196; load averages: 1.00, 1.00, 1.00 up 0+01:54:34 12:41:35 > > >> 72 processes: 2 running, 69 sleeping, 1 waiting > > >> CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle > > >> Mem: 46M Active, 171M Inact, 1429M Wired, 14G Free > > >> ARC: 919M Total, 354M MFU, 487M MRU, 6912K Anon, 8726K Header, 63M Other > > >> 234M Compressed, 610M Uncompressed, 2.60:1 Ratio > > >> Swap: 16G Total, 16G Free > > >> > > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > >> 11 root 4 155 ki31 0B 64K RUN 0 345:06 314.31% idle > > >> 0 root 49 -16 - 0B 784K swapin 1 112:27 99.85% kernel > > >> 30 root 319 -16 - 0B 5120K spa->s 3 0:06 0.00% zpool-aurora-os > > >> 1157 root 1 20 0 176M 150M select 2 0:05 0.00% smbd > > >> 1154 root 1 20 0 175M 150M select 2 0:05 0.00% smbd > > >> > > >> This is a 12.4-RELEASE system. > > >> > > >> Thanks for any ideas, > > >> Nikos > > >> > > >> > > >> > > > > > > Sending the email again with the correct subject > > > > You could add -H to the top command, which will show kernel threads within > > the kernel process. > > > > Mike > > > > > > Thanks Mike, > > A kernel thread named acpi_task_n seems to be the source of the problem. This system is rather old and was ok running 12.2-REL. Maybe some update to the ACPI code?. What could I try next? > > nik@aurora:~ % top -H -S -b > last pid: 2529; load averages: 1.03, 1.03, 1.00 up 0+04:43:45 15:30:46 > 840 threads: 6 running, 820 sleeping, 14 waiting > CPU: 0.0% user, 0.0% nice, 24.6% system, 0.0% interrupt, 75.3% idle > Mem: 29M Active, 192M Inact, 1717M Wired, 13G Free > ARC: 1182M Total, 475M MFU, 608M MRU, 7744K Anon, 12M Header, 79M Other > 312M Compressed, 782M Uncompressed, 2.51:1 Ratio > Swap: 16G Total, 16G Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 155 ki31 0B 64K CPU3 3 272:53 100.00% idle{idle: cpu3} > 11 root 155 ki31 0B 64K RUN 0 260:10 81.15% idle{idle: cpu0} > 0 root 8 - 0B 784K - 3 141:30 76.76% kernel{acpi_task_2} > 11 root 155 ki31 0B 64K CPU1 1 212:51 74.66% idle{idle: cpu1} > 11 root 155 ki31 0B 64K RUN 2 108:52 51.86% idle{idle: cpu2} > 0 root 8 - 0B 784K CPU2 2 116:25 24.27% kernel{acpi_task_0} > 2324 root 20 0 177M 151M select 3 0:03 0.10% smbd{smbd} > 0 root 8 - 0B 784K - 0 21:08 0.00% kernel{acpi_task_1} > 0 root -16 - 0B 784K swapin 2 0:53 0.00% kernel{swapper} > > > > > > 12.4 autoloaded acpi_wmi with dubious results: Autoloading module: acpi_wmi acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 12.2 did not autoload it. From eugen@grosbein.net Mon Jan 30 14:47:35 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P59ys2rFfz3bNRq for ; Mon, 30 Jan 2023 14:48:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P59ys0BqPz3psm for ; Mon, 30 Jan 2023 14:48:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; none Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 30UEltLF038072 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2023 14:47:56 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nvass@gmx.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 30UElsSa075705 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Jan 2023 21:47:54 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Kernel is using a lot of CPU To: Nikos Vassiliadis References: Cc: Mike Karels , freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: Date: Mon, 30 Jan 2023 21:47:35 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4P59ys0BqPz3psm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 30.01.2023 21:27, Nikos Vassiliadis wrote: > 12.4 autoloaded acpi_wmi with dubious results: > > Autoloading module: acpi_wmi > acpi_wmi0: on acpi0 > acpi_wmi0: cannot find EC device > device_attach: acpi_wmi0 attach returned 6 > acpi_wmi0: on acpi0 > acpi_wmi0: cannot find EC device > device_attach: acpi_wmi0 attach returned 6 > > 12.2 did not autoload it. You may blacklist the module in /etc/rc.conf to disable autoloading, if you wish: devmatch_blacklist="acpi_wmi.ko" From nobody Mon Jan 30 14:50:38 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5B1r6mMnz3bNvM for ; Mon, 30 Jan 2023 14:50:40 +0000 (UTC) (envelope-from DutchDaemon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5B1r6LKHz3r7J for ; Mon, 30 Jan 2023 14:50:40 +0000 (UTC) (envelope-from DutchDaemon@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675090240; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UkIAXtfflm2jGac4hb23Bv0DRPeN1/IWUn+X9K8oCXs=; b=ZopDKXhCvTB8iAoSpUpnWMSFvTL+q6RVJBSFpSUhXJ+W0Lbx0gWEW0TAa3AolCKsghVxCN 8McyaoD/8QmYh6f5Tsk3xtog/JJWKVvrnaDFR5Av5fD1zHLj4EdxDmHbinUZeJROXl7Cm1 BaG+tY25+u+LPfJdx6YjJbVkz7PZBcGol4PGDjzqqX6PtnxJBFHn7vsTucc588lhTM/2Qo O5oqR2EINQ6OFr6Rglj+fkPUBjHMQFSkazb0wY03vNhLB6clSRPTwXlpc+9H1BxbhsUN1k BqmghvCYHTPZvratl+MoPWJI+omSjIIiDJsw50lua2dkuyiydkjCbWzzcHfE9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675090240; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UkIAXtfflm2jGac4hb23Bv0DRPeN1/IWUn+X9K8oCXs=; b=cmTUIrcUi9zndT5HSc2P+f/W2XtZIPFlbzpzbGbCJOAwMyeOI3lZmdXPF+2+Tl/zuqZeDP A7RzvLiqXA+vE/IQlvYFkZyGkUGykn8/MPn87C0pTtIbrwYKFjlT1mPvRN11az6Q+h60ay 3l5z+uXJLJ1exJIPQ+g5CffvUWPzdOP1XnG3vqRJqWIdCYfGqAiSpX8Cf/eWrXH0Y5wq9N 7cH4WdPgf3uj7FHQQ721Gxm0PY07e4HxtEyylZIuU3juj1rku0u4wLUtXf2/L8kQi3hhN5 SIHeSXxK9r4tDScubgYZgAnQjxOftx2L5x//9stKxRvBhCK4WxmkljP0JBIZiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675090240; a=rsa-sha256; cv=none; b=WyR4ODaUG8r6VUaeKCqDftYeLw6bsOYD7qfaeyEceI2eOfqwwgAoTxn4r2mhRqtZK/3QMU Y/fV5oY/1z6+1VCfZcCfzF8qvRIcDFCU7VBOF/ZkL7cqPZBuu3LqfprLMk3KKS+iMI9YvK nrYpt3tLrO+alccOAJLd5vfm++/wI8ZBuuMOIwFdP8EdUdJgHxEInuT8a9bwtCeZz89hE+ zgGYoiXy9dCTBTOKhTTsLmOvWayLOHClE54+XeTp/yLdy+zJJTUSI6np4tGfARHVgWvYak Avpa5onurTmuLQVzF4kCQ02YILApqnrplGbYRUWqEdOalOmPAgVAqXkyb3RJmA== Received: from [192.168.178.205] (unknown [85.148.89.7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dutchdaemon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4P5B1r3nhLz1QYJ for ; Mon, 30 Jan 2023 14:50:40 +0000 (UTC) (envelope-from DutchDaemon@FreeBSD.org) Message-ID: Date: Mon, 30 Jan 2023 15:50:38 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Kernel is using a lot of CPU To: stable@freebsd.org References: Content-Language: nl, en-US From: DutchDaemon - FreeBSD Forums Administrator Organization: The FreeBSD Forums In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------QiHzyK26JQ2WjC80SnmpgsBS" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QiHzyK26JQ2WjC80SnmpgsBS Content-Type: multipart/mixed; boundary="------------cNPri9Qd0ooZD64ZgZ4DoZZI"; protected-headers="v1" From: DutchDaemon - FreeBSD Forums Administrator To: stable@freebsd.org Message-ID: Subject: Re: Kernel is using a lot of CPU References: In-Reply-To: --------------cNPri9Qd0ooZD64ZgZ4DoZZI Content-Type: multipart/alternative; boundary="------------wuH0qW5mZVtuUNrx7lYLAY9Q" --------------wuH0qW5mZVtuUNrx7lYLAY9Q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMzAvMDEvMjAyMyAxNTo0NywgRXVnZW5lIEdyb3NiZWluIHdyb3RlOg0KPiAzMC4wMS4y MDIzIDIxOjI3LCBOaWtvcyBWYXNzaWxpYWRpcyB3cm90ZToNCj4NCj4+IDEyLjQgYXV0b2xv YWRlZCBhY3BpX3dtaSB3aXRoIGR1YmlvdXMgcmVzdWx0czoNCj4+DQo+PiBBdXRvbG9hZGlu ZyBtb2R1bGU6IGFjcGlfd21pDQo+PiBhY3BpX3dtaTA6IDxBQ1BJLVdNSSBtYXBwaW5nPiBv biBhY3BpMA0KPj4gYWNwaV93bWkwOiBjYW5ub3QgZmluZCBFQyBkZXZpY2UNCj4+IGRldmlj ZV9hdHRhY2g6IGFjcGlfd21pMCBhdHRhY2ggcmV0dXJuZWQgNg0KPj4gYWNwaV93bWkwOiA8 QUNQSS1XTUkgbWFwcGluZz4gb24gYWNwaTANCj4+IGFjcGlfd21pMDogY2Fubm90IGZpbmQg RUMgZGV2aWNlDQo+PiBkZXZpY2VfYXR0YWNoOiBhY3BpX3dtaTAgYXR0YWNoIHJldHVybmVk IDYNCj4+DQo+PiAxMi4yIGRpZCBub3QgYXV0b2xvYWQgaXQuDQo+IFlvdSBtYXkgYmxhY2ts aXN0IHRoZSBtb2R1bGUgaW4gL2V0Yy9yYy5jb25mIHRvIGRpc2FibGUgYXV0b2xvYWRpbmcs IGlmIHlvdSB3aXNoOg0KPg0KPiBkZXZtYXRjaF9ibGFja2xpc3Q9ImFjcGlfd21pLmtvIg0K L2Jsb2NrbGlzdC8NCg== --------------wuH0qW5mZVtuUNrx7lYLAY9Q Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 30/01/2023 15:47, Eugene Grosbein wrote:
30.01.2023 21:27, Nikos Vass=
iliadis wrote:


12.4 autoloaded acpi_wmi w=
ith dubious results:

Autoloading module: acpi_wmi
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6

12.2 did not autoload it.

You may blacklist the module in /etc/rc.conf to disable autoloading, if y=
ou wish:

devmatch_blacklist=3D"acpi_wmi.ko"
/blocklist/ --------------wuH0qW5mZVtuUNrx7lYLAY9Q-- --------------cNPri9Qd0ooZD64ZgZ4DoZZI-- --------------QiHzyK26JQ2WjC80SnmpgsBS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9AWUvcZu/lO5r3wZ0R2eb0cya6gFAmPX2T4FAwAAAAAACgkQ0R2eb0cya6il LhAAuJdW7m7K2s3y8r9HyA9g+G+2Ldf9q3vY6j5GKdx1NrG3JRDTmPgXBN3S4j5UfPVeVVnsxwA2 4igcjQaArtEBnUgD7qKHsEPAJB1U4IHhqF1xsZKp0+fM0S4pQAB3ZFUS6jJh4qo29j5kpdE7PixP kn/0qcnZlUJpwdOubTeO/gnOzeeYV4Civ6fHAlOUMYK8PJLp05MHr9sbIXJ0QJOXGBOXRBIfJjLo le9zbfV+ZAseifp2Cue6mP5R9zAIytLmKv0orfVKZFD0jz4gc9ShugKEH6UelyLNLzAbmttt3fqm eVu1YoEC03T1zHynii3bYANtYbtDCAnea4bUS0SGJ1AIXLUi3Lvl+bEFtA+tFxIGf7l02lXzMKvT wCHi53iPgdAA0lEO0wj2PASpMmma5OfE7nnASZLYFhPp1qSLQCugikkEdKIS0Q/mu9Q7d6nr7kT2 QlVDjaGFFuv49aIcZhWcxpsxvtBWlXkq+R/5IDEz6kDDEhqz42s6CDDxC6BwOCuErKEOYWkg1O2Z 0aFWX5yxLP27+TD1zIVl/SitUPbKPuR5b7rkEtBEdLY2Xz4jl0q8NMDdhQCvDhVEDb6PznQZqEBD Wia8XVyqrbC2n37lxqGmUZJGKLVz9THBcgcX4ylrY8JiPGsfqaGcSnzZAnqODpsL/jV8ommMWNsN U84= =HcS/ -----END PGP SIGNATURE----- --------------QiHzyK26JQ2WjC80SnmpgsBS-- From eugen@grosbein.net Mon Jan 30 15:04:18 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5BL02FCrz3bQfb for ; Mon, 30 Jan 2023 15:04:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5BL00pwlz3tr1; Mon, 30 Jan 2023 15:04:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; none Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 30UF4cqn038367 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2023 15:04:38 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: DutchDaemon@FreeBSD.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 30UF4b0x075970 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Jan 2023 22:04:37 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Kernel is using a lot of CPU To: DutchDaemon - FreeBSD Forums Administrator , stable@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Mon, 30 Jan 2023 22:04:18 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4P5BL00pwlz3tr1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 30.01.2023 21:50, DutchDaemon - FreeBSD Forums Administrator wrote: > On 30/01/2023 15:47, Eugene Grosbein wrote: >> 30.01.2023 21:27, Nikos Vassiliadis wrote: >> >>> 12.4 autoloaded acpi_wmi with dubious results: >>> >>> Autoloading module: acpi_wmi >>> acpi_wmi0: on acpi0 >>> acpi_wmi0: cannot find EC device >>> device_attach: acpi_wmi0 attach returned 6 >>> acpi_wmi0: on acpi0 >>> acpi_wmi0: cannot find EC device >>> device_attach: acpi_wmi0 attach returned 6 >>> >>> 12.2 did not autoload it. >> You may blacklist the module in /etc/rc.conf to disable autoloading, if you wish: >> >> devmatch_blacklist="acpi_wmi.ko" > /blocklist/ Thanks for correction, and sorry for mistake. ENOSLEEP. From nobody Mon Jan 30 15:19:12 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5Bg52dqJz3bSgW for ; Mon, 30 Jan 2023 15:19:29 +0000 (UTC) (envelope-from jon@xyinn.org) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5Bg51dXgz3xxG; Mon, 30 Jan 2023 15:19:29 +0000 (UTC) (envelope-from jon@xyinn.org) Authentication-Results: mx1.freebsd.org; none Date: Mon, 30 Jan 2023 15:19:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xyinn.org; s=protonmail; t=1675091967; x=1675351167; bh=Sw1UulfqWT8h/B8eXbi7Qg484b7Hcxffdawb3vaY1MY=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=p+vBt1w+mi6bieB0SkFbBcxLndu9B8hGX2+1dyYzANS1YHXrxjLLdJHvYcBow+smN AsLbg8IQVnVYRNnBnVcI9ndwjFDXWkL4JuUR8KSpz3muSi4zh27iO1vrN7WadxMg2A Ep+y41vyUzBNFOKQUEh/LKCtiis28mka9xoLvUlhavaSfoAojQ6SuYZ/qfuIx5RYXo xcoDg+jZIPdHvCnHaMVMMeZACSWM9NA8CHee/b1LMNkcEE38OiLdRj8C4Wt3jDAL6U dy+WUorwdZL9QiIuRqxxtAkc4WO69zJbI5QKTfAiUSIL43kVxB5WU9MgQ0tBv4WKl7 0QoXJ/hkEHqJg== To: DutchDaemon@FreeBSD.org, stable@freebsd.org From: Jonathan Vasquez Subject: Re: Kernel is using a lot of CPU Message-ID: In-Reply-To: References: Feedback-ID: 12351801:user:proton List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_KER1wx2gs2DqzyxpGmMMQZES86exbV2p5QrCkTo" X-Rspamd-Queue-Id: 4P5Bg51dXgz3xxG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_KER1wx2gs2DqzyxpGmMMQZES86exbV2p5QrCkTo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RnJvbSBteSB0ZXN0aW5nIGl0IHNlZW1zIHBlb3BsZSBhcmUgdXNpbmcgYmxhY2tsaXN0IGFuZCBi bG9ja2xpc3QuIEknbSBub3Qgc3VyZSBpZiBwZW9wbGUgYXJlIGNoYW5naW5nIGR1ZSB0byBQQyBy ZWFzb25zIGJ1dCBib3RoIHNlZW1lZCB0byB3b3JrIGZvciBtZS4KCkpvbmF0aGFuIFZhc3F1ZXoK UEdQOiAzNERBIDg1OEMgMTQ0NyA1MDlFIEM3N0EgRDQ5RiBGQjg1IDkwQjcgQzRDQSA1Mjc5ClNl bnQgd2l0aCBQcm90b25NYWlsIFNlY3VyZSBFbWFpbAoKU2VudCBmcm9tIFByb3RvbiBNYWlsIG1v YmlsZQoKLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQpPbiBKYW4gMzAsIDIwMjMs IDA5OjUwLCBEdXRjaERhZW1vbiAtIEZyZWVCU0QgRm9ydW1zIEFkbWluaXN0cmF0b3Igd3JvdGU6 Cgo+IE9uIDMwLzAxLzIwMjMgMTU6NDcsIEV1Z2VuZSBHcm9zYmVpbiB3cm90ZToKPgo+PiAzMC4w MS4yMDIzIDIxOjI3LCBOaWtvcyBWYXNzaWxpYWRpcyB3cm90ZToKPj4KPj4+IDEyLjQgYXV0b2xv YWRlZCBhY3BpX3dtaSB3aXRoIGR1YmlvdXMgcmVzdWx0czoKPj4+Cj4+PiBBdXRvbG9hZGluZyBt b2R1bGU6IGFjcGlfd21pCj4+PiBhY3BpX3dtaTA6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBhY3Bp MAo+Pj4gYWNwaV93bWkwOiBjYW5ub3QgZmluZCBFQyBkZXZpY2UKPj4+IGRldmljZV9hdHRhY2g6 IGFjcGlfd21pMCBhdHRhY2ggcmV0dXJuZWQgNgo+Pj4gYWNwaV93bWkwOiA8QUNQSS1XTUkgbWFw cGluZz4gb24gYWNwaTAKPj4+IGFjcGlfd21pMDogY2Fubm90IGZpbmQgRUMgZGV2aWNlCj4+PiBk ZXZpY2VfYXR0YWNoOiBhY3BpX3dtaTAgYXR0YWNoIHJldHVybmVkIDYKPj4+Cj4+PiAxMi4yIGRp ZCBub3QgYXV0b2xvYWQgaXQuCj4+Cj4+IFlvdSBtYXkgYmxhY2tsaXN0IHRoZSBtb2R1bGUgaW4g L2V0Yy9yYy5jb25mIHRvIGRpc2FibGUgYXV0b2xvYWRpbmcsIGlmIHlvdSB3aXNoOgo+Pgo+PiBk ZXZtYXRjaF9ibGFja2xpc3Q9ImFjcGlfd21pLmtvIgo+Cj4gL2Jsb2NrbGlzdC8= --b1_KER1wx2gs2DqzyxpGmMMQZES86exbV2p5QrCkTo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 RnJvbSBteSB0ZXN0aW5nIGl0IHNlZW1zIHBlb3BsZSBhcmUgdXNpbmcgYmxhY2tsaXN0IGFuZCBi bG9ja2xpc3QuIEknbSBub3Qgc3VyZSBpZiBwZW9wbGUgYXJlIGNoYW5naW5nIGR1ZSB0byBQQyBy ZWFzb25zIGJ1dCBib3RoIHNlZW1lZCB0byB3b3JrIGZvciBtZS48YnI+PGJyPjxicj48ZGl2Pkpv bmF0aGFuIFZhc3F1ZXo8YnIgLz48L2Rpdj48ZGl2PlBHUDogMzREQSA4NThDIDE0NDcgNTA5RSBD NzdBICBENDlGIEZCODUgOTBCNyBDNENBIDUyNzk8YnIgLz48L2Rpdj48ZGl2PlNlbnQgd2l0aCBQ cm90b25NYWlsIFNlY3VyZSBFbWFpbDxiciAvPjwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGJyPjxi cj5TZW50IGZyb20gUHJvdG9uIE1haWwgbW9iaWxlPGJyPjxicj48YnI+PGJyPi0tLS0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+T24gSmFuIDMwLCAyMDIzLCAwOTo1MCwgRHV0Y2hE YWVtb24gLSBGcmVlQlNEIEZvcnVtcyBBZG1pbmlzdHJhdG9yIDwgRHV0Y2hEYWVtb25ARnJlZUJT RC5vcmc+IHdyb3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48YnI+PGh0 bWwgZGF0YS1sdC1pbnN0YWxsZWQ9InRydWUiPg0KICA8aGVhZD4NCiAgICA8bWV0YSBodHRwLWVx dWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQog IDwvaGVhZD4NCiAgPGJvZHkgc3R5bGU9InBhZGRpbmctYm90dG9tOiAxcHg7IiB0ZXh0PSIjMDAw MDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgi Pk9uIDMwLzAxLzIwMjMgMTU6NDcsIEV1Z2VuZSBHcm9zYmVpbg0KICAgICAgd3JvdGU6PGJyPg0K ICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICBjaXRlPSJtaWQ6 ZGQ0Y2M0Y2MtOTY1OS0zZjZjLWQ4MWMtNTA2YzhhNzc3MGUwQGdyb3NiZWluLm5ldCI+DQogICAg ICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPjMwLjAxLjIwMjMgMjE6MjcsIE5p a29zIFZhc3NpbGlhZGlzIHdyb3RlOg0KDQo8L3ByZT4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KICAgICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPjEyLjQg YXV0b2xvYWRlZCBhY3BpX3dtaSB3aXRoIGR1YmlvdXMgcmVzdWx0czoNCg0KQXV0b2xvYWRpbmcg bW9kdWxlOiBhY3BpX3dtaQ0KYWNwaV93bWkwOiAmbHQ7QUNQSS1XTUkgbWFwcGluZyZndDsgb24g YWNwaTANCmFjcGlfd21pMDogY2Fubm90IGZpbmQgRUMgZGV2aWNlDQpkZXZpY2VfYXR0YWNoOiBh Y3BpX3dtaTAgYXR0YWNoIHJldHVybmVkIDYNCmFjcGlfd21pMDogJmx0O0FDUEktV01JIG1hcHBp bmcmZ3Q7IG9uIGFjcGkwDQphY3BpX3dtaTA6IGNhbm5vdCBmaW5kIEVDIGRldmljZQ0KZGV2aWNl X2F0dGFjaDogYWNwaV93bWkwIGF0dGFjaCByZXR1cm5lZCA2DQoNCjEyLjIgZGlkIG5vdCBhdXRv bG9hZCBpdC4NCjwvcHJlPg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPHByZSBjbGFzcz0i bW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCllvdSBtYXkgYmxhY2tsaXN0IHRoZSBtb2R1bGUgaW4g L2V0Yy9yYy5jb25mIHRvIGRpc2FibGUgYXV0b2xvYWRpbmcsIGlmIHlvdSB3aXNoOg0KDQpkZXZt YXRjaF9ibGFja2xpc3Q9ImFjcGlfd21pLmtvIg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0K ICAgIC9ibG9ja2xpc3QvDQogIDwvYm9keT4NCiAgPGx0LWNvbnRhaW5lcj48L2x0LWNvbnRhaW5l cj4NCjwvaHRtbD4NCjwvZGl2Pg== --b1_KER1wx2gs2DqzyxpGmMMQZES86exbV2p5QrCkTo-- From nobody Mon Jan 30 17:22:30 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5FPt5hgyz3c1NX for ; Mon, 30 Jan 2023 17:23:14 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5FPt1xkqz4P53 for ; Mon, 30 Jan 2023 17:23:14 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; none Received: from [10.236.9.9] ([10.236.9.9]) by msvc-mesg-gmx023.server.lan (via HTTP); Mon, 30 Jan 2023 18:22:30 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: Eugene Grosbein Cc: Mike Karels , freebsd-stable@freebsd.org Subject: Re: Re: Kernel is using a lot of CPU Content-Type: text/plain; charset=UTF-8 Importance: normal Sensitivity: Normal Date: Mon, 30 Jan 2023 18:22:30 +0100 In-Reply-To: References: X-Priority: 3 X-Provags-ID: V03:K1:wVsRkD7dWoOMYbL5FB6mfgT2/SMbPh//zJMsxlrnGvKiMrYZjaIYumiLmlzoZF1bDUO4h E9ijQo9+9KcVtN0V1/NI4JHg5dB9xI2KKY2+AIP6D3r1w8bekMcxto2zp4Frf4bFALdT0+22k34+ /YH0Dmxu89os8EUpF09+Al8tkUcTIQfbhWVGagkwmWLvk8jR7LVTGY74CeR4Da23zrRJPr6Kmjbh 0Ef6pkm9Pha1HMEcsMIMdidt0afMFNsyV/6IY3WghIjCCxKF4+ZtxuKqFxeCA+5mRfxOgcnnWrFX e8= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:FagzA+HHGbk=;RPcqkSED3AUug/Mg66EIQ3h4r1x Ts8yeB+OnhF3Ae1LafatHnQQFSgzVvnU6AoZBQvw7IQxqq8c3CDbI67kwJqToxB3Rp/LgWtVn SgHhUofnTBd0RfhEDRFvwDbkeGqq/VUvZnmW7mXOALCQXeZB+JBvWIqDoNkoZlMP8dygk/4i0 Cy1nsRj77DLWHa3dyciry8Zh2Y+hCsQv7nlQFk2tyKGrEn6PO4ED2v3E1vSShs6h3EeJUf09c 6zrWezkEv98H2GTKZJf+k9gMtnh671v7VKHt4OCwVfLE4gHOVsrVyJQFvQzz2yXG9VS1FMZ/e 5/McIghurCyu1TSs5149aADDpy5rSILxrdgDQJjHs0OhFOajD/DH5d6gGh0ZmXTKGHe5FumcT Q57YQDwDLuY+41QVvu4zWm1oGrLk8d27z5HUMP6vKzm4NeZqSI629Op5RBRfPTlu/ZKJXGmDr wroUtV4AKV90Rk3r8y7nlpTP1pWiCaohD79DsHAhJuid/mLmLfopOTRuX0NN0Shp/A5MRYOOK osbipOdAqnh+GIoFHRKz2yJlZoEfR3L7bmmjR/LJKCYPblt/e5nr/cAgkGthE1TDzgPNPuwUO wilrdlWxCPbH6ud1R/cdQCdPQj69U+JihplNYVih9F88yIoPXW+CL3rG7Yj6kv7FL8Vyy6t/e QPr40S6lX1N2kKftVtLNch4L8jy184kLkWII++bc3Lj+mvbwkTvj6Ic69L868LiHoOv2HQc2p /eeBdxPQrUlKFYby1xV08dqf3tSo3bdu6G3aSezG+6IwF2wyAtsg8gCVXsdYn1go7JEo9hI5h j1NGzPL7fT2LxjPIRaz92YLHeDcZ/xG8vjo9lfVDP6b94= X-Rspamd-Queue-Id: 4P5FPt1xkqz4P53 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Sent: Monday, January 30, 2023 at 3:47 PM > From: "Eugene Grosbein" > To: "Nikos Vassiliadis" > Cc: "Mike Karels" , freebsd-stable@freebsd.org > Subject: Re: Kernel is using a lot of CPU > > 30.01.2023 21:27, Nikos Vassiliadis wrote: > > > 12.4 autoloaded acpi_wmi with dubious results: > > > > Autoloading module: acpi_wmi > > acpi_wmi0: on acpi0 > > acpi_wmi0: cannot find EC device > > device_attach: acpi_wmi0 attach returned 6 > > acpi_wmi0: on acpi0 > > acpi_wmi0: cannot find EC device > > device_attach: acpi_wmi0 attach returned 6 > > > > 12.2 did not autoload it. > > You may blacklist the module in /etc/rc.conf to disable autoloading, if you wish: > > devmatch_blacklist="acpi_wmi.ko" > Yes, I removed the module and rebooted. The mysterious load is gone but sadly I am not sure that the module was to blame because after loading it again the load did not re-appear. I leave it blacklisted for the time being... Thanks, Nikos From nobody Mon Jan 30 17:40:46 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5Fps3VZlz3c41h for ; Mon, 30 Jan 2023 17:41:25 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5Fpr72gqz3DZ3; Mon, 30 Jan 2023 17:41:24 +0000 (UTC) (envelope-from nvass@gmx.com) Authentication-Results: mx1.freebsd.org; none Received: from [10.236.9.9] ([10.236.9.9]) by msvc-mesg-gmx003.server.lan (via HTTP); Mon, 30 Jan 2023 18:40:46 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Message-ID: From: Nikos Vassiliadis To: Jonathan Vasquez Cc: DutchDaemon@FreeBSD.org, stable@freebsd.org, eugen@grosbein.net Subject: Re: Re: Kernel is using a lot of CPU Content-Type: text/plain; charset=UTF-8 Importance: normal Sensitivity: Normal Date: Mon, 30 Jan 2023 18:40:46 +0100 In-Reply-To: References: X-Priority: 3 X-Provags-ID: V03:K1:/qwxB4jB12Nv04PKUtVAUebMV/xSjIl8r8UxMmgbfQdomc2c0u6U2Qj+nJOLaqyrzuXJ1 8RkdzRI/Hhd3KC5eDPV3FsgW2iRHQewVMxkOxn5t4JFFzQG8muLYVD22pmot5TE8MJ3XeQlDZ2Nx vVkZRLViW0czrF+cljQwoQ1cCq+agYs2l1L2v2ExX9NJut/u99PPSKcuZEfQlvnHBFGLOV2TACpz smoK0QLHQwYBUSnCdf1WQvAjhDlW9VpxQYalsfFF3louKcde2urSzeu3cvWcj8nHkJvcqpyui431 WA= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:36ESxN0Ym1U=;hvwvgnARX1nzBOgyEfhviCIScX7 BmuGe05BEaBV7/33W7mVuBbAOebCk5WMcobgfvJJxnDemQMWBjRIeg7mayX/pP7OjJrFqi0q8 UHow1sByiAUzsfk1XzNhoilHgq61c3l/ZjA25doXpBKG3LK3W3Y4Oxb17taUY7aVe8LrMuBJL 1X+c/z4aWMlaUSLXZGSM7zGu22bnVri+uUNLd4xGul3/HrmxfWGn7Lc7e/5hfX0Mkmuz9+xYh Zvp5OmLzy/rJFLFtXvMut1oby+MjYBHfzaAlp0SCdrevc3K+AiPlQPOgd/osDSzgUVO5kpAHi e9m05XTfyZSMRzIdleMI2ufcl3vcmbpl+QoU0wReQ19oa6PfXyBvDZZfELHptoXtVcK0IstAA ZyTJ1E1C8TgKV5JMTXCWYun23x1yIWR8atQNnEU4udWWJSmi6o3QcuE7FvmBduINT56eg+HUu KJ03LG1OTvoq1HsUSVo+8rJV6SiPIhGuu4Co+1jgm1atBq9rHMrZ+n8+MJ0y2DPT7FOV13qD7 nUVTWQoCswMeZicSBrA+EmJ+BkM6hAL/JMJ9C/E4dAPpdJMb+sIlMCBVbbto8bSn84wlAyRQu OGGytpijkuA8eTO0ZfHLIZYd4/Sa7myH6CBX5xig1LoIR0AK5oOneGpLHnPyxZHQA8LnfwK9J /AgtNYn+mmtR3+KvcajojA9Sxzaq2eDqjs7zggln2pYzvTvhwNEIfMBFWbScIiVkGJVE+Kjxv itCihxhH7307VyP3mf90nodds6mbkVzbRbSfdyDD6BZfYeT4wg40/Y4hXjgohaw6peF39NFI4 R4fBoMJpGFqQUPMfwWCCn/XQX2Hj6qprnE3bnzKar6ZX8= X-Rspamd-Queue-Id: 4P5Fpr72gqz3DZ3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Sent: Monday, January 30, 2023 at 4:19 PM > From: "Jonathan Vasquez" > To: DutchDaemon@FreeBSD.org, stable@freebsd.org > Subject: Re: Kernel is using a lot of CPU > > From my testing it seems people are using blacklist and blocklist. I'm not sure if people are changing due to PC reasons but both seemed to work for me. Both work due to the nice devmatch rc script: x=$(echo '#'${devmatch_blocklist:-${devmatch_blacklist}}'#' | \ sed -e "s/ /#/g;s/\.ko#/#/g") From nobody Mon Jan 30 21:17:22 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5LcQ3T3Kz3cZvr for ; Mon, 30 Jan 2023 21:17:42 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5LcP0yVhz3xfb for ; Mon, 30 Jan 2023 21:17:41 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 2001:468:c80:a103:2:5000:5555:5555) smtp.mailfrom=paul@gromit.dlib.vt.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id BFFB44CDC6 for ; Mon, 30 Jan 2023 16:17:33 -0500 (EST) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Message-Id: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> Date: Mon, 30 Jan 2023 16:17:22 -0500 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-1.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FREEFALL_USER(0.00)[paul]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4P5LcP0yVhz3xfb X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N TL;DR: When working from home, I can max out my residential 200 Mbit = network connection when downloading from remote Linux hosts at $JOB but = only manage about 20% of my max residential connection speed when = downloading from remote FreeBSD hosts at $JOB. When at $JOB, both = FreeBSD and Linux hosts have no problem saturating their GbE connections = transferring between each other. Why is this and how can I debug and = fix it? I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit = down/~10 Mbit up). I've noticed recently that I can easily get 10--20 = MB/s download speeds when transferring data from Linux hosts at work but = when I try to download that same data from the FreeBSD hosts I use the = speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts = that are on the same subnet at work. Transfers from the FreeBSD hosts = at work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s. So, it just appears to be the traffic = over the WAN to my home that is affected. The WAN path from home to = this subnet is typically 15 hops with a typical average ping latency of = about 23 ms. The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and = 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org = tuning document = (https://calomel.org/freebsd_network_tuning.html), but removed those = tuning settings when I noticed the problem but the problem still = persists. The only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic". (I notice that -CURRENT now has = this as default so wanted to try that on 13-STABLE, too.) The FreeBSD = systems are using either igb or em NICs. The Linux systems are using = similar hardware. None has a problem maintaining local GbE transfer = speeds---it's only the slower/longer WAN connections that have problems = for the FreeBSD hosts. It seems that Linux hosts cope with the WAN path to my home better than = the FreeBSD systems. Has anyone else noticed this? Does anyone have = any idea as to what is obviously going wrong here and how I might = debug/fix the FreeBSD hosts to yield faster speeds? My workaround at = the moment is to favour using the remote Linux hosts for bulk data = transfers. (I don't like this workaround.) Any help/insight is gratefully appreciated. Cheers, Paul.= From nobody Mon Jan 30 21:59:30 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5MXx46Vjz3cjFD for ; Mon, 30 Jan 2023 21:59:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5MXw1Bqgz46Ry for ; Mon, 30 Jan 2023 21:59:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=cpFNLlh2; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl Received: from [IPV6:2a02:22e0:cf00:1ff:c526:f4c3:3a62:2b92] (mzar@[IPv6:2a02:22e0:cf00:1ff:c526:f4c3:3a62:2b92]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 30ULxW47045341 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 30 Jan 2023 22:59:32 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1675115973; bh=5ZS9u3O8sJ+kQ44Wgm7uVgxtQ+Y7bvCkokJkQpcdY7g=; h=Date:To:References:From:Subject:In-Reply-To; b=cpFNLlh27Rcw/jxp6XPvtCZTsceKfTk93f/UDV36STP95daZdVgFodJaWpH7FCFcs mZ9D5j9qiGwbIVg90pqzTuOy98sUYbiEi4GNR0UBHWXvWUcGCs9pXy72yT2PbVdxD1 +4z85OKV/aMBJ1wWlojWMjFSuExi6j6+1cz95XzU0elrIxfNPmFv53LLEUFGXXNle0 u1rNt8ofJw4aLgmv49ZFrUT1ItE0Ad8IANypvMyYQUn9NQZFSr5Yz94xeFxQB4+sXj 4nK9hUzxkBZXepS2d8e5JPOW3eMTuVTTh86nIid5Ge0EeXZD4wp0M079e7mq2s+5zG zNPugyfkL0zgg== Message-ID: <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> Date: Mon, 30 Jan 2023 22:59:30 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: stable@freebsd.org References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> Content-Language: en-US From: Marek Zarychta Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? In-Reply-To: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[stable@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P5MXw1Bqgz46Ry X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N W dniu 30.01.2023 o 22:17, Paul Mather pisze: > TL;DR: When working from home, I can max out my residential 200 Mbit network connection when downloading from remote Linux hosts at $JOB but only manage about 20% of my max residential connection speed when downloading from remote FreeBSD hosts at $JOB. When at $JOB, both FreeBSD and Linux hosts have no problem saturating their GbE connections transferring between each other. Why is this and how can I debug and fix it? > > I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit down/~10 Mbit up). I've noticed recently that I can easily get 10--20 MB/s download speeds when transferring data from Linux hosts at work but when I try to download that same data from the FreeBSD hosts I use the speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts that are on the same subnet at work. Transfers from the FreeBSD hosts at work (within-subnet and within-site) are fine and match those of the Linux hosts---often 112 MB/s. So, it just appears to be the traffic over the WAN to my home that is affected. The WAN path from home to this subnet is typically 15 hops with a typical average ping latency of about 23 ms. > > The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org tuning document (https://calomel.org/freebsd_network_tuning.html), but removed those tuning settings when I noticed the problem but the problem still persists. The only remaining customisation is that the 13-STABLE has "net.inet.tcp.cc.algorithm=cubic". (I notice that -CURRENT now has this as default so wanted to try that on 13-STABLE, too.) The FreeBSD systems are using either igb or em NICs. The Linux systems are using similar hardware. None has a problem maintaining local GbE transfer speeds---it's only the slower/longer WAN connections that have problems for the FreeBSD hosts. > > It seems that Linux hosts cope with the WAN path to my home better than the FreeBSD systems. Has anyone else noticed this? Does anyone have any idea as to what is obviously going wrong here and how I might debug/fix the FreeBSD hosts to yield faster speeds? My workaround at the moment is to favour using the remote Linux hosts for bulk data transfers. (I don't like this workaround.) > > Any help/insight is gratefully appreciated. > > Cheers, > > Paul. > While playing with different mod_cc(4) might bring some improvement, to get a real boost I'd suggest enabling tcp_rack(4) if feasible. -- Marek Zarychta From nobody Mon Jan 30 22:25:07 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5NDL47hSz3bJGQ for ; Mon, 30 Jan 2023 22:30:26 +0000 (UTC) (envelope-from freebsd-stable@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5NDK4ZGcz4GLf for ; Mon, 30 Jan 2023 22:30:25 +0000 (UTC) (envelope-from freebsd-stable@m.gmane-mx.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd-stable@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-stable@m.gmane-mx.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmx.com (policy=none) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pMcaS-0003e3-3A for freebsd-stable@freebsd.org; Mon, 30 Jan 2023 23:25:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: 2yt@gmx.com Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Date: Mon, 30 Jan 2023 15:25:07 -0700 Message-ID: References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US In-Reply-To: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> X-Spamd-Result: default: False [1.29 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.82)[-0.818]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[2yt@gmx.com,freebsd-stable@m.gmane-mx.org]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmx.com : SPF not aligned (relaxed), No valid DKIM,none]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[2yt@gmx.com,freebsd-stable@m.gmane-mx.org]; GREYLIST(0.00)[pass,body]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P5NDK4ZGcz4GLf X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N On 1/30/23 14:17, Paul Mather wrote: > TL;DR: When working from home, I can max out my residential 200 Mbit network connection when downloading from remote Linux hosts at $JOB but only manage about 20% of my max residential connection speed when downloading from remote FreeBSD hosts at $JOB. When at $JOB, both FreeBSD and Linux hosts have no problem saturating their GbE connections transferring between each other. Why is this and how can I debug and fix it? > > I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit down/~10 Mbit up). I've noticed recently that I can easily get 10--20 MB/s download speeds when transferring data from Linux hosts at work but when I try to download that same data from the FreeBSD hosts I use the speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts that are on the same subnet at work. Transfers from the FreeBSD hosts at work (within-subnet and within-site) are fine and match those of the Linux hosts---often 112 MB/s. So, it just appears to be the traffic over the WAN to my home that is affected. The WAN path from home to this subnet is typically 15 hops with a typical average ping latency of about 23 ms. > > The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org tuning document (https://calomel.org/freebsd_network_tuning.html), but removed those tuning settings when I noticed the problem but the problem still persists. The only remaining customisation is that the 13-STABLE has "net.inet.tcp.cc.algorithm=cubic". (I notice that -CURRENT now has this as default so wanted to try that on 13-STABLE, too.) The FreeBSD systems are using either igb or em NICs. The Linux systems are using similar hardware. None has a problem maintaining local GbE transfer speeds---it's only the slower/longer WAN connections that have problems for the FreeBSD hosts. > > It seems that Linux hosts cope with the WAN path to my home better than the FreeBSD systems. Has anyone else noticed this? Does anyone have any idea as to what is obviously going wrong here and how I might debug/fix the FreeBSD hosts to yield faster speeds? My workaround at the moment is to favour using the remote Linux hosts for bulk data transfers. (I don't like this workaround.) > > Any help/insight is gratefully appreciated. > > Cheers, > > Paul. > sysctl net.inet.tcp.cc.algorithm=htcp I would set "htcp" on the server and home computer to improve through in your type of situation. From nobody Mon Jan 30 23:30:00 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5PYK0l5Jz3bRtr for ; Mon, 30 Jan 2023 23:30:13 +0000 (UTC) (envelope-from matt.garber@gmail.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5PYJ2rZrz4MMG for ; Mon, 30 Jan 2023 23:30:12 +0000 (UTC) (envelope-from matt.garber@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="h/RKRUcj"; spf=pass (mx1.freebsd.org: domain of matt.garber@gmail.com designates 2607:f8b0:4864:20::e30 as permitted sender) smtp.mailfrom=matt.garber@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-xe30.google.com with SMTP id p10so9859918vsu.5 for ; Mon, 30 Jan 2023 15:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=uJYK0uJyJJlhByf4b9LqhPx0VGXYnchiGvKAeg8zIeg=; b=h/RKRUcjvO+BWtddOEI0TdzvxbWkRojv0Qzk3tV01swG+PB/2MgAdK1opzx8BSkysR yW7yM03NLe780yy61h8WmheCAr9BBA1c2RVBcqJX2dfILJVcC0Zcnc9S5+zw2kKu8Wr+ tSIxSeFF80Tmb1pWeONj9Ehs9I0mQtoJ1+rCNL3h2CyQhfrQeoT1H/032GBmivvHycJk ZaNLN2Q7uI7Jn1NbU6F7ohelEEfeZjiHsG85Kh5vSFh91ZDgBsyC1z9+aOgM8xiUyLLE eexYU/v+1O88M1bA4SoNF9yq1OHSbW6TkgABEKSIi9Fu5ISDVFKnkSYO0J48SU9G2gMN JaKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uJYK0uJyJJlhByf4b9LqhPx0VGXYnchiGvKAeg8zIeg=; b=ZGF/VPi22ipd18HHZYCOJ7DLROKti85CZYSWEWYOsFOqe3wXK7BDneCtTsm/oSCIsj h4s6yZnp5EVMCx5mF4n7kjSxdbsJwfgye0HoLkmhmpH73cWufGtc7ZRRobgCIzvlfLOy 4Fz1ysg6ZqjRjQSta4dQVPgi2wG0+SwFkDjBt28emgJyI+UFp2/mrGoEhCjG2jlfanvh GpaEc+OILNmVTHbD98vqgn0pjpeW6N8liekyJr2RBQ1IUyb5U0h1AkKgcECKzks5l0cz AW1voAZKdOMQILbpTUq8NgpBw/1Wraz2TTgSFgDBRsN27xbny7R4HxbfOJFZflPuerV8 GqEQ== X-Gm-Message-State: AO0yUKUQZSpHqHg0csfQYHul+wRwne2TFlTFZMXGVd7/Ur3R1fMxIhUa +ETu40sYUB2LSn84MkOjstVQvvC3inscveuBy6UpNhQD X-Google-Smtp-Source: AK7set9MoHmH3Fkmuysuv/0+P44C/zvGIbCkVjlhZySufgCXOCZHNkK8mk03N9OuSqFmuXso0udUcar7IHaCUmyeSxQ= X-Received: by 2002:a05:6102:4b2:b0:3ef:e329:614f with SMTP id r18-20020a05610204b200b003efe329614fmr1999966vsa.25.1675121411549; Mon, 30 Jan 2023 15:30:11 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> In-Reply-To: From: Matt Garber Date: Mon, 30 Jan 2023 18:30:00 -0500 Message-ID: Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? To: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b0f07f05f38398b8" X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P5PYJ2rZrz4MMG X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000b0f07f05f38398b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Any help/insight is gratefully appreciated. > > > > Cheers, > > > > Paul. > > > > sysctl net.inet.tcp.cc.algorithm=3Dhtcp > > I would set "htcp" on the server and home computer to improve through in > your type of situation. There may be other FreeBSD sysctls that have bad defaults in this scenario and could be better tuned, but I doubt changing the CC algorithm at this point is the problem =E2=80=94 at least not so much a problem that=E2=80=99= s causing throughput to be reduced so drastically. Happy to be wrong if that does help things quickly and easily, though. (Since OP mentioned that FreeBSD CC was set to CUBIC, that would match what the Linux boxes are using by default, too, unless they=E2=80=99ve been chan= ged to something newer like BBR=E2=80=A6 so seems like CUBIC *should* be performin= g fine on this WAN link, and the difference is something else.) =E2=80=94Matt --000000000000b0f07f05f38398b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Any help/insight is gratefully appreciated.
>
> Cheers,
>
> Paul.
>

sysctl net.inet.tcp.cc.algorithm=3Dhtcp

I would set "htcp" on the server and home computer to improve thr= ough in
your type of situation.


There may be other= FreeBSD sysctls that have bad defaults in this scenario and could be bette= r tuned, but I doubt changing the CC algorithm at this point is the problem= =E2=80=94 at least not so much a problem that=E2=80=99s causing throughput= to be reduced so drastically. Happy to be wrong if that does help things q= uickly and easily, though.

(Since OP mentioned that FreeBSD CC was set to CUBIC, that would match w= hat the Linux boxes are using by default, too, unless they=E2=80=99ve been = changed to something newer like BBR=E2=80=A6 so seems like CUBIC *should* b= e performing fine on this WAN link, and the difference is something else.)<= /div>


=E2=80=94Matt


--000000000000b0f07f05f38398b8-- From eugen@grosbein.net Tue Jan 31 02:13:52 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5TBd0Vlfz3c6fl for ; Tue, 31 Jan 2023 02:14:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5TBc4skDz3Fw7 for ; Tue, 31 Jan 2023 02:14:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; none Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 30V2ECmf049192 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Jan 2023 02:14:13 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: paul@gromit.dlib.vt.edu Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 30V2ECc8079979 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 31 Jan 2023 09:14:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? To: Paul Mather , FreeBSD-STABLE Mailing List References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> From: Eugene Grosbein Message-ID: <150b0a33-5695-6d12-d86c-0fba0b40d265@grosbein.net> Date: Tue, 31 Jan 2023 09:13:52 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4P5TBc4skDz3Fw7 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 31.01.2023 4:17, Paul Mather wrote: > TL;DR: When working from home, I can max out my residential 200 Mbit network connection when downloading from remote Linux hosts at $JOB but only manage about 20% of my max residential connection speed when downloading from remote FreeBSD hosts at $JOB. When at $JOB, both FreeBSD and Linux hosts have no problem saturating their GbE connections transferring between each other. Why is this and how can I debug and fix it? > > I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit down/~10 Mbit up). I've noticed recently that I can easily get 10--20 MB/s download speeds when transferring data from Linux hosts at work but when I try to download that same data from the FreeBSD hosts I use the speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts that are on the same subnet at work. Transfers from the FreeBSD hosts at work (within-subnet and within-site) are fine and match those of the Linux hosts---often 112 MB/s. So, it just appears to be the traffic over the WAN to my home that is affected. The WAN path from home to this subnet is typically 15 hops with a typical average ping latency of about 23 ms. > > The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org tuning document (https://calomel.org/freebsd_network_tuning.html), but removed those tuning settings when I noticed the problem but the problem still persists. The only remaining customisation is that the 13-STABLE has "net.inet.tcp.cc.algorithm=cubic". (I notice that -CURRENT now has this as default so wanted to try that on 13-STABLE, too.) The FreeBSD systems are using either igb or em NICs. The Linux systems are using similar hardware. None has a problem maintaining local GbE transfer speeds---it's only the slower/longer WAN connections that have problems for the FreeBSD hosts. > > It seems that Linux hosts cope with the WAN path to my home better than the FreeBSD systems. Has anyone else noticed this? Does anyone have any idea as to what is obviously going wrong here and how I might debug/fix the FreeBSD hosts to yield faster speeds? My workaround at the moment is to favour using the remote Linux hosts for bulk data transfers. (I don't like this workaround.) > > Any help/insight is gratefully appreciated. I bet speedy traffic does not cross any NAT boxes but perhaps you employ NAT at your own place. Both pfnat and ipfw nat are not compatible with TSO, also sometimes RX/TX checksum offload for NIC produce broken checksums, and all that creates excessive retransmissions and timeouts greatly reducing traffic speed. You may want to inspect traffic with Wireshark, as it shows retransmissions and generally anomalies with colors, or just go ahead and disable TSO and rxcsum/txcsum for external interface. From nobody Tue Jan 31 01:38:00 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5THG6Cjfz3c70B for ; Tue, 31 Jan 2023 02:18:18 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5THF5K24z3Gxq for ; Tue, 31 Jan 2023 02:18:17 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org; dmarc=none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 30V2IAj0015951 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2023 03:18:10 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: (from uucp@localhost) by uucp.dinoex.org (8.17.1/8.17.1/Submit) with UUCP id 30V2IAYi015950 for freebsd-stable@freebsd.org; Tue, 31 Jan 2023 03:18:10 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 30V1cttp020939 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Tue, 31 Jan 2023 02:38:56 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 30V1c0ZR013953 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2023 02:38:01 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.16.1/8.16.1/Submit) id 30V1c0aU013952 for freebsd-stable@freebsd.org; Tue, 31 Jan 2023 02:38:00 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Tue, 31 Jan 2023 02:38:00 +0100 From: Peter To: freebsd-stable@freebsd.org Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts--- Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 31 Jan 2023 03:18:13 +0100 (CET) X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.945]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[sub.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_FIVE(0.00)[5]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4P5THF5K24z3Gxq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N > TL;DR: When working from home, I can max out my residential 200 Mbit > network connection when downloading from remote Linux hosts at but > only manage about 20% of my max residential connection speed when > downloading from remote FreeBSD I had a similar effect once, when downloading from my cloud site into my home network, which did happen only in specific conditions when routing things around a few more hops in the home network. After experimenting a while with the congestion stuff, it finally resolved quite differently: TSO offloading on the FreeBSD server in the cloud needed to be disabled. From nobody Tue Jan 31 01:45:25 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5THH4hh7z3c72Q for ; Tue, 31 Jan 2023 02:18:19 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5THH0rbNz3H3P for ; Tue, 31 Jan 2023 02:18:19 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org; dmarc=none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 30V2I7KY015939 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2023 03:18:08 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: (from uucp@localhost) by uucp.dinoex.org (8.17.1/8.17.1/Submit) with UUCP id 30V2I7b2015933 for freebsd-stable@freebsd.org; Tue, 31 Jan 2023 03:18:07 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 30V1ltdi025961 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Tue, 31 Jan 2023 02:47:55 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 30V1jPrl014021 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2023 02:45:25 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.16.1/8.16.1/Submit) id 30V1jPNp014020 for freebsd-stable@freebsd.org; Tue, 31 Jan 2023 02:45:25 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Tue, 31 Jan 2023 02:45:25 +0100 From: Peter To: freebsd-stable@freebsd.org Subject: Re: Kernel is using a lot of CPU Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 31 Jan 2023 03:18:10 +0100 (CET) X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.975]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sub.org]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4P5THH0rbNz3H3P X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N > 12.4 autoloaded acpi_wmi with dubious results: > > Autoloading module: acpi_wmi > acpi_wmi0: on acpi0 > acpi_wmi0: cannot find EC device > device_attach: acpi_wmi0 attach returned 6 > acpi_wmi0: on acpi0 > acpi_wmi0: cannot find EC device > device_attach: acpi_wmi0 attach returned 6 > > 12.2 did not autoload it. Ah, the EC. If it "cannot find" the EC, then that might account for unexpected strangeness. The EC is an "embedded controller" that is controlled by the ACPI and does certain kinds of strange things, for instance managing the battery. Some background information is here: https://queue.acm.org/blogposting.cfm?id=18995 If this is a usual elderly desktop connected to mains power, then you may not have it and/or not need it. On my desktop (ivybridge) I can safely do > devmatch_blacklist="acpi_wmi" On my rather modern Lifebook (tigerlake I think) I also get errors from it, but there I need it because otherwise some battery stuff is not done. In my case the error is "no response" and I did not experience unduly CPU load. From nobody Tue Jan 31 15:39:44 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5q455vp6z3bL1b for ; Tue, 31 Jan 2023 15:39:49 +0000 (UTC) (envelope-from 2yt@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5q444GvDz3wmY for ; Tue, 31 Jan 2023 15:39:48 +0000 (UTC) (envelope-from 2yt@gmx.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 2yt@gmx.com designates 212.227.17.21 as permitted sender) smtp.mailfrom=2yt@gmx.com; dmarc=pass (policy=none) header.from=gmx.com Received: from [192.168.160.51] ([47.5.85.140]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MLzFx-1p54rr2hRR-00Hv0e for ; Tue, 31 Jan 2023 16:39:47 +0100 Message-ID: Date: Tue, 31 Jan 2023 08:39:44 -0700 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 From: David <2yt@gmx.com> Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> Content-Language: en-US To: freebsd-stable@freebsd.org In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:O7L7ztbWUaih6b8ZhwTkfvM9x/zy5dDV7IcwKQSG8FyXwNKxXjO GRjmI+NskTycausJCPsN0WGlEJKiYxhaOHkpZS0fEBcovFh0tqu4BBl9mV+TAR81iCc+IEw kqD6lFb6xQpsK6ZqmRX584knVBHG2SlwybPssHbMqZhFNPg3Xdz4J+NbcGrRcR7O2pW/vjk 7tRUOh9yNe3DzMz4TRhWw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Igw2+iv6DSE=;Lq1Z9on01kvLasJSGIQwrX2aVj3 GZe/16oql46BfrD8AopeyACD/C4NWxG1l03Okjngc7p3X+I5UzFccXGusKrB7RugwroSI51yz 1T9otuTTQPvYTAL6l/40asfszh7kQXQWlvswJHFAFqBRoCgo+hV1Ae+i3HeAkhisKfQHQ6weU MlmngDbpS10m6HisK69E4d6p/17d9fCemwCdV54HM+mTIq4JArcGZowyovaRkLX1nv3K+ZVx5 2/lyM/Jmpc2sHPFpsXFwNt9Im/cNWp3Yn898nqoMHGtcCoTzcazfZQ9XvJDrD3BaOtx9n0BCt X8ak4qg+Aixuxqc7Sc2PuMSjGiVtIVB67W0xHu3CxiHEkRS626LpE00IbilowtBrRZy+N64v0 jRLEJLrOzbZUO3PR+EBA9KtJc/UAS2OerLnVs6LPBhwxc4i6RGLCpcrS4ciXLq6MXjENCfKvL zpqJBkqq+Sv3VbraWH7+C+Ir8EV84na7vXm7itXYnA0xT/iI/g74g2zfpOd5dYdT2DCqAsMa8 ZS50f4m6BWY5GdW9ChnvgeWdqGCcoaPLTzIwG1c8/K4Laft34pUxv9WVbaZXDfnvXPHDtHzvw eM1FGeKLZQZc5CraR0lov3FZq93YJS7IhJr4YZzXxxcbqdbGtlKcoFqJ+hJRIHYwvbgyXnfaE U/1lUmXRbXjQELv+AMRDwMdNnqX7q0Xh1VD5pjXgFMYvVgbtz2wzZGXP8ArAIPXGmKFDbl3sN LSYY2ZfehW+bKYYMLzv8tYOLkDOCJKLG/4G3ADlC3eBeeAjX+Nhb/1ebu34Md5kmZDmKARuO1 LZbD0sVYA3aAsye5x7YX3070xmCClBXbHDAXMe51/8gJbPi8qq42kd/i1WCNOaORfLmxTXKtC 1vqeVGysq4RkIUTvPH5ucSaOBQPqYMGTUk5u5EcBySkZ+ye67w5cQ3dYumDxjdrTKw4cj3wtq qGtVVw== X-Spamd-Result: default: False [-0.11 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; NEURAL_SPAM_LONG(0.88)[0.881]; DMARC_POLICY_ALLOW(-0.50)[gmx.com,none]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; NEURAL_HAM_SHORT(-0.11)[-0.107]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.21:from]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmx.com]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.21:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P5q444GvDz3wmY X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On 1/30/23 16:30, Matt Garber wrote: > > > Any help/insight is gratefully appreciated. > > > > Cheers, > > > > Paul. > > > > sysctl net.inet.tcp.cc.algorithm=htcp > > I would set "htcp" on the server and home computer to improve > through in > your type of situation. > > > > There may be other FreeBSD sysctls that have bad defaults in this > scenario and could be better tuned, but I doubt changing the CC > algorithm at this point is the problem — at least not so much a problem > that’s causing throughput to be reduced so drastically. Happy to be > wrong if that does help things quickly and easily, though. > > (Since OP mentioned that FreeBSD CC was set to CUBIC, that would match > what the Linux boxes are using by default, too, unless they’ve been > changed to something newer like BBR… so seems like CUBIC *should* be > performing fine on this WAN link, and the difference is something else.) > > > —Matt > I love FreeBSD and very much appreciate the efforts of those people much smarter. But... I don't think the defaults get enough testing in real world conditions. I came across Paul's issue several years ago and spent a few a hours testing and found the defaults performed very well on a LAN but could perform terribly on a many hop WAN. HTCP performs marginally worse on a LAN or close WAN connection, but much much better on a many hop WAN connection. Testing: ------------------------------------ All computers are running FreeBSD 13.1. File transfer done with SCP. No changes were made between runs other than toggling the cc.algorithm. Be sure to run sysctl net.inet.tcp.hostcache.expire=1 before testing. (default 3600) HOST 1) 10 hops and 50ms pings. Connection limited to 120mb ------------------------------------ Run #1 NEWRENO 100% 315MB 13.0MB/s 00:24 HTCP 100% 315MB 12.8MB/s 00:24 Run #2 NEWRENO 100% 315MB 13.2MB/s 00:23 HTCP 100% 315MB 12.8MB/s 00:24 HOST 2) 17 hops and 110ms pings. Connection limited to 100mb ------------------------------------ Run #1 NEWRENO 100% 315MB 1.1MB/s 04:48 HTCP 100% 315MB 10.5MB/s 00:30 Run #2 NEWRENO 100% 315MB 1.6MB/s 03:22 HTCP 100% 315MB 3.5MB/s 01:29 Run #3 NEWRENO 100% 315MB 1.3MB/s 04:00 HTCP 100% 315MB 10.8MB/s 00:29 In my opinion HTCP is a better default for the current state of the internet. Cheers, David From nobody Tue Jan 31 18:31:29 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5ttT75GMz3bwny for ; Tue, 31 Jan 2023 18:31:45 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5ttT5FC1z4HWQ for ; Tue, 31 Jan 2023 18:31:45 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0200D511A2; Tue, 31 Jan 2023 13:31:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> Date: Tue, 31 Jan 2023 13:31:29 -0500 Cc: stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> To: Marek Zarychta X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5ttT5FC1z4HWQ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 30, 2023, at 4:59 PM, Marek Zarychta = wrote: > W dniu 30.01.2023 o 22:17, Paul Mather pisze: >> TL;DR: When working from home, I can max out my residential 200 Mbit = network connection when downloading from remote Linux hosts at $JOB but = only manage about 20% of my max residential connection speed when = downloading from remote FreeBSD hosts at $JOB. When at $JOB, both = FreeBSD and Linux hosts have no problem saturating their GbE connections = transferring between each other. Why is this and how can I debug and = fix it? >>=20 >> I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit = down/~10 Mbit up). I've noticed recently that I can easily get 10--20 = MB/s download speeds when transferring data from Linux hosts at work but = when I try to download that same data from the FreeBSD hosts I use the = speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts = that are on the same subnet at work. Transfers from the FreeBSD hosts = at work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s. So, it just appears to be the traffic = over the WAN to my home that is affected. The WAN path from home to = this subnet is typically 15 hops with a typical average ping latency of = about 23 ms. >>=20 >> The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and = 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org = tuning document = (https://calomel.org/freebsd_network_tuning.html), but removed those = tuning settings when I noticed the problem but the problem still = persists. The only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic". (I notice that -CURRENT now has = this as default so wanted to try that on 13-STABLE, too.) The FreeBSD = systems are using either igb or em NICs. The Linux systems are using = similar hardware. None has a problem maintaining local GbE transfer = speeds---it's only the slower/longer WAN connections that have problems = for the FreeBSD hosts. >>=20 >> It seems that Linux hosts cope with the WAN path to my home better = than the FreeBSD systems. Has anyone else noticed this? Does anyone = have any idea as to what is obviously going wrong here and how I might = debug/fix the FreeBSD hosts to yield faster speeds? My workaround at = the moment is to favour using the remote Linux hosts for bulk data = transfers. (I don't like this workaround.) >>=20 >> Any help/insight is gratefully appreciated. >>=20 >> Cheers, >>=20 >> Paul. >>=20 > While playing with different mod_cc(4) might bring some improvement, = to get a real boost I'd suggest enabling tcp_rack(4) if feasible. I am interested in trying this out, but believe it is more feasible in = my case for the -STABLE and -CURRENT systems I am using, not so much for = the -RELEASE systems that are kept up to date via binary freebsd-update = updates. My reading of the tcp_rack(4) man page is that you have to = build a custom kernel as, unlike the cc_* congestion control algorithms, = the loadable tcp_rack module is not built by default. Is that an = accurate reading? Cheers, Paul. From nobody Tue Jan 31 19:31:49 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5wD039KRz3c51s for ; Tue, 31 Jan 2023 19:32:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5wD02mFlz4P2L for ; Tue, 31 Jan 2023 19:32:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id AA19451605; Tue, 31 Jan 2023 14:31:59 -0500 (EST) From: Paul Mather Message-Id: <55B6F3B3-1676-476D-9784-63164930199B@gromit.dlib.vt.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_72FB16F0-865A-43BF-9F71-D02BAB1D8931" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Date: Tue, 31 Jan 2023 14:31:49 -0500 In-Reply-To: Cc: freebsd-stable@freebsd.org To: 2yt@gmx.com References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5wD02mFlz4P2L X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_72FB16F0-865A-43BF-9F71-D02BAB1D8931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 30, 2023, at 5:25 PM, 2yt@gmx.com wrote: > On 1/30/23 14:17, Paul Mather wrote: >> TL;DR: When working from home, I can max out my residential 200 Mbit = network connection when downloading from remote Linux hosts at $JOB but = only manage about 20% of my max residential connection speed when = downloading from remote FreeBSD hosts at $JOB. When at $JOB, both = FreeBSD and Linux hosts have no problem saturating their GbE connections = transferring between each other. Why is this and how can I debug and = fix it? >> I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit = down/~10 Mbit up). I've noticed recently that I can easily get 10--20 = MB/s download speeds when transferring data from Linux hosts at work but = when I try to download that same data from the FreeBSD hosts I use the = speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts = that are on the same subnet at work. Transfers from the FreeBSD hosts = at work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s. So, it just appears to be the traffic = over the WAN to my home that is affected. The WAN path from home to = this subnet is typically 15 hops with a typical average ping latency of = about 23 ms. >> The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and = 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org = tuning document = (https://calomel.org/freebsd_network_tuning.html), but removed those = tuning settings when I noticed the problem but the problem still = persists. The only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic". (I notice that -CURRENT now has = this as default so wanted to try that on 13-STABLE, too.) The FreeBSD = systems are using either igb or em NICs. The Linux systems are using = similar hardware. None has a problem maintaining local GbE transfer = speeds---it's only the slower/longer WAN connections that have problems = for the FreeBSD hosts. >> It seems that Linux hosts cope with the WAN path to my home better = than the FreeBSD systems. Has anyone else noticed this? Does anyone = have any idea as to what is obviously going wrong here and how I might = debug/fix the FreeBSD hosts to yield faster speeds? My workaround at = the moment is to favour using the remote Linux hosts for bulk data = transfers. (I don't like this workaround.) >> Any help/insight is gratefully appreciated. >> Cheers, >> Paul. >=20 > sysctl net.inet.tcp.cc.algorithm=3Dhtcp >=20 > I would set "htcp" on the server and home computer to improve through = in your type of situation. I did not mention this explicitly but part of the "some TCP tuning based = upon the calomel.org tuning document" I mention = having done (and then removed) was to use the "htcp" congestion control = algorithm. I restored the use of "htcp" at your suggestion and notice = it does improve matters slightly, but I still get nowhere near maxing = out my download pipe as I can when downloading from Linux hosts at $JOB. = Switching back to "htcp" on the FreeBSD servers improves matters from = 3--4 MB/s for bulk downloads to 5--6 MB/s (with some variability) based = upon several test downloads. The clients at home are a mixture but typically are macOS and FreeBSD. = My home setup uses OPNsense 23.1 as a gateway, using NAT for IPv4 and = Hurricane Electric for IPv6. (I'm using "htcp" CC on OPNsense. I'm = also using the Traffic Shaper on OPNsense and have a FQ_CoDel setup = defined that yields an A/A+ result on BufferBloat tests.) The remote = servers at $JOB (both Linux and FreeBSD) are on the same subnet as each = other and not behind a NAT. I have been doing the download tests over = IPv4 ("curl -v -4 -o /dev/null ..."). Cheers, Paul.= --Apple-Mail=_72FB16F0-865A-43BF-9F71-D02BAB1D8931 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 30, 2023, at = 5:25 PM, 2yt@gmx.com wrote:

On 1/30/23 14:17, Paul Mather wrote:
TL;DR: When working from home, I can max out my = residential 200 Mbit network connection when downloading from remote = Linux hosts at $JOB but only manage about 20% of my max residential = connection speed when downloading from remote FreeBSD hosts at $JOB. =  When at $JOB, both FreeBSD and Linux hosts have no problem = saturating their GbE connections transferring between each other. =  Why is this and how can I debug and fix it?
I have a 200 Mbit = residential cable connection (Xfinity, 200 Mbit down/~10 Mbit up). =  I've noticed recently that I can easily get 10--20 MB/s download = speeds when transferring data from Linux hosts at work but when I try to = download that same data from the FreeBSD hosts I use the speed usually = tops out at 3--4 MB/s.  These are Linux and FreeBSD hosts that are = on the same subnet at work.  Transfers from the FreeBSD hosts at = work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s.  So, it just appears to be the = traffic over the WAN to my home that is affected.  The WAN path = from home to this subnet is typically 15 hops with a typical average = ping latency of about 23 ms.
The FreeBSD hosts are a mixture of = -CURRENT, 13-STABLE, and 13.1-RELEASE.  I had done some TCP tuning = based upon the calomel.org <http://calomel.org/> tuning document = (https://calomel.o= rg/freebsd_network_tuning.html), but removed those tuning settings = when I noticed the problem but the problem still persists.  The = only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic".  (I notice that -CURRENT now = has this as default so wanted to try that on 13-STABLE, too.)  The = FreeBSD systems are using either igb or em NICs.  The Linux systems = are using similar hardware.  None has a problem maintaining local = GbE transfer speeds---it's only the slower/longer WAN connections that = have problems for the FreeBSD hosts.
It seems that Linux hosts cope = with the WAN path to my home better than the FreeBSD systems.  Has = anyone else noticed this?  Does anyone have any idea as to what is = obviously going wrong here and how I might debug/fix the FreeBSD hosts = to yield faster speeds?  My workaround at the moment is to favour = using the remote Linux hosts for bulk data transfers.  (I don't = like this workaround.)
Any help/insight is gratefully = appreciated.
Cheers,
Paul.

sysctl = net.inet.tcp.cc.algorithm=3Dhtcp

I would set "htcp" on the server = and home computer to improve through in your type of = situation.


I did not mention this explicitly but = part of the "some TCP tuning based upon the calomel.org tuning document" I = mention having done (and then removed) was to use the "htcp" congestion = control algorithm.  I restored the use of "htcp" at your suggestion = and notice it does improve matters slightly, but I still get nowhere = near maxing out my download pipe as I can when downloading from Linux = hosts at $JOB.  Switching back to "htcp" on the FreeBSD servers = improves matters from 3--4 MB/s for bulk downloads to 5--6 MB/s (with = some variability) based upon several test downloads.

The clients at home = are a mixture but typically are macOS and FreeBSD.  My home setup = uses OPNsense 23.1 as a gateway, using NAT for IPv4 and Hurricane = Electric for IPv6.  (I'm using "htcp" CC on OPNsense.  I'm = also using the Traffic Shaper on OPNsense and have a FQ_CoDel setup = defined that yields an A/A+ result on BufferBloat tests.)  The = remote servers at $JOB (both Linux and FreeBSD) are on the same subnet = as each other and not behind a NAT.  I have been doing the download = tests over IPv4 ("curl -v -4 -o /dev/null ...").

Cheers,

Paul.
= --Apple-Mail=_72FB16F0-865A-43BF-9F71-D02BAB1D8931-- From nobody Tue Jan 31 20:38:25 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5xhp2KxBz3cFJX for ; Tue, 31 Jan 2023 20:38:34 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5xhn5bRzz3LLW for ; Tue, 31 Jan 2023 20:38:33 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2a02:22e0:cf00:1ff:b17d:1e6f:50a2:6f71] (mzar@[IPv6:2a02:22e0:cf00:1ff:b17d:1e6f:50a2:6f71]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 30VKcRc3002504 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 31 Jan 2023 21:38:28 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1675197509; bh=J09Y0RNsltBEZkhlKkoiDO1nnqVUBQxyR2uniQVghRg=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=gi17opZcyEfeA9dvIbZgIwmstdsiVpim8O4YXN3FmzCi4IKSjnQkfqLhL+1RDZg5j wumWtZGbylDw15bZBrtD84OO4gNzvbchKA27z6vC/hGxg5CNolw+aeCfhJn1oPNxQJ XJCtHTZ6GoAXLo8dzrdZdUWl52zDSe6YzoAtDlEpcobZMiTA0c0CX6quZx+GrBWovD ANzzUnMj7AAc5zHG0VsKE2NKcUppZNYlxnCVMD8cmXGhfGif2Hg6NrjOu9NHAchVRz DXv/81fwktMIe0kj0993gxtYLa1K4Xg8ksTeG8sqRZGff6Uqzb2B39AVOc7g7sjzrW XuvPkKy/jA8IQ== Message-ID: <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Date: Tue, 31 Jan 2023 21:38:25 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Paul Mather Cc: stable@freebsd.org References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> Content-Language: en-US From: Marek Zarychta Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? In-Reply-To: <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P5xhn5bRzz3LLW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N W dniu 31.01.2023 o 19:31, Paul Mather pisze: >> While playing with different mod_cc(4) might bring some improvement, to get a real boost I'd suggest enabling tcp_rack(4) if feasible. > > I am interested in trying this out, but believe it is more feasible in my case for the -STABLE and -CURRENT systems I am using, not so much for the -RELEASE systems that are kept up to date via binary freebsd-update updates. My reading of the tcp_rack(4) man page is that you have to build a custom kernel as, unlike the cc_* congestion control algorithms, the loadable tcp_rack module is not built by default. Is that an accurate reading? > Yes, this gift from Netflix is probably better suited for -STABLE and -CURRENT as easier to set up there. There is an excellent, up-to-date article about it by Klara Systems writers[1]. From my experience tcp_rack(4) is well suited for congested, lossy or redundant network paths where loses, duplicated packets or races between packets occur. Not a panacea, but very performant TCP stack based on the _fair_  algorithm. In some instances, it might help you to saturate the bandwidth of the link. TCP algo can be loaded/unloaded/changed on the fly. In FreeBSD 14-CURRENT you can change it on an active socket with tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app bound to the socket. Please feel free to play with TCP stacks and congestion algos with the help of benchmarks/iperf3 to find out what prevents the link from being saturated and give us some feedback here. [1] https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ Cheers -- Marek Zarychta From nobody Tue Jan 31 21:05:44 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5yJS1gnLz3cJLF for ; Tue, 31 Jan 2023 21:06:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5yJQ6cpFz3Nhl for ; Tue, 31 Jan 2023 21:05:58 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 30VL5iOK018645 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 31 Jan 2023 16:05:50 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Tue, 31 Jan 2023 16:05:44 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? To: stable@freebsd.org References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Content-Language: en-US From: George Mitchell In-Reply-To: <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-2.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.94)[-0.936]; NEURAL_HAM_SHORT(-0.86)[-0.861]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[m5p.com]; TAGGED_FROM(0.00)[freebsd]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P5yJQ6cpFz3Nhl X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On 1/31/23 15:38, Marek Zarychta wrote: > W dniu 31.01.2023 o 19:31, Paul Mather pisze: >>> While playing with different mod_cc(4) might bring some improvement, >>> to get a real boost I'd suggest enabling tcp_rack(4) if feasible. >> >> I am interested in trying this out, but believe it is more feasible in >> my case for the -STABLE and -CURRENT systems I am using, not so much >> for the -RELEASE systems that are kept up to date via binary >> freebsd-update updates.  My reading of the tcp_rack(4) man page is >> that you have to build a custom kernel as, unlike the cc_* congestion >> control algorithms, the loadable tcp_rack module is not built by >> default.  Is that an accurate reading? >> > Yes, this gift from Netflix is probably better suited for -STABLE and > -CURRENT as easier to set up there. There is an excellent, up-to-date > article about it by Klara Systems writers[1]. From my experience > tcp_rack(4) is well suited for congested, lossy or redundant network > paths where loses, duplicated packets or races between packets occur. > Not a panacea, but very performant TCP stack based on the _fair_ > algorithm. In some instances, it might help you to saturate the > bandwidth of the link. TCP algo can be loaded/unloaded/changed on the > fly. In FreeBSD 14-CURRENT you can change it on an active socket with > tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app > bound to the socket. > Please feel free to play with TCP stacks and congestion algos with the > help of benchmarks/iperf3 to find out what prevents the link from being > saturated and give us some feedback here. > > [1] https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ > > Cheers > Wow! I'm a long time FreeBSD user (from the days of 1.1.5.1) and internet user (since 1990), but this thread has made it clear that I have been remiss on keeping up with developments in the TCP world. Is there a chance someone might update section IV of the handbook with some of this material? Also, does anyone on this thread know if these settings might interact (beneficially or not) with TOR? -- George From nobody Tue Jan 31 21:12:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5ySX2yz6z3cJwf for ; Tue, 31 Jan 2023 21:13:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5ySX1G4Nz3Ptj for ; Tue, 31 Jan 2023 21:13:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id DAFD7518E3; Tue, 31 Jan 2023 16:12:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: <150b0a33-5695-6d12-d86c-0fba0b40d265@grosbein.net> Date: Tue, 31 Jan 2023 16:12:48 -0500 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <03DC7A96-7945-4C8B-A062-F8F00BD690C4@gromit.dlib.vt.edu> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <150b0a33-5695-6d12-d86c-0fba0b40d265@grosbein.net> To: Eugene Grosbein X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5ySX1G4Nz3Ptj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 30, 2023, at 9:13 PM, Eugene Grosbein wrote: > 31.01.2023 4:17, Paul Mather wrote: >=20 >> TL;DR: When working from home, I can max out my residential 200 Mbit = network connection when downloading from remote Linux hosts at $JOB but = only manage about 20% of my max residential connection speed when = downloading from remote FreeBSD hosts at $JOB. When at $JOB, both = FreeBSD and Linux hosts have no problem saturating their GbE connections = transferring between each other. Why is this and how can I debug and = fix it? >>=20 >> I have a 200 Mbit residential cable connection (Xfinity, 200 Mbit = down/~10 Mbit up). I've noticed recently that I can easily get 10--20 = MB/s download speeds when transferring data from Linux hosts at work but = when I try to download that same data from the FreeBSD hosts I use the = speed usually tops out at 3--4 MB/s. These are Linux and FreeBSD hosts = that are on the same subnet at work. Transfers from the FreeBSD hosts = at work (within-subnet and within-site) are fine and match those of the = Linux hosts---often 112 MB/s. So, it just appears to be the traffic = over the WAN to my home that is affected. The WAN path from home to = this subnet is typically 15 hops with a typical average ping latency of = about 23 ms. >>=20 >> The FreeBSD hosts are a mixture of -CURRENT, 13-STABLE, and = 13.1-RELEASE. I had done some TCP tuning based upon the calomel.org = tuning document = (https://calomel.org/freebsd_network_tuning.html), but removed those = tuning settings when I noticed the problem but the problem still = persists. The only remaining customisation is that the 13-STABLE has = "net.inet.tcp.cc.algorithm=3Dcubic". (I notice that -CURRENT now has = this as default so wanted to try that on 13-STABLE, too.) The FreeBSD = systems are using either igb or em NICs. The Linux systems are using = similar hardware. None has a problem maintaining local GbE transfer = speeds---it's only the slower/longer WAN connections that have problems = for the FreeBSD hosts. >>=20 >> It seems that Linux hosts cope with the WAN path to my home better = than the FreeBSD systems. Has anyone else noticed this? Does anyone = have any idea as to what is obviously going wrong here and how I might = debug/fix the FreeBSD hosts to yield faster speeds? My workaround at = the moment is to favour using the remote Linux hosts for bulk data = transfers. (I don't like this workaround.) >>=20 >> Any help/insight is gratefully appreciated. >=20 > I bet speedy traffic does not cross any NAT boxes but perhaps you = employ NAT at your own place. > Both pfnat and ipfw nat are not compatible with TSO, also sometimes = RX/TX checksum offload for NIC produce broken checksums, > and all that creates excessive retransmissions and timeouts greatly = reducing traffic speed. My IPv4 clients at home are behind a NAT router (OPNsense 23.1 with HTCP = CC enabled and FQ_CoDel traffic shaper configured). The remote systems = at $JOB are not behind NAT. On my OPNsense router I have disabled = hardware offloading as (IIRC) these are generally not recommended for = routers. As such, I have "Disable hardware checksum offload"; "Disable = hardware TCP segmentation offload"; and "Disable hardware large receive = offload" all checked in Interfaces -> Settings in OPNsense. The home = router running OPNsense uses NICs that identify as "82583V Gigabit = Network Connection" (emX@pci0:X:0:0: class=3D0x020000 rev=3D0x00 = hdr=3D0x00 vendor=3D0x8086 device=3D0x150c subvendor=3D0x8086 = subdevice=3D0x0000). The FreeBSD systems at $JOB default to having TSO and RXCSUM/TXCSUM = enabled. I disabled these but it didn't make any apparent difference in = improving speeds. I looked at a Linux system on similar hardware and = "ethtool -k" indicates it also has TSO and RX/TX checksum offloading = enabled. > You may want to inspect traffic with Wireshark, as it shows = retransmissions and generally anomalies with colors, > or just go ahead and disable TSO and rxcsum/txcsum for external = interface. I'm going to pursue this next. I made Wireshark captures at the client = end but need to collect packet traces at the server side. Also, with = the help of your suggestion, I managed to find a colour configuration to = highlight retransmissions. Hopefully that might help differentiate the = FreeBSD vs. Linux situation. I'm not great at grokking Wireshark traces = but I guess I'm about to get better in the future. :-) Thanks for the suggestions. Cheers, Paul. From nobody Tue Jan 31 21:17:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5yZP73Q6z3cKph for ; Tue, 31 Jan 2023 21:18:05 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5yZP4vvJz3R9r for ; Tue, 31 Jan 2023 21:18:05 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id EEB45518E9; Tue, 31 Jan 2023 16:17:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts--- From: Paul Mather In-Reply-To: Date: Tue, 31 Jan 2023 16:17:48 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C08DA8D-D3A1-4225-B168-CAEB745542D4@gromit.dlib.vt.edu> References: To: Peter X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5yZP4vvJz3R9r X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 30, 2023, at 8:38 PM, Peter wrote: >=20 >=20 >> TL;DR: When working from home, I can max out my residential 200 Mbit >> network connection when downloading from remote Linux hosts at but >> only manage about 20% of my max residential connection speed when >> downloading from remote FreeBSD >=20 > I had a similar effect once, when downloading from my cloud site into > my home network, which did happen only in specific conditions when > routing things around a few more hops in the home network. >=20 > After experimenting a while with the congestion stuff, it finally > resolved quite differently: TSO offloading on the FreeBSD server in > the cloud needed to be disabled. At both your and Eugene Grosbein's suggestion I tried disabling this at = the remote FreeBSD side but it didn't appear to have any discernible = impact on speeds. (It is disabled at my home router end.) Thanks for = the suggestion. Cheers, Paul. From nobody Tue Jan 31 21:32:20 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5yv92LH9z3cMRd for ; Tue, 31 Jan 2023 21:32:37 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5yv86T4qz3jKT for ; Tue, 31 Jan 2023 21:32:36 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.126.123) smtp.mailfrom=paul@gromit.dlib.vt.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id AD3705197A; Tue, 31 Jan 2023 16:32:31 -0500 (EST) From: Paul Mather Message-Id: <8A1B625C-D948-43C4-B787-DFB8A25BBF7A@gromit.dlib.vt.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE7EC00B-3170-4B90-9FE3-DF492002C429" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Date: Tue, 31 Jan 2023 16:32:20 -0500 In-Reply-To: Cc: freebsd-stable@freebsd.org To: Matt Garber References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-1.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.994]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEFALL_USER(0.00)[paul]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P5yv86T4qz3jKT X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_AE7EC00B-3170-4B90-9FE3-DF492002C429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 30, 2023, at 6:30 PM, Matt Garber wrote: >=20 >> > Any help/insight is gratefully appreciated. >> >=20 >> > Cheers, >> >=20 >> > Paul. >> >=20 >>=20 >> sysctl net.inet.tcp.cc.algorithm=3Dhtcp >>=20 >> I would set "htcp" on the server and home computer to improve through = in=20 >> your type of situation. >=20 >=20 > There may be other FreeBSD sysctls that have bad defaults in this = scenario and could be better tuned, but I doubt changing the CC = algorithm at this point is the problem =E2=80=94 at least not so much a = problem that=E2=80=99s causing throughput to be reduced so drastically. = Happy to be wrong if that does help things quickly and easily, though. Changing the CC algorithm doesn't affect speeds greatly in my case. For = example, changing to HTCP on one of the remote FreeBSD systems improves = speeds somewhat, but not to put them on a par with what I get from the = Linux systems. I can easily get 19--20 MB/s on a 100 MB download from = Linux but I've never managed to get above 10 MB/s at all from the remote = FreeBSD systems, even when switching to HTCP. In addition, the Linux = download quickly gets up to max speed but FreeBSD is slower to increase = speeds and is more variable in the speeds throughout the entire = download. > (Since OP mentioned that FreeBSD CC was set to CUBIC, that would match = what the Linux boxes are using by default, too, unless they=E2=80=99ve = been changed to something newer like BBR=E2=80=A6 so seems like CUBIC = *should* be performing fine on this WAN link, and the difference is = something else.) I suspect the same thing, too, i.e., it is implementation/specific = configuration details that differ between FreeBSD and Linux, especially = when they are both set to use CUBIC. I checked on one of the Linux systems (Rocky Linux 9) and verified it = defaults to CUBIC (net.ipv4.tcp_congestion_control =3D cubic). Cheers, Paul. --Apple-Mail=_AE7EC00B-3170-4B90-9FE3-DF492002C429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 30, = 2023, at 6:30 PM, Matt Garber <matt.garber@gmail.com> = wrote:


> Any help/insight is gratefully appreciated.
>
> Cheers,
>
> Paul.
>

sysctl net.inet.tcp.cc.algorithm=3Dhtcp

I would set "htcp" on the server and home computer to improve through in =
your type of situation.


There may = be other FreeBSD sysctls that have bad defaults in this scenario and = could be better tuned, but I doubt changing the CC algorithm at this = point is the problem =E2=80=94 at least not so much a problem that=E2=80=99= s causing throughput to be reduced so drastically. Happy to be wrong if = that does help things quickly and easily, = though.


=
Changing the CC algorithm doesn't affect speeds greatly in my case. =  For example, changing to HTCP on one of the remote FreeBSD systems = improves speeds somewhat, but not to put them on a par with what I get = from the Linux systems.  I can easily get 19--20 MB/s on a 100 MB = download from Linux but I've never managed to get above 10 MB/s at all = from the remote FreeBSD systems, even when switching to HTCP.  In = addition, the Linux download quickly gets up to max speed but FreeBSD is = slower to increase speeds and is more variable in the speeds throughout = the entire download.


(Since OP mentioned that = FreeBSD CC was set to CUBIC, that would match what the Linux boxes are = using by default, too, unless they=E2=80=99ve been changed to something = newer like BBR=E2=80=A6 so seems like CUBIC *should* be performing fine = on this WAN link, and the difference is something = else.)


I = suspect the same thing, too, i.e., it is implementation/specific = configuration details that differ between FreeBSD and Linux, especially = when they are both set to use CUBIC.

I checked = on one of the Linux systems (Rocky Linux 9) and verified it defaults to = CUBIC (net.ipv4.tcp_congestion_control =3D = cubic).

Cheers,

Paul.
= --Apple-Mail=_AE7EC00B-3170-4B90-9FE3-DF492002C429-- From nobody Tue Jan 31 22:03:08 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P5zZp3mr4z3cR1H for ; Tue, 31 Jan 2023 22:03:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P5zZp2ww1z3rMR for ; Tue, 31 Jan 2023 22:03:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7B0255167E; Tue, 31 Jan 2023 17:03:19 -0500 (EST) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: Date: Tue, 31 Jan 2023 17:03:08 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> To: David <2yt@gmx.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P5zZp2ww1z3rMR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 31, 2023, at 10:39 AM, David <2yt@gmx.com> wrote: > On 1/30/23 16:30, Matt Garber wrote: >> > Any help/insight is gratefully appreciated. >> > >> > Cheers, >> > >> > Paul. >> > >> sysctl net.inet.tcp.cc.algorithm=3Dhtcp >> I would set "htcp" on the server and home computer to improve >> through in >> your type of situation. >> There may be other FreeBSD sysctls that have bad defaults in this = scenario and could be better tuned, but I doubt changing the CC = algorithm at this point is the problem =E2=80=94 at least not so much a = problem that=E2=80=99s causing throughput to be reduced so drastically. = Happy to be wrong if that does help things quickly and easily, though. >> (Since OP mentioned that FreeBSD CC was set to CUBIC, that would = match what the Linux boxes are using by default, too, unless they=E2=80=99= ve been changed to something newer like BBR=E2=80=A6 so seems like CUBIC = *should* be performing fine on this WAN link, and the difference is = something else.) >> =E2=80=94Matt >=20 > I love FreeBSD and very much appreciate the efforts of those people = much smarter. But... I don't think the defaults get enough testing in = real world conditions. >=20 > I came across Paul's issue several years ago and spent a few a hours = testing and found the defaults performed very well on a LAN but could = perform terribly on a many hop WAN. HTCP performs marginally worse on a = LAN or close WAN connection, but much much better on a many hop WAN = connection. >=20 [[...]] > In my opinion HTCP is a better default for the current state of the = internet. It looks like they already changed the default from NewReno to CUBIC in = FreeBSD-CURRENT. I agree with your observation about the defaults vs. real world = conditions. As you observed, I also get great performance in a = high-speed LAN, but not so much in a many-hop WAN to an asymmetric ISP = connection. I actually started down this rabbit hole when I noticed I couldn't = manage more than about 3--4 MB in a single stream and thought my ISP was = throttling me. But then I noticed I would actually get fast/maximum = speeds, e.g., when doing "brew upgrade -v" and Homebrew would be = downloading packages, and so then wondered whether they were throttling = non-HTTP traffic. That led me to discover that even HTTP downloads were = slow to the FreeBSD servers I use remotely at $JOB and, furthermore, = that all traffic to Linux systems I use at $JOB didn't seem to be = throttled or incapable of getting maximum single stream bandwidth = matching my ISP's quoted speeds. :-\ I accept that this may just be a peculiarity of my local and remote = setup, and so appreciate the help and suggestions people have offered in = trying to debug the issue. Cheers, Paul.= From nobody Wed Feb 1 00:27:42 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P62nR5LCpz3cylR for ; Wed, 1 Feb 2023 00:27:55 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P62nR3H0Vz45NL for ; Wed, 1 Feb 2023 00:27:55 +0000 (UTC) (envelope-from nonesuch@longcount.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-xe30.google.com with SMTP id y8so17980236vsq.0 for ; Tue, 31 Jan 2023 16:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ASwz0KCzJl1Xvmaj+Jv8TyvvwiZ5/08hZ8GhY9F5WQU=; b=YI3Mcad4pll/O67Q1ugeKIY/bIi2AV7OsmOqTJYh12wzqjBoWUKFSgMDMmFf0uBTL6 52oY2Zszy5bmfm8zSsi4fM6puyqZVFwC67i+TdBG0JKSk+A6gKv2izuz+GUu3Z0NTmfh jyegV+NLhD2RM642WvaDCo+teJiobgPzN3uBPRtPqzE6Wk9TxVs7/eY2to0CO6x82oZy /jXiCgU2+E+heQ+kzci7b31GYLqUh6WtvPmFd7p5qFYmYAX5TdOpKJbh1hMCL7GaoMps b/OsXGXLTQ141F+DVdgvRxcFhXi1vZC9QK3EF8hNyQgqi2eP+n/iHim15qulOzypYVFK TZjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ASwz0KCzJl1Xvmaj+Jv8TyvvwiZ5/08hZ8GhY9F5WQU=; b=HrqLPFrR9Z26kMKvhjVbIbr7bI+sf6V7nOH8ODhVQ92cFzdFtJbXEt8om4TGvKtyW6 MC1cOjYt0f00E89Tv3sJHb+S1KAW2HA1O1OBG2vKOe6Jxijm+H7uiFcei4u5Y94MmsX1 eGDlMl/trkAwR/QcESoP4600lmMgAD+KokuJmJ2dX3phlv6/T798JyOc5Dt/CjJqzj0U o/bbgqGGBZJWqdTyokDXO84ivy1vuKVw4vOZclaJSXOIzCcHuridAxJMfQ/IkaD3jbWE r0Qmt1dcsg9XHiw679am3MOg19Ek8IGZYSE9rJvORnVh9MvPjnw9owkX/vhfpWmrYU+N ghYQ== X-Gm-Message-State: AO0yUKU9ztDEOLMd8Rkh2Shbha7uU24yZlrXNaWUFaqEJYtaYCoBx4Wd tB22NVqVOVY12Hm/OyVIToBwbLDmtzY+KCCSv35lNg== X-Google-Smtp-Source: AK7set/zekbE8fCAXcTUXjjAORIbLdVkwNZiYFMO3idA1STRJKT1ZKUZb+TrIXHOExO6aYznerE2nntNckAtb1QkXeQ= X-Received: by 2002:a05:6102:5596:b0:3eb:8473:a258 with SMTP id dc22-20020a056102559600b003eb8473a258mr158135vsb.14.1675211273507; Tue, 31 Jan 2023 16:27:53 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> In-Reply-To: From: Mark Saad Date: Tue, 31 Jan 2023 19:27:42 -0500 Message-ID: Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? To: Paul Mather Cc: David <2yt@gmx.com>, freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e1ae7205f39884bb" X-Rspamd-Queue-Id: 4P62nR3H0Vz45NL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e1ae7205f39884bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2023 at 5:03 PM Paul Mather wrote= : > On Jan 31, 2023, at 10:39 AM, David <2yt@gmx.com> wrote: > > > On 1/30/23 16:30, Matt Garber wrote: > >> > Any help/insight is gratefully appreciated. > >> > > >> > Cheers, > >> > > >> > Paul. > >> > > >> sysctl net.inet.tcp.cc.algorithm=3Dhtcp > >> I would set "htcp" on the server and home computer to improve > >> through in > >> your type of situation. > >> There may be other FreeBSD sysctls that have bad defaults in this > scenario and could be better tuned, but I doubt changing the CC algorithm > at this point is the problem =E2=80=94 at least not so much a problem tha= t=E2=80=99s > causing throughput to be reduced so drastically. Happy to be wrong if tha= t > does help things quickly and easily, though. > >> (Since OP mentioned that FreeBSD CC was set to CUBIC, that would match > what the Linux boxes are using by default, too, unless they=E2=80=99ve be= en changed > to something newer like BBR=E2=80=A6 so seems like CUBIC *should* be perf= orming > fine on this WAN link, and the difference is something else.) > >> =E2=80=94Matt > > > > I love FreeBSD and very much appreciate the efforts of those people muc= h > smarter. But... I don't think the defaults get enough testing in real wor= ld > conditions. > > > > I came across Paul's issue several years ago and spent a few a hours > testing and found the defaults performed very well on a LAN but could > perform terribly on a many hop WAN. HTCP performs marginally worse on a L= AN > or close WAN connection, but much much better on a many hop WAN connectio= n. > > > [[...]] > > > In my opinion HTCP is a better default for the current state of the > internet. > > > It looks like they already changed the default from NewReno to CUBIC in > FreeBSD-CURRENT. > > I agree with your observation about the defaults vs. real world > conditions. As you observed, I also get great performance in a high-spee= d > LAN, but not so much in a many-hop WAN to an asymmetric ISP connection. > > I actually started down this rabbit hole when I noticed I couldn't manage > more than about 3--4 MB in a single stream and thought my ISP was > throttling me. But then I noticed I would actually get fast/maximum > speeds, e.g., when doing "brew upgrade -v" and Homebrew would be > downloading packages, and so then wondered whether they were throttling > non-HTTP traffic. That led me to discover that even HTTP downloads were > slow to the FreeBSD servers I use remotely at $JOB and, furthermore, that > all traffic to Linux systems I use at $JOB didn't seem to be throttled or > incapable of getting maximum single stream bandwidth matching my ISP's > quoted speeds. :-\ > > I accept that this may just be a peculiarity of my local and remote setup= , > and so appreciate the help and suggestions people have offered in trying = to > debug the issue. > > Cheers, > > Paul. > Paul I was reading this and I wanted to just add two bits, one congestion control only really affects tcp sockets, so if you are using a freebsd router, setting the cc algo here does not do all that much. Second thing, the "ergonomics" of the tcp tunings on FreeBSD vs Redhat are very different. . IMHO try aligning the two boxes tcp tunings and also make sure the network cards used in each server are also aligned. IE do you have LRO enabled on one server and not the other. Is one server using an Intel 10G nic vs a Chelsio 10G nic ? --=20 mark saad | nonesuch@longcount.org --000000000000e1ae7205f39884bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 31, 2023 at 5:03 PM Paul = Mather <paul@gromit.dlib.vt.e= du> wrote:
2yt@gmx.com> wrote:

> On 1/30/23 16:30, Matt Garber wrote:
>>=C2=A0 =C2=A0 =C2=A0> Any help/insight is gratefully appreciated= .
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> Cheers,
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> Paul.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 sysctl net.inet.tcp.cc.algorithm=3Dhtcp
>>=C2=A0 =C2=A0 I would set "htcp" on the server and home c= omputer to improve
>>=C2=A0 =C2=A0 through in
>>=C2=A0 =C2=A0 your type of situation.
>> There may be other FreeBSD sysctls that have bad defaults in this = scenario and could be better tuned, but I doubt changing the CC algorithm a= t this point is the problem =E2=80=94 at least not so much a problem that= =E2=80=99s causing throughput to be reduced so drastically. Happy to be wro= ng if that does help things quickly and easily, though.
>> (Since OP mentioned that FreeBSD CC was set to CUBIC, that would m= atch what the Linux boxes are using by default, too, unless they=E2=80=99ve= been changed to something newer like BBR=E2=80=A6 so seems like CUBIC *sho= uld* be performing fine on this WAN link, and the difference is something e= lse.)
>> =E2=80=94Matt
>
> I love FreeBSD and very much appreciate the efforts of those people mu= ch smarter. But... I don't think the defaults get enough testing in rea= l world conditions.
>
> I came across Paul's issue several years ago and spent a few a hou= rs testing and found the defaults performed very well on a LAN but could pe= rform terribly on a many hop WAN. HTCP performs marginally worse on a LAN o= r close WAN connection, but much much better on a many hop WAN connection.<= br> >
[[...]]

> In my opinion HTCP is a better default for the current state of the in= ternet.


It looks like they already changed the default from NewReno to CUBIC in Fre= eBSD-CURRENT.

I agree with your observation about the defaults vs. real world conditions.= =C2=A0 As you observed, I also get great performance in a high-speed LAN, b= ut not so much in a many-hop WAN to an asymmetric ISP connection.

I actually started down this rabbit hole when I noticed I couldn't mana= ge more than about 3--4 MB in a single stream and thought my ISP was thrott= ling me.=C2=A0 But then I noticed I would actually get fast/maximum speeds,= e.g., when doing "brew upgrade -v" and Homebrew would be downloa= ding packages, and so then wondered whether they were throttling non-HTTP t= raffic.=C2=A0 That led me to discover that even HTTP downloads were slow to= the FreeBSD servers I use remotely at $JOB and, furthermore, that all traf= fic to Linux systems I use at $JOB didn't seem to be throttled or incap= able of getting maximum single stream bandwidth matching my ISP's quote= d speeds. :-\

I accept that this may just be a peculiarity of my local and remote setup, = and so appreciate the help and suggestions people have offered in trying to= debug the issue.

Cheers,

Paul.
Paul
=C2=A0 I was reading this and I want= ed to just add two bits, one congestion control only really affects tcp soc= kets, so if you are using a freebsd router, setting the cc algo here does n= ot do all that much. Second thing, the "ergonomics" of the tcp tu= nings on FreeBSD vs Redhat are very different.=C2=A0 .=C2=A0 IMHO try align= ing the two boxes tcp tunings and also make sure the network cards used in = each server are also aligned. IE do you have LRO enabled on one server and = not the other. Is one=C2=A0 server using an Intel 10G nic vs a Chelsio 10G = nic ?

--
= mark saad | non= esuch@longcount.org
--000000000000e1ae7205f39884bb-- From nobody Wed Feb 1 02:46:10 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P65s35SRDz3bp1H for ; Wed, 1 Feb 2023 02:46:15 +0000 (UTC) (envelope-from 2yt@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P65s25LM9z4Js5 for ; Wed, 1 Feb 2023 02:46:14 +0000 (UTC) (envelope-from 2yt@gmx.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 2yt@gmx.com designates 212.227.15.18 as permitted sender) smtp.mailfrom=2yt@gmx.com; dmarc=pass (policy=none) header.from=gmx.com Received: from [192.168.160.51] ([47.5.85.140]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1N7iCW-1ob0mE3Rhq-014iEY for ; Wed, 01 Feb 2023 03:46:13 +0100 Message-ID: Date: Tue, 31 Jan 2023 19:46:10 -0700 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Content-Language: en-US References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> To: freebsd-stable@freebsd.org From: David <2yt@gmx.com> In-Reply-To: <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:I+4C0vuoqifr2V19oLjaiB0XRApbc/R6rpRIQIFRqyxsNplRrWD K9y4YvujnfwMJi3gr1yXroZAK7VhbUYnsvGL9yC9tW0P1IJaTWRal6O0O4Ql7Nel2RnLY0a 5BZqmTILj3Kjya2wZzmFfc16xrdx2z6ufSf/kOjHA12AaOK05YaoZZ0ScuoKjkxXBNKLA9G /UTWDTfxeSnd0vuzYS0sA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:GH1TzAdr2ko=;YdEzjNV6dfVvg8jSSKTvsFXKelH 4jqKIfyqGMLnrQaFKFGrE3FZuoelSmrd+Iiqx02WR7/p8I+M4PSwhcq2j/NICVgfNskyfo12V ziDRRYN2Sj9X8fuujtIvogM+t7xHzeOgYloF3Bds9ylDUBkKZNFyr4hF2L/M7H7uB1veGIxR4 nyQgXvNvqqw3Ah+kCoVx5B2ke2zeGl7xktzTVT75u/pUCGtiqmH40XpEKP23MGMGobfbAAmn2 HdAZL5kTuR8FiSuw9f+gon903YdmXX9NmQkprFlcOzDqCrPG/9o33KfHRIhB0ysGps5ni/KF8 wU+Nf9kgkDJ4NlgivurEWngsG0v+obXahH5YGU0VknKF09YqhgDyanpVTqOtCiUWJBBdTPBhk U15shJzkavbyWHH04i7957E80i7ea117eYDdjMAz2OuX4qRmhx5I4JPEmhRpkMK7DSvkBkVzO tcMahS7Ej+97/f0Jl4u9/bsNHCv5M8bwJOEdFlYlPTnVb8wVSoJfS/660vZwjidPmc4wjmgcs ya3BjThxSOVQvdqwa5sB3BEAkGoFDP5xwyAtb05CEPP/7+wpkeKAXpPYAuDl8E25COtw8Ibxj q1HmuAvaUDbCALkdKZOWJK9IR+PdNcuh4Kz5PYesLHS9R8PT72oYNK6fHhmYmpbJd3nRuM8su NVgsu8pbBBWO1weCDNvzUDqxsIAPWDBIut6rpNyp4+/ML4lRfU47kRCUyMKhtX7BTA7cuRjeZ ENmoxAmvUCOxiM/J0hH+SnLgMCKlB2RtUHSFjTDtzrneeDF4UiWxhxavv3bkmOO1lu3tdtaZQ DmGK6Bfe1M6OZwqdFy4iYv+6FnovP5VmbiDVRVqC/SWRd+0YPCqHOqt+pwGU1JmdBCa4Qq5Wr TLBwsHd2fy3ayubqnhesglCDaDRBPQSjcYmB9x+okTK1p4BphGBLO8LRB+ECgqiMBAXojvs1B v6nTrO7Yv68Iobaz/VWOVPMWEWc= X-Spamd-Result: default: False [-0.73 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.93)[0.932]; NEURAL_HAM_SHORT(-0.76)[-0.761]; DMARC_POLICY_ALLOW(-0.50)[gmx.com,none]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/24:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18:from]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmx.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P65s25LM9z4Js5 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On 1/31/23 13:38, Marek Zarychta wrote: > W dniu 31.01.2023 o 19:31, Paul Mather pisze: >>> While playing with different mod_cc(4) might bring some improvement, >>> to get a real boost I'd suggest enabling tcp_rack(4) if feasible. >> >> I am interested in trying this out, but believe it is more feasible in >> my case for the -STABLE and -CURRENT systems I am using, not so much >> for the -RELEASE systems that are kept up to date via binary >> freebsd-update updates.  My reading of the tcp_rack(4) man page is >> that you have to build a custom kernel as, unlike the cc_* congestion >> control algorithms, the loadable tcp_rack module is not built by >> default.  Is that an accurate reading? >> > Yes, this gift from Netflix is probably better suited for -STABLE and > -CURRENT as easier to set up there. There is an excellent, up-to-date > article about it by Klara Systems writers[1]. From my experience > tcp_rack(4) is well suited for congested, lossy or redundant network > paths where loses, duplicated packets or races between packets occur. > Not a panacea, but very performant TCP stack based on the _fair_ > algorithm. In some instances, it might help you to saturate the > bandwidth of the link. TCP algo can be loaded/unloaded/changed on the > fly. In FreeBSD 14-CURRENT you can change it on an active socket with > tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app > bound to the socket. > Please feel free to play with TCP stacks and congestion algos with the > help of benchmarks/iperf3 to find out what prevents the link from being > saturated and give us some feedback here. > > [1] https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ > > Cheers > I compiled a custom kernel (releng/13.1) and followed Klara Systems instructions. The results are quite good. I would hope the RACK stack will be included in the upcoming 13.2 release as it is a significant upgrade. Testing: ------------------------------------ All computers are running FreeBSD 13.1. File transfer done with SCP. Route to HOST has 17 hops and 110ms pings. Connection limited to 100mb. Congestion tonight was highly variable, so the data below is very rough. All CC algorithms did better under RACK TCP Stack freebsd (default) ====================================== htcp 100% 315MB 3.7MB/s 01:24 htcp 100% 315MB 3.1MB/s 01:41 htcp 100% 315MB 2.6MB/s 02:03 newreno 100% 315MB 4.8MB/s 01:05 newreno 100% 315MB 1.4MB/s 03:48 newreno 100% 315MB 1.7MB/s 03:01 cubic 100% 315MB 8.3MB/s 00:37 cubic 100% 315MB 1.1MB/s 04:49 cubic 100% 315MB 1.9MB/s 02:44 TCP Stack RACK ====================================== htcp 100% 315MB 3.9MB/s 01:19 htcp 100% 315MB 8.6MB/s 00:36 htcp 100% 315MB 10.6MB/s 00:29 newreno 100% 315MB 10.5MB/s 00:30 newreno 100% 315MB 9.1MB/s 00:34 newreno 100% 315MB 7.6MB/s 00:41 cubic 100% 315MB 4.1MB/s 01:16 cubic 100% 315MB 8.6MB/s 00:36 cubic 100% 315MB 7.3MB/s 00:42 -- David From nobody Wed Feb 1 12:18:49 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6LYs74DHz3c4Z4 for ; Wed, 1 Feb 2023 12:18:57 +0000 (UTC) (envelope-from pete@twisted.org.uk) Received: from toybox.twisted.org.uk (toybox.twisted.org.uk [178.250.76.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6LYs4mwDz449s for ; Wed, 1 Feb 2023 12:18:57 +0000 (UTC) (envelope-from pete@twisted.org.uk) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=twisted.org.uk; s=x; h=Date:From:Message-Id:In-Reply-To:Cc:Subject:To: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:References:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MTRwxkajeE70GZdwAcjSH1cOlBxS+tum5sTU6sKk6zw=; b=aHYr3Mo4+FgvPYwOat2udiGvJ6 FY2aSCYUDi7dwrQWjWGq/iWhagbFCnkMlvRTzfh79sbP2S1dtwiM3w19IblTYGvBY1ftjc2Pr2MX6 pE79r+OJUK2XOY5FsDHTHlG6zHGJLiRy1jTblC1ep8J/lrVB61iOorcBFIUpGJwqmwnU=; Received: from mailnull by toybox.twisted.org.uk with spamc-scanned (Exim 4.95 (FreeBSD)) (envelope-from ) id 1pNC4g-000JJu-LT for freebsd-stable@freebsd.org; Wed, 01 Feb 2023 12:18:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on toybox.twisted.org.uk X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Score: -0.0 () Received: from pete by toybox.twisted.org.uk with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1pNC4f-000JJi-MH; Wed, 01 Feb 2023 12:18:49 +0000 To: 2yt@gmx.com, paul@gromit.dlib.vt.edu Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Cc: freebsd-stable@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Wed, 01 Feb 2023 12:18:49 +0000 X-spamc-toybox: true X-transport-toybox: lookuphost X-Rspamd-Queue-Id: 4P6LYs4mwDz449s X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12290, ipnet:178.250.72.0/21, country:GB] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org > > In my opinion HTCP is a better default for the current state of the internet. > > > It looks like they already changed the default from NewReno to CUBIC in FreeBSD-CURRENT. This worries me, because I did some experimentatiion yesterday, changing these settings and trying things out, Not for sending, but for recieving. i.e. I switch the algorithm on the server, and then send a lot of data to it. I have a MacBook, on home lan+wifi, and a small server running FreeBSD 13. I backup the laptop by rsyncing to the server and I can run that manually, so its a nice test of how fast I can push data to the server. I switched the server to cubic - and my rsync fails. Not always at the same point, but predictably after a number of minutes it always fails with the connection being dropped. Doesnt happen with newreno, and always happens with cubic. Which surprised me. So, I switched cubic back to newreno - but if this is going to be the default in CURRENT then probably we need to gte to the bottom of it somehow. I just am not sure how to start... -pete. From nobody Wed Feb 1 16:26:24 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6S3f0LB9z3cd2d for ; Wed, 1 Feb 2023 16:26:38 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6S3d5ZB2z3D7l for ; Wed, 1 Feb 2023 16:26:37 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id F1C9C550EA; Wed, 1 Feb 2023 11:26:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> Date: Wed, 1 Feb 2023 11:26:24 -0500 Cc: stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> To: Marek Zarychta X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P6S3d5ZB2z3D7l X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 31, 2023, at 3:38 PM, Marek Zarychta = wrote: > W dniu 31.01.2023 o 19:31, Paul Mather pisze: >>> While playing with different mod_cc(4) might bring some improvement, = to get a real boost I'd suggest enabling tcp_rack(4) if feasible. >>=20 >> I am interested in trying this out, but believe it is more feasible = in my case for the -STABLE and -CURRENT systems I am using, not so much = for the -RELEASE systems that are kept up to date via binary = freebsd-update updates. My reading of the tcp_rack(4) man page is that = you have to build a custom kernel as, unlike the cc_* congestion control = algorithms, the loadable tcp_rack module is not built by default. Is = that an accurate reading? >>=20 > Yes, this gift from Netflix is probably better suited for -STABLE and = -CURRENT as easier to set up there. There is an excellent, up-to-date = article about it by Klara Systems writers[1]. =46rom my experience = tcp_rack(4) is well suited for congested, lossy or redundant network = paths where loses, duplicated packets or races between packets occur. = Not a panacea, but very performant TCP stack based on the _fair_ = algorithm. In some instances, it might help you to saturate the = bandwidth of the link. TCP algo can be loaded/unloaded/changed on the = fly. In FreeBSD 14-CURRENT you can change it on an active socket with = tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app = bound to the socket. > Please feel free to play with TCP stacks and congestion algos with the = help of benchmarks/iperf3 to find out what prevents the link from being = saturated and give us some feedback here. >=20 > [1] = https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ Thank you, Marek, for the link to the Klara article about building and = using RACK. I'm building it now on a FreeBSD-CURRENT system and will = test it out. Cheers, Paul. From nobody Wed Feb 1 19:33:32 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6XCd6zp0z3bqKw for ; Wed, 1 Feb 2023 19:33:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6XCd0K9xz3rxP for ; Wed, 1 Feb 2023 19:33:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 2001:468:c80:a103:2:5000:5555:5555) smtp.mailfrom=paul@gromit.dlib.vt.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D33B031F7B; Wed, 1 Feb 2023 14:33:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> Date: Wed, 1 Feb 2023 14:33:32 -0500 Cc: stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> To: Marek Zarychta X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-1.46 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.96)[-0.964]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[paul]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P6XCd0K9xz3rxP X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Feb 1, 2023, at 11:26 AM, Paul Mather = wrote: > On Jan 31, 2023, at 3:38 PM, Marek Zarychta = wrote: >=20 >> W dniu 31.01.2023 o 19:31, Paul Mather pisze: >>>> While playing with different mod_cc(4) might bring some = improvement, to get a real boost I'd suggest enabling tcp_rack(4) if = feasible. >>>=20 >>> I am interested in trying this out, but believe it is more feasible = in my case for the -STABLE and -CURRENT systems I am using, not so much = for the -RELEASE systems that are kept up to date via binary = freebsd-update updates. My reading of the tcp_rack(4) man page is that = you have to build a custom kernel as, unlike the cc_* congestion control = algorithms, the loadable tcp_rack module is not built by default. Is = that an accurate reading? >>>=20 >> Yes, this gift from Netflix is probably better suited for -STABLE and = -CURRENT as easier to set up there. There is an excellent, up-to-date = article about it by Klara Systems writers[1]. =46rom my experience = tcp_rack(4) is well suited for congested, lossy or redundant network = paths where loses, duplicated packets or races between packets occur. = Not a panacea, but very performant TCP stack based on the _fair_ = algorithm. In some instances, it might help you to saturate the = bandwidth of the link. TCP algo can be loaded/unloaded/changed on the = fly. In FreeBSD 14-CURRENT you can change it on an active socket with = tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app = bound to the socket. >> Please feel free to play with TCP stacks and congestion algos with = the help of benchmarks/iperf3 to find out what prevents the link from = being saturated and give us some feedback here. >>=20 >> [1] = https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ >=20 >=20 > Thank you, Marek, for the link to the Klara article about building and = using RACK. I'm building it now on a FreeBSD-CURRENT system and will = test it out. It looks like we may have a winner, folks. I built and enabled the = extra TCP stacks and for the first time was able to max out my = connection to the remote FreeBSD system. I get consistently higher = throughput over the 15-hop WAN path to the remote FreeBSD system when = using the RACK TCP stack than when using the default "freebsd" stack. Although the speeds are consistently higher when using the setting = "net.inet.tcp.functions_default=3Drack", they are still variable. = However, rather than the 3--4 MB/s I saw that kicked off this thread, I = now average over 10 MB/s. I actually get the best results with = "net.inet.tcp.functions_default=3Dbbr" (having loaded tcp_bbr). That = behaves very much like the Linux hosts in that speeds climb very quickly = until it saturates the WAN connection. I get the same high speeds from = the remote FreeBSD system using tcp_bbr as I do to the Linux hosts. I = will stick with tcp_bbr for now as the default on my remote FreeBSD = servers. It appears to put them on a par with Linux for this WAN link. Cheers, Paul. From nobody Wed Feb 1 20:14:27 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6Y6p5DRQz3bvbl for ; Wed, 1 Feb 2023 20:14:42 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6Y6p1gbTz3wrL for ; Wed, 1 Feb 2023 20:14:42 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 311KESnA067087 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 1 Feb 2023 21:14:29 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1675282470; bh=T6ElMDJIX2AcyeUT+ZNsN0eq6/FAJnw1yO0Fo2cJg98=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=gMf01PqMOu9hvyn8JZH1RQOXKRq8tRv9Fo3VmBmb1wpeOOd29/uKgD2XdPAu6Xz/E h8cv8v2UbJnyaLw+upFuUSmetfAkxw8/WGq7FW5Fp75curl3tqGV8jaIPP2wP1PWdS UnalBNJQxHTms+pF7XdkzOeT803GmaC+JsUALKPRJh/sIiQOfjp6Z9rWMn7VuHBQDf u/53WVrIiwlgMRwfSyKcaUtf6kvE+CO/r9T5et4XUHiLqNJOHO/aCM4tACKZIIeOfX zWVupBzZFf1G3TukGLp2Gm8LO+etj9XT/T2hPYyliQqjd2spr2sDJfELCILyyVCXR4 pigVTY3LvOYTA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: Date: Wed, 1 Feb 2023 21:14:27 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: pl, en-US To: Paul Mather Cc: stable@freebsd.org References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> From: Marek Zarychta Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? In-Reply-To: <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------oOJZwKLrW0ToGWFwxvjkqwIY" X-Rspamd-Queue-Id: 4P6Y6p1gbTz3wrL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oOJZwKLrW0ToGWFwxvjkqwIY Content-Type: multipart/mixed; boundary="------------npqkMrGMtkisS9hPTh2XgOFc"; protected-headers="v1" From: Marek Zarychta To: Paul Mather Cc: stable@freebsd.org Message-ID: Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> In-Reply-To: <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> --------------npqkMrGMtkisS9hPTh2XgOFc Content-Type: multipart/alternative; boundary="------------1juhIJZ2T2YNrkGgKNMy09EZ" --------------1juhIJZ2T2YNrkGgKNMy09EZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDEuMDIuMjAyMyBvwqAyMDozMywgUGF1bCBNYXRoZXIgcGlzemU6DQo+IEl0IGxv b2tzIGxpa2Ugd2UgbWF5IGhhdmUgYSB3aW5uZXIsIGZvbGtzLiAgSSBidWlsdCBhbmQgZW5h YmxlZCB0aGUgZXh0cmEgVENQIHN0YWNrcyBhbmQgZm9yIHRoZSBmaXJzdCB0aW1lIHdhcyBh YmxlIHRvIG1heCBvdXQgbXkgY29ubmVjdGlvbiB0byB0aGUgcmVtb3RlIEZyZWVCU0Qgc3lz dGVtLiAgSSBnZXQgY29uc2lzdGVudGx5IGhpZ2hlciB0aHJvdWdocHV0IG92ZXIgdGhlIDE1 LWhvcCBXQU4gcGF0aCB0byB0aGUgcmVtb3RlIEZyZWVCU0Qgc3lzdGVtIHdoZW4gdXNpbmcg dGhlIFJBQ0sgVENQIHN0YWNrIHRoYW4gd2hlbiB1c2luZyB0aGUgZGVmYXVsdCAiZnJlZWJz ZCIgc3RhY2suDQo+DQo+IEFsdGhvdWdoIHRoZSBzcGVlZHMgYXJlIGNvbnNpc3RlbnRseSBo aWdoZXIgd2hlbiB1c2luZyB0aGUgc2V0dGluZyAibmV0LmluZXQudGNwLmZ1bmN0aW9uc19k ZWZhdWx0PXJhY2siLCB0aGV5IGFyZSBzdGlsbCB2YXJpYWJsZS4gIEhvd2V2ZXIsIHJhdGhl ciB0aGFuIHRoZSAzLS00IE1CL3MgSSBzYXcgdGhhdCBraWNrZWQgb2ZmIHRoaXMgdGhyZWFk LCBJIG5vdyBhdmVyYWdlIG92ZXIgMTAgTUIvcy4NCj4NCj4gSSBhY3R1YWxseSBnZXQgdGhl IGJlc3QgcmVzdWx0cyB3aXRoICJuZXQuaW5ldC50Y3AuZnVuY3Rpb25zX2RlZmF1bHQ9YmJy IiAoaGF2aW5nIGxvYWRlZCB0Y3BfYmJyKS4gIFRoYXQgYmVoYXZlcyB2ZXJ5IG11Y2ggbGlr ZSB0aGUgTGludXggaG9zdHMgaW4gdGhhdCBzcGVlZHMgY2xpbWIgdmVyeSBxdWlja2x5IHVu dGlsIGl0IHNhdHVyYXRlcyB0aGUgV0FOIGNvbm5lY3Rpb24uICBJIGdldCB0aGUgc2FtZSBo aWdoIHNwZWVkcyBmcm9tIHRoZSByZW1vdGUgRnJlZUJTRCBzeXN0ZW0gdXNpbmcgdGNwX2Ji ciBhcyBJIGRvIHRvIHRoZSBMaW51eCBob3N0cy4gIEkgd2lsbCBzdGljayB3aXRoIHRjcF9i YnIgZm9yIG5vdyBhcyB0aGUgZGVmYXVsdCBvbiBteSByZW1vdGUgRnJlZUJTRCBzZXJ2ZXJz LiAgSXQgYXBwZWFycyB0byBwdXQgdGhlbSBvbiBhIHBhciB3aXRoIExpbnV4IGZvciB0aGlz IFdBTiBsaW5rLg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayBQYXVsLiBQbGVhc2UgYmVh ciBpbiBtaW5kIHRoYXQgQkJSIDEgd2hpY2ggaXMgDQppbXBsZW1lbnRlZCBpbiBGcmVlQlNE IGlzIG5vdCBhIGZhaXJbMV0gY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobS4gDQpNYXli ZSBpbiB0aGUgZnV0dXJlLCB3ZSB3aWxsIGhhdmUgQkJSIHYyIGluIHRoZSBzdGFjaywgYnV0 IGZvciBub3csIEkgDQpkb24ndCByZWNvbW1lbmQgdXNpbmcgQkJSLCB1bmxlc3MgeW91IHdh bnQgdG8gYWN0IHNsaWdodGx5IGFzIGEgaG0uLi4uIA0KbmV0d29yayBsZWVjaGVyLiBNYXli ZSBMaW51eCBob3N0cyBiZWhhdmUgdGhpcyB3YXksIG1heWJlIHRoZXkgaGF2ZSANCmltcGxl bWVudGVkIEJCUiB2MiwgSSBhbSBub3QgZmFtaWxpYXIgd2l0aCBMaW51eCBUQ1Agc3RhY2sg ZW5oYW5jZW1lbnRzLiANCk9uIHRoZSBvdGhlciBoYW5kLCB0Y3BfcmFjayg0KSBpcyBwZXJm b3JtYW50LCB3ZWxsLXRlc3RlZCBpbiB0aGUgRnJlZUJTRCANCnN0YWNrLCBjb25zaWRlcmVk IGZhaXIgYW5kIG1vcmUgYWNjZXB0YWJsZSBmb3IgYSBmaWxlc2VydmVyLCB0aG91Z2ggbm90 IA0KaWRlYWwsIGllLiBwcm9iYWJseSBtb3JlIGNvbXB1dGF0aW9uYWxseSBleHBlbnNpdmUg YW5kIHN0aWxsIG1pc3NpbmcgDQpzb21lIGZlYXR1cmVzIGxpa2UgVENQLU1ENS4NCg0KWzFd IGh0dHBzOi8vd3d3Lm1kcGkuY29tLzE0MjQtODIyMC8yMS8xMi80MTI4DQoNCg0KQ2hlZXJz DQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg0K --------------1juhIJZ2T2YNrkGgKNMy09EZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W dniu 1.02.2023 o=C2=A020:33, Paul Ma= ther pisze: 
It looks like we may have a =
winner, folks.  I built and enabled the extra TCP stacks and for the firs=
t time was able to max out my connection to the remote FreeBSD system.  I=
 get consistently higher throughput over the 15-hop WAN path to the remot=
e FreeBSD system when using the RACK TCP stack than when using the defaul=
t "freebsd" stack.

Although the speeds are consistently higher when using the setting "net.i=
net.tcp.functions_default=3Drack", they are still variable.  However, rat=
her than the 3--4 MB/s I saw that kicked off this thread, I now average o=
ver 10 MB/s.

I actually get the best results with "net.inet.tcp.functions_default=3Dbb=
r" (having loaded tcp_bbr).  That behaves very much like the Linux hosts =
in that speeds climb very quickly until it saturates the WAN connection. =
 I get the same high speeds from the remote FreeBSD system using tcp_bbr =
as I do to the Linux hosts.  I will stick with tcp_bbr for now as the def=
ault on my remote FreeBSD servers.  It appears to put them on a par with =
Linux for this WAN link.

https://www.mdpi.com/1424-8220/21/12/4128


Cheers

--=20
Marek Zarychta
--------------1juhIJZ2T2YNrkGgKNMy09EZ-- --------------npqkMrGMtkisS9hPTh2XgOFc-- --------------oOJZwKLrW0ToGWFwxvjkqwIY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmPayCMFAwAAAAAACgkQHZW8vIFppoKk /wf/W7qkjE1lkJPFLmhobbvHb51raYKTMEC590cMQKQWAe5zLveiIQou1ABiWKM/9qzThaPByc45 axnTvl3ABqd/Lr6z0k4MZFLkhfZzPs/iUHYWOlPvjCv2L2HiZq8I/MHZib1LLTJasmrk/MIbjKgs 2R+An9qvyXv9RcdvV/ZMVHkHCKyFdmGkZ30eFx4TayCfibLbfF9Py92VrgotC43PiNNRfvP0VxjX wk/sJuszfr5ND4KaRGMZJP4FKWqQuFUoNV4Vd9sl3Td4rQGyB2YOVugmzfbgO9TQZta6m1CLCecT gTg482tb+TOcEEqyyQtQQnSJe1GvQ4WK9F8tHLzJcA== =OCFE -----END PGP SIGNATURE----- --------------oOJZwKLrW0ToGWFwxvjkqwIY-- From nobody Wed Feb 1 20:29:37 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6YSF1Ztkz3bws1 for ; Wed, 1 Feb 2023 20:29:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6YSF0zzSz40Pv for ; Wed, 1 Feb 2023 20:29:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 2BB0D206EC; Wed, 1 Feb 2023 15:29:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: Date: Wed, 1 Feb 2023 15:29:37 -0500 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <31816EF8-7516-45F9-8584-A649F0011E3D@gromit.dlib.vt.edu> References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> To: David <2yt@gmx.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P6YSF0zzSz40Pv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 31, 2023, at 9:46 PM, David <2yt@gmx.com> wrote: > On 1/31/23 13:38, Marek Zarychta wrote: >> W dniu 31.01.2023 o 19:31, Paul Mather pisze: >>>> While playing with different mod_cc(4) might bring some = improvement, to get a real boost I'd suggest enabling tcp_rack(4) if = feasible. >>>=20 >>> I am interested in trying this out, but believe it is more feasible = in my case for the -STABLE and -CURRENT systems I am using, not so much = for the -RELEASE systems that are kept up to date via binary = freebsd-update updates. My reading of the tcp_rack(4) man page is that = you have to build a custom kernel as, unlike the cc_* congestion control = algorithms, the loadable tcp_rack module is not built by default. Is = that an accurate reading? >>>=20 >> Yes, this gift from Netflix is probably better suited for -STABLE and = -CURRENT as easier to set up there. There is an excellent, up-to-date = article about it by Klara Systems writers[1]. =46rom my experience = tcp_rack(4) is well suited for congested, lossy or redundant network = paths where loses, duplicated packets or races between packets occur. = Not a panacea, but very performant TCP stack based on the _fair_ = algorithm. In some instances, it might help you to saturate the = bandwidth of the link. TCP algo can be loaded/unloaded/changed on the = fly. In FreeBSD 14-CURRENT you can change it on an active socket with = tcpsso(8) utility, in FreeBSD 12 and 13 you have to restart the app = bound to the socket. >> Please feel free to play with TCP stacks and congestion algos with = the help of benchmarks/iperf3 to find out what prevents the link from = being saturated and give us some feedback here. >> [1] = https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/ >> Cheers >=20 > I compiled a custom kernel (releng/13.1) and followed Klara Systems = instructions. The results are quite good. I would hope the RACK stack = will be included in the upcoming 13.2 release as it is a significant = upgrade. I heartily concur with this. It would be very nice if the extra TCP = stacks were available and able to be loaded in the upcoming 13.2 = release. As I mentioned recently in this thread, I built and enabled the extra = TCP stacks on a -CURRENT system and got much better performance than = with the default "freebsd" stack. I've just done the same on a = 13-STABLE system and get the same result. Using the tcp_bbr stack = appears to solve the problem I was having. It would be great if the TCPHPTS and RATELIMIT options could be added to = the GENERIC kernel and WITH_EXTRA_TCP_STACKS default to enabled for = building in src.conf. That way, the tcp_rack and tcp_bbr modules would = get built by default and people would have the option of loading them on = -RELEASE systems without having to build their own kernel when doing = updates via freebsd-update. Cheers, Paul. From nobody Wed Feb 1 21:07:15 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6ZHl1ckFz3c2QM for ; Wed, 1 Feb 2023 21:07:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6ZHl1B7sz43VV for ; Wed, 1 Feb 2023 21:07:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id F3F30205EE; Wed, 1 Feb 2023 16:07:25 -0500 (EST) From: Paul Mather Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_233E2C73-6AEB-4008-BE76-E608477332C2" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Date: Wed, 1 Feb 2023 16:07:15 -0500 In-Reply-To: Cc: stable@freebsd.org To: Marek Zarychta References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4P6ZHl1B7sz43VV X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_233E2C73-6AEB-4008-BE76-E608477332C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 1, 2023, at 3:14 PM, Marek Zarychta = wrote: > W dniu 1.02.2023 o 20:33, Paul Mather pisze: >> It looks like we may have a winner, folks. I built and enabled the = extra TCP stacks and for the first time was able to max out my = connection to the remote FreeBSD system. I get consistently higher = throughput over the 15-hop WAN path to the remote FreeBSD system when = using the RACK TCP stack than when using the default "freebsd" stack. >>=20 >> Although the speeds are consistently higher when using the setting = "net.inet.tcp.functions_default=3Drack", they are still variable. = However, rather than the 3--4 MB/s I saw that kicked off this thread, I = now average over 10 MB/s. >>=20 >> I actually get the best results with = "net.inet.tcp.functions_default=3Dbbr" (having loaded tcp_bbr). That = behaves very much like the Linux hosts in that speeds climb very quickly = until it saturates the WAN connection. I get the same high speeds from = the remote FreeBSD system using tcp_bbr as I do to the Linux hosts. I = will stick with tcp_bbr for now as the default on my remote FreeBSD = servers. It appears to put them on a par with Linux for this WAN link. > Thanks for the feedback Paul. Please bear in mind that BBR 1 which is = implemented in FreeBSD is not a fair[1] congestion control algorithm. = Maybe in the future, we will have BBR v2 in the stack, but for now, I = don't recommend using BBR, unless you want to act slightly as a hm.... = network leecher. Maybe Linux hosts behave this way, maybe they have = implemented BBR v2, I am not familiar with Linux TCP stack enhancements. > On the other hand, tcp_rack(4) is performant, well-tested in the = FreeBSD stack, considered fair and more acceptable for a fileserver, = though not ideal, ie. probably more computationally expensive and still = missing some features like TCP-MD5. >=20 >=20 > [1] https://www.mdpi.com/1424-8220/21/12/4128 >=20 That is a fair and astute observation, Marek. I am also not familiar = with Linux TCP stack implementations but it had occurred to me that = maybe Linux was not being an entirely good netizen whereas FreeBSD was = behaving with impeccable net manners when it came to congestion control = and being fair to others, and that is why Linux was getting faster = speeds for me. Then again, perhaps not. :-) In the case of the remote FreeBSD hosts I use at $JOB, they have low = numbers of users and so are more akin to endpoints than servers, so I'm = not worried about "leeching" from them. Also, my ISP download bandwidth = is 1/5th of each FreeBSD system, so hopefully there is still plenty to = go around after I max out my bulk downloads. (Plus, I believe $JOB = prefers my downloads to take half [or less] the time.) :-) Hopefully we will get BBR v2 (or something even fairer) at some point. = IIRC, the FreeBSD Foundation has been highlighting some of this network = stack work. It would be a pity for it not to be enabled by default so = more people could use it on -RELEASE without building a custom kernel. = I'm just glad right now I'm not stuck with 3--4 MB/s downloads any more. Cheers, Paul. --Apple-Mail=_233E2C73-6AEB-4008-BE76-E608477332C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 1, = 2023, at 3:14 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> = wrote:

W dniu 1.02.2023 = o 20:33, Paul Mather pisze:
It looks like we may have a =
winner, folks.  I built and enabled the extra TCP stacks and for the =
first time was able to max out my connection to the remote FreeBSD =
system.  I get consistently higher throughput over the 15-hop WAN path =
to the remote FreeBSD system when using the RACK TCP stack than when =
using the default "freebsd" stack.

Although the speeds are consistently higher when using the setting =
"net.inet.tcp.functions_default=3Drack", they are still variable.  =
However, rather than the 3--4 MB/s I saw that kicked off this thread, I =
now average over 10 MB/s.

I actually get the best results with =
"net.inet.tcp.functions_default=3Dbbr" (having loaded tcp_bbr).  That =
behaves very much like the Linux hosts in that speeds climb very quickly =
until it saturates the WAN connection.  I get the same high speeds from =
the remote FreeBSD system using tcp_bbr as I do to the Linux hosts.  I =
will stick with tcp_bbr for now as the default on my remote FreeBSD =
servers.  It appears to put them on a par with Linux for this WAN link.

Thanks for the feedback Paul. Please bear in mind = that BBR 1 which is implemented in FreeBSD is not a fair[1] congestion = control algorithm. Maybe in the future, we will have BBR v2 in the = stack, but for now, I don't recommend using BBR, unless you want to act = slightly as a hm.... network leecher. Maybe Linux hosts behave this way, = maybe they have implemented BBR v2, I am not familiar with Linux TCP = stack enhancements. On the other hand, tcp_rack(4) is performant, well-tested in the FreeBSD = stack, considered fair and more acceptable for a fileserver, though not = ideal, ie. probably more computationally expensive and still missing = some features like TCP-MD5.

[1] https://www.mdpi.com/14= 24-8220/21/12/4128


That = is a fair and astute observation, Marek.  I am also not familiar = with Linux TCP stack implementations but it had occurred to me that = maybe Linux was not being an entirely good netizen whereas FreeBSD was = behaving with impeccable net manners when it came to congestion control = and being fair to others, and that is why Linux was getting faster = speeds for me.  Then again, perhaps not. = :-)

In the case of the remote FreeBSD hosts I = use at $JOB, they have low numbers of users and so are more akin to = endpoints than servers, so I'm not worried about "leeching" from them. =  Also, my ISP download bandwidth is 1/5th of each FreeBSD system, = so hopefully there is still plenty to go around after I max out my bulk = downloads.  (Plus, I believe $JOB prefers my downloads to take half = [or less] the time.) :-)

Hopefully we will get = BBR v2 (or something even fairer) at some point.  IIRC, the FreeBSD = Foundation has been highlighting some of this network stack work. =  It would be a pity for it not to be enabled by default so more = people could use it on -RELEASE without building a custom kernel. =  I'm just glad right now I'm not stuck with 3--4 MB/s downloads any = more.

Cheers,

Paul.
= --Apple-Mail=_233E2C73-6AEB-4008-BE76-E608477332C2-- From nobody Wed Feb 1 22:54:09 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P6cft2wKmz3cGPC for ; Wed, 1 Feb 2023 22:54:14 +0000 (UTC) (envelope-from 2yt@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P6cfs3J2Cz3Bq2 for ; Wed, 1 Feb 2023 22:54:13 +0000 (UTC) (envelope-from 2yt@gmx.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 2yt@gmx.com designates 212.227.17.22 as permitted sender) smtp.mailfrom=2yt@gmx.com; dmarc=pass (policy=none) header.from=gmx.com Received: from [192.168.160.51] ([47.5.85.140]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N6KUT-1oYnZy0GiH-016i7q for ; Wed, 01 Feb 2023 23:54:11 +0100 Message-ID: Date: Wed, 1 Feb 2023 15:54:09 -0700 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? Content-Language: en-US References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> To: freebsd-stable@freebsd.org From: David <2yt@gmx.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:skPCEXNlj+3YVtCKwjzpFcprpRiUnfllUTxn1XJrOMoD5IzOUUf AGYtvlMoH9Ghvk+JrID8hQ8XLhEIGmeIlGyNDGkDZAO5iitlxbp0Nup3djfJ7a1OFkWSiId 2PiThiY7atgOafAkcua7s2xfQQDcWnFk36FjpEK9HqTvIdLad86awPGSvMIwYD1TXj1xjHM Vd/gqfJbNvtDNQvyRjjWw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:nUF/5NLIVVo=;P33NylyXltIHXYc/4URA1uTCgyl jCVJg2eCJBbnnGesKhmQiE9455f2GXad+R7PVv3yFbJpY+rnU92ufHbbTqh7BzIScagUiNjWS mgf7H+kxW+m8DXqCD41LTq18tKMZfQGF/MefJbOtNbcrNJ2Adx5mrfzxKSQ1rSNULtp53Y8Lj 3hZkJWV7/vccM0bMsSbES488GXS7FmYBQeG0GvM+T8kyQSkFkpBxWdKyGmezA+v6y+6e2YJjX w9w/i1B0Ne861JRPDbT/ei2qDqwqZ993Mh4XBZBXLWxwXJLwoM0WVJU3fZROqN1NXJdVpcnLS 1zdOThIJL/mn+FJBfYcA3isH6bpvT6QypM55kdRTbky7L1yUKi9vdwlfAnnDFjqzCCVFB8FgG 0PJnxiAmzyfuEtnfOJN1bw7wHKmKO+Svir1Ug5DtZ+1J40UU4huPEFp2MfSHqTE6oFgWmh9d7 gkGWbcx7W6be04smE9rFK5zwi/yCeOlq/6DC33iNJy7rp0ubN/ts/jmDn/ngBf+o9jycDkT3/ tVoCQv8v/c4LInSQEwWuKlBWZr4SXYkq2qDVzcmszK0iPismPmegpzsiwcB2+q/fmUOovT/Qf X8Fu3qkgz1ANlTQ0REjQujrimYaYVKzKtzQpu8noDjkeEK6DjI+C7lZJCMSDy5jKYZ7i9GAYi P936fM4RmB3Wb8KmfUQt9k51YrgQos40uqLkg8ocQ7jP0NRQtx2GvShvykt/2UxxZXY/saS2u VZJi6BAB/5okBWT9ulpeyj+JZ1ucJNMssBE9+5xcJhyzD26jh6hJkdYlMBuiHPVmDoENXSOV6 ZWDVVE0PPUAPaFk8xNXylN9sGEksEw2NSTzDWOYzJedxRPyCrOcALjumFZT4QWK3a+CDyC8qm gi0k6NmRL6XyWFj6v+bMkN3c1aVrQuhmncU0FgFWvCc6PThQ9TgJaEIV5qCKMV9Uf6/I6NvIY fQfx1w== X-Spamd-Result: default: False [-1.17 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; NEURAL_HAM_LONG(-0.99)[-0.986]; NEURAL_SPAM_SHORT(0.71)[0.707]; DMARC_POLICY_ALLOW(-0.50)[gmx.com,none]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmx.com]; FREEMAIL_ENVFROM(0.00)[gmx.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P6cfs3J2Cz3Bq2 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On 2/1/23 14:07, Paul Mather wrote: > On Feb 1, 2023, at 3:14 PM, Marek Zarychta > wrote: > >> W dniu 1.02.2023 o 20:33, Paul Mather pisze: >>> It looks like we may have a winner, folks. I built and enabled the extra TCP stacks and for the first time was able to max out my connection to the remote FreeBSD system. I get consistently higher throughput over the 15-hop WAN path to the remote FreeBSD system when using the RACK TCP stack than when using the default "freebsd" stack. >>> >>> Although the speeds are consistently higher when using the setting "net.inet.tcp.functions_default=rack", they are still variable. However, rather than the 3--4 MB/s I saw that kicked off this thread, I now average over 10 MB/s. >>> >>> I actually get the best results with "net.inet.tcp.functions_default=bbr" (having loaded tcp_bbr). That behaves very much like the Linux hosts in that speeds climb very quickly until it saturates the WAN connection. I get the same high speeds from the remote FreeBSD system using tcp_bbr as I do to the Linux hosts. I will stick with tcp_bbr for now as the default on my remote FreeBSD servers. It appears to put them on a par with Linux for this WAN link. >> >> Thanks for the feedback Paul. Please bear in mind that BBR 1 which is >> implemented in FreeBSD is not a fair[1] congestion control algorithm. >> Maybe in the future, we will have BBR v2 in the stack, but for now, I >> don't recommend using BBR, unless you want to act slightly as a hm.... >> network leecher. Maybe Linux hosts behave this way, maybe they have >> implemented BBR v2, I am not familiar with Linux TCP stack >> enhancements. On the other hand, tcp_rack(4) is performant, >> well-tested in the FreeBSD stack, considered fair and more acceptable >> for a fileserver, though not ideal, ie. probably more computationally >> expensive and still missing some features like TCP-MD5. >> >> [1] https://www.mdpi.com/1424-8220/21/12/4128 >> > > That is a fair and astute observation, Marek.  I am also not familiar > with Linux TCP stack implementations but it had occurred to me that > maybe Linux was not being an entirely good netizen whereas FreeBSD was > behaving with impeccable net manners when it came to congestion control > and being fair to others, and that is why Linux was getting faster > speeds for me.  Then again, perhaps not. :-) > > In the case of the remote FreeBSD hosts I use at $JOB, they have low > numbers of users and so are more akin to endpoints than servers, so I'm > not worried about "leeching" from them.  Also, my ISP download bandwidth > is 1/5th of each FreeBSD system, so hopefully there is still plenty to > go around after I max out my bulk downloads.  (Plus, I believe $JOB > prefers my downloads to take half [or less] the time.) :-) > > Hopefully we will get BBR v2 (or something even fairer) at some point. >  IIRC, the FreeBSD Foundation has been highlighting some of this > network stack work.  It would be a pity for it not to be enabled by > default so more people could use it on -RELEASE without building a > custom kernel.  I'm just glad right now I'm not stuck with 3--4 MB/s > downloads any more. > > Cheers, > > Paul. > Word of caution: It would appear not all FreeBSD applications like BBR or RACK. I run a Magento (e-commerce) VM and was getting weird pauses (hang for a bit then resume) on the website. Running Magneto requires several other TCP services and something wasn't happy. Not going to debug the problem, just wanted to give a heads up. -- David From nobody Fri Feb 3 10:06:42 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7WV95dwFz2nR92 for ; Fri, 3 Feb 2023 10:04:49 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7WV86b1lz3KGb for ; Fri, 3 Feb 2023 10:04:48 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=terraplane.org header.s=ds202212 header.b="O9+nt/FQ"; spf=pass (mx1.freebsd.org: domain of eivinde@terraplane.org designates 2a01:5b40:0:3006::1 as permitted sender) smtp.mailfrom=eivinde@terraplane.org; dmarc=pass (policy=none) header.from=terraplane.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2TNCKqo9QG65nmELbo/KNiCsQ2YOaP9YU8QtlDN97pw=; b=O9+nt/FQf+eThL4NGahmxng/XH zqM4kGpd+1lWTK1riMymMsftlyfVVUnAvl0jKF5BN8tK76ZnqaY9K/Qqwn+Ufv5AEXBFTML3e2l3P dYFbsUKH6D79PVSKYQYc697iiIAbDWo3ls0KwItoXxfS0Ag5y1OVOJ3sVe6cYxgJ1LMF0fOCMo+Eh lu8q+Bp0t0arQgdNzdEyUQ/PDqmzHTmGwsff2y5fuM4Ic3uVPaizOMm6OKlbcKojh9kH3wCaW5t7Q UJGeAOCP/7kE6bXl28xiUVKyE7dZPla/Yb+fLJjrHm1Ca+fN94ytHanGuxZkShawJdualyFxKvPrS 3W9dOMGQ==; Received: from ti0027q160-0136.bb.online.no ([37.200.21.137]:11894 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pNsvv-001EMk-Vr for freebsd-stable@freebsd.org; Fri, 03 Feb 2023 11:04:40 +0100 Date: Fri, 3 Feb 2023 11:06:42 +0100 From: Eivind Nicolay Evensen To: freebsd-stable@freebsd.org Subject: Grep with non-ascii Message-ID: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[terraplane.org,none]; R_SPF_ALLOW(-0.20)[+ip6:2a01:5b40:0:2000::/51]; R_DKIM_ALLOW(-0.20)[terraplane.org:s=ds202212]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[terraplane.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P7WV86b1lz3KGb X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello. I just noticed this today: elg!ene[~]> printf "b\nhei\nl\n" | grep grep: trailing backslash (\) elg!ene[~]> echo $LC_CTYPE $LANG nb_NO.ISO8859-1 nb_NO.ISO8859-1 While I have the result I envisioned with gnugrep: elg!ene[~]> printf "b\nhei\nl\n" | ggrep b l Also, on OpenIndiana, linux and Netbsd, grep gives the proper result. Is lib/libc/regex the right place to look into this if I find the time, or does anybody know this enough to know the problem? Regards -- Eivind Nicolay Evensen From nobody Fri Feb 3 11:39:48 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7Ybv0Jsfz2p1Kx for ; Fri, 3 Feb 2023 11:39:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7Ybs4NLlz3k61 for ; Fri, 3 Feb 2023 11:39:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 313Bdm7f015287 for ; Fri, 3 Feb 2023 20:39:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 3 Feb 2023 20:39:48 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: Grep with non-ascii Message-Id: <20230203203948.23d66303bcae8c528202071a@dec.sakura.ne.jp> In-Reply-To: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.58 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P7Ybs4NLlz3k61 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Feb 2023 11:06:42 +0100 Eivind Nicolay Evensen wrote: > Hello. > > I just noticed this today: > > elg!ene[~]> printf "bø\nhei\nøl\n" | grep ø > grep: trailing backslash (\) > elg!ene[~]> echo $LC_CTYPE $LANG > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > While I have the result I envisioned with gnugrep: > > elg!ene[~]> printf "bø\nhei\nøl\n" | ggrep ø > bø > øl > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper result. > > Is lib/libc/regex the right place to look into this if I > find the time, or does anybody know this enough to know the > problem? > > Regards > -- > Eivind Nicolay Evensen Possibly a locale problem, or depending on what command line shell you are using. Tried copy/pasting to command line, I got the result below. % printf "bø\nhei\nøl\n" | grep ø bø øl I'm using LC_ALL=ja_JP.UTF-8, LANG=ja_JP.UTF-8 as locale and shells/zsh as command line shell. What happenes if you switch locale to nb_NO.UTF-8? -- Tomoaki AOKI From eugen@grosbein.net Fri Feb 3 12:12:32 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7ZL56KdMz2p332 for ; Fri, 3 Feb 2023 12:13:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7ZL53Jg7z3p2g for ; Fri, 3 Feb 2023 12:13:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; none Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 313CCuOG007968 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Feb 2023 12:12:56 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: eivinde@terraplane.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 313CCtMO008750 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 3 Feb 2023 19:12:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Grep with non-ascii To: Eivind Nicolay Evensen , freebsd-stable@freebsd.org References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> From: Eugene Grosbein Message-ID: <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> Date: Fri, 3 Feb 2023 19:12:32 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4P7ZL53Jg7z3p2g X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > Hello. > > I just noticed this today: > > elg!ene[~]> printf "b\nhei\nl\n" | grep > grep: trailing backslash (\) > elg!ene[~]> echo $LC_CTYPE $LANG > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > While I have the result I envisioned with gnugrep: > > elg!ene[~]> printf "b\nhei\nl\n" | ggrep > b > l > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper result. > > Is lib/libc/regex the right place to look into this if I > find the time, or does anybody know this enough to know the > problem? Try single quotes instead of double quotes. And pleace specify system version and shell name, and shell version if its not in base system. From nobody Fri Feb 3 13:41:15 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7cHz6HQgz2p87x for ; Fri, 3 Feb 2023 13:41:19 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7cHz1Dx2z46XH for ; Fri, 3 Feb 2023 13:41:19 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=y1Fiiu6y; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="o C6isto"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7B5545C00E4 for ; Fri, 3 Feb 2023 08:41:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 03 Feb 2023 08:41:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t= 1675431678; x=1675518078; bh=tvBSLAhxKDFN3GmlM3uxpdPsRfrKmQDWAeW kiR8yYFk=; b=y1Fiiu6yXCyV2QCWG3BpDiNI42K1zQhwYW6yg9nHHJGbLkIKPz7 CCnRtxyOjn9Tht0soYsU4mYaVhZr9qRhV280bzhoCAGsjct2sDSVUBm+Lwmhm1NO Hd2ZGQ4jzNpxvWk/UehVI+KhwYMeas1oO7R09CV7yB3AcuxB2tpqz7NQ1YBGajif MqMjdyAgMWKgVP3b7DbyD7XC/tyFeJLcN+ojA7vsXbNnAXinTLzm0rVW22ENKP5f hcBoqH0QVblVzgciKuq8Koglb16XSj+z4TvNiEdGdgYjTg4OdxCDOSktKpS3Bcfb s2oc7Dege9I0tuimcJTCy7/DodlKK2ESxpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1675431678; x= 1675518078; bh=tvBSLAhxKDFN3GmlM3uxpdPsRfrKmQDWAeWkiR8yYFk=; b=o C6istoBK4IYp+rv+gwq6cuD6ernhhiS/xZ0H1IxOE/UTJPLxpthTY1tnUKPh4rPU ey43C0vrpd4OI0VVXU+drI7BhD/0YJFM8k/5ni6obP9T4WtompoQUEpUhT5+XrIP ntIOYPxeqLroxzIDDFlClLp2NWPdQnJVGO221Oyw19XsJpCLxX3yRWCT/XYi1ewE v/3yh1xUw1yOTHZxsZvI+DNaEsa65vRcBmISd/i3KsIqERhGqKCfjlc5f4BEEct8 fQqNByQNT/OT36Lx72exAYImIuSRukX31FOGCAa2YasmCAofCraxqIGJ5Vi0G17b /VJdvMHvyjBt0iJyd4w+g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegtddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 3 Feb 2023 08:41:17 -0500 (EST) Date: Fri, 3 Feb 2023 13:41:15 +0000 From: void To: freebsd-stable@freebsd.org Subject: avoiding periodic(8) during long poudriere runs Message-ID: Mail-Followup-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.69 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4P7cHz1Dx2z46XH X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N Hello stable@ How does one avoid periodic(8) during long poudriere runs? I find that it'll cause the system to thrash if periodic starts when poudriere is running. is there some established way of telling it not to run when, for example, 5 min load is over 2.00 ? I've seen ubuntu do similar, but am unsure of the exact mechanism. tia, -- From nobody Fri Feb 3 13:54:51 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7cbf2Yl5z2p8mm for ; Fri, 3 Feb 2023 13:54:54 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7cbd34gbz49l0 for ; Fri, 3 Feb 2023 13:54:53 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=hT2AP6DF; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=oM2DbSJB; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 523E55C01C1 for ; Fri, 3 Feb 2023 08:54:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 03 Feb 2023 08:54:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1675432493; x=1675518893; bh=91SiTueQMY 9s1HH4E2RfnAvW4LbDyXHCqOUjWbxheHM=; b=hT2AP6DFEwkX1r6Daf82nGs7tI pIpsHQaKkad1dd/LatfUEUIthITWtAeyx4XAqZS2trOHBL+cMr9ZKsK3yLlar2Bu Nz8UcbMTQVrq+sVCI0NQ3ljDEQtSjtkUbct1wmU4JDyf40q02ooh5SdlTBn/uc64 f3bXZA/wHkDDk3H9Zuw0zmT112zPf3wRp0CZK3xK3StJ9V+W38y8rbaTYvppgFd1 C6WpKQwtCcrZAh9c8iVcLIh74X3MD3WQV1JLQ/jZQgANZw3i4jCSPpDgwbB4CHVm 4HxhIhfG+e3dRUIhk2A97H3r27gN6Av4C6G1ueJf63RjU6EQ6o9k2sK2PkVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675432493; x=1675518893; bh=91SiTueQMY9s1HH4E2RfnAvW4LbD yXHCqOUjWbxheHM=; b=oM2DbSJBd7VE8F3nmXv+vMT5J+xchNk4fNDxYpJhzX+H 8KqJx0gLbwSbjMpVcD+5JyHbPuy/tJbKPO65bQSK7e8aCpfcu45ntLb44gGUnRRB TpnqWGHmUFtF0XTGnearFW3hvVQPSJTWm1AKWX+vHX39otwaj9EIVRpUyCFLB0xL js1fG4h5cJ/mZJHZQCR77pqu033skLs/I8yVwic35O2w1c1ox0SK+glEi9/UnjgW /EKyjV0mYKbILhE4vI6rj5iy5dTKKicqtOvIsvgiycLmER3n2kPWQdVDmOUihNeO IBWnHxCRFxDoEoKaGwsHhGzfZarFTdmKmRSebzMgSQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegtddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 3 Feb 2023 08:54:52 -0500 (EST) Date: Fri, 3 Feb 2023 13:54:51 +0000 From: void To: freebsd-stable@freebsd.org Subject: Re: buildworld fails with bhyverun.c:1270:6 unused variable??? Message-ID: Mail-Followup-To: freebsd-stable@freebsd.org References: <86a62bd7sf.fsf@virtual-earth.de> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <86a62bd7sf.fsf@virtual-earth.de> X-Spamd-Result: default: False [-3.69 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25:c]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4P7cbd34gbz49l0 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sat, Jan 21, 2023 at 07:55:05PM +0100, Mathias Picker wrote: >I have this for some time, had no time to look into this, but >today I deleted /usr/src, fetched source again, switched to >stable/13, did a su -l root, removed /etc/make.conf and rebuild, >same error. Not sure if you've tried this, but generically when I encounter problems like this, I'll rm -rf /usr/obj, then re-create it, and also if you're using ccache, do the same in the ccache dir (mine is at /var/cache/ccache). Then, fetch sources, cd into /usr/src then "make -j16 cleanworld && make -j16 cleandir && make -j16 clean" just to make absolutely certain, before buildworld. -- From nobody Fri Feb 3 14:18:53 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7d524zsJz2pB46 for ; Fri, 3 Feb 2023 14:16:54 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7d522xxqz4FMl for ; Fri, 3 Feb 2023 14:16:54 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IDC4SfW5FltmujHwWrIhcumj0FZz2ZbDdLL7b/hRzxo=; b=qH11hawjcD6mgQONpHEmrXdIfn UA2lGSQUyXbAjkcs3O08G2p5o0szZrn7D2e5xxnJxDQFvScOFFCMSvnTck3WU3MBW8E5+saZjG8ge nRF6SMV/5aNP67HwFa5H3ZF1qn2RloboWYUdQomjNRygoKcsB012A8J5Etr865ArcWGfy/EX8f3cD tsSBWm0Adn8GASuT4gvv2P7H3pScO8HzftgtRaYl2GkuK0w0REEpiWCkQ2CWmuU2gzJzfEm1g+Ap1 agOILQOJPZX4xn7p8wRKZZqesI4au34ihp0fdjjCzahQNvQPS+28aD5j+uBbHThmobHVXceZoJO/H 8lKyaHPg==; Received: from ti0027q160-0136.bb.online.no ([37.200.21.137]:26186 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pNwry-003Q4C-53; Fri, 03 Feb 2023 15:16:50 +0100 Date: Fri, 3 Feb 2023 15:18:53 +0100 From: Eivind Nicolay Evensen To: Eugene Grosbein Cc: freebsd-stable@freebsd.org Subject: Re: Grep with non-ascii Message-ID: <20230203151853.02732bd6@elg.hjerdalen.lokalnett> In-Reply-To: <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P7d522xxqz4FMl X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Den Fri, 3 Feb 2023 19:12:32 +0700 skrev Eugene Grosbein : > 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > > Hello. > > > > I just noticed this today: > > > > elg!ene[~]> printf "b\nhei\nl\n" | grep > > grep: trailing backslash (\) > > elg!ene[~]> echo $LC_CTYPE $LANG > > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > > > While I have the result I envisioned with gnugrep: > > > > elg!ene[~]> printf "b\nhei\nl\n" | ggrep > > b > > l > > > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper > > result. > > > > Is lib/libc/regex the right place to look into this if I > > find the time, or does anybody know this enough to know the > > problem? > > Try single quotes instead of double quotes. > And pleace specify system version and shell name, and shell version > if its not in base system. This is elg!ene[~]> uname -a FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD 13.2-PRERELEASE #1: Tue Jan 31 11:23:29 CET 2023 ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv amd64 Using the tcsh that comes with it. But I don't think the quotes matter much because of this: elg!ene[~]> grep grep: trailing backslash (\) The output was more just to have something to look for, like with ggrep but anyway: elg!ene[~]> printf 'b\nhei\nl\n' |grep grep: trailing backslash (\) And obviously: elg!ene[~]> printf 'b\nhei\nl\n' b hei l And it seems to be the same for any 8859-1 character not part of ascii: elg!ene[~]> grep grep: trailing backslash (\) elg!ene[~]> grep grep: trailing backslash (\) elg!ene[~]> grep grep: trailing backslash (\) -- Eivind Nicolay Evensen From nobody Fri Feb 3 14:26:17 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7dFX3QFQz2pBTg for ; Fri, 3 Feb 2023 14:24:16 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7dFX31Cqz4JT3 for ; Fri, 3 Feb 2023 14:24:16 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0GWmlsbu13ooZJtIWG4oGp/ZcpF5LeYSBXTEXW4Oa7U=; b=rZ6IdxdxlBYh/6n668onoFVi8z cSRBlteFQau1+4SVobdXwXH4cL4S2/Nk+rGcyqwGm6ydxj7haDL4BQHjrMQVb1eXrxHLKnJthlWMV ref9l9c7/bDna4Ifaz2Yf3jXVd/VbDZ7qlKrFgN+SNAZzbReGdZlizbZtZjMlVIhCulE7idBY7yuv p+H53mqTApLpmC8cbFBna4pO++JEcqVkAhnkgAEZZ+74XjlNotBCURIXMC77LrjwLvGPlfL1R/G3y t2zaOIFAcY+NkZ7Bm8DNmkMf02jmGKaW3M8jiMF5S+5FKcvDLmUX2KDUR9Lzgp0ZQhqrtn6mm1Pji tgceCoTQ==; Received: from ti0027q160-0136.bb.online.no ([37.200.21.137]:26271 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pNwz8-003TTT-Mm; Fri, 03 Feb 2023 15:24:14 +0100 Date: Fri, 3 Feb 2023 15:26:17 +0100 From: Eivind Nicolay Evensen To: Tomoaki AOKI Cc: stable@freebsd.org Subject: Re: Grep with non-ascii Message-ID: <20230203152617.00e01686@elg.hjerdalen.lokalnett> In-Reply-To: <20230203203948.23d66303bcae8c528202071a@dec.sakura.ne.jp> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <20230203203948.23d66303bcae8c528202071a@dec.sakura.ne.jp> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P7dFX31Cqz4JT3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Den Fri, 3 Feb 2023 20:39:48 +0900 skrev Tomoaki AOKI : > On Fri, 3 Feb 2023 11:06:42 +0100 > Eivind Nicolay Evensen wrote: > > > Hello. > > > > I just noticed this today: > > > > elg!ene[~]> printf "b\nhei\nl\n" | grep > > grep: trailing backslash (\) > > elg!ene[~]> echo $LC_CTYPE $LANG > > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > > > While I have the result I envisioned with gnugrep: > > > > elg!ene[~]> printf "b\nhei\nl\n" | ggrep > > b > > l > > > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper > > result. > > > > Is lib/libc/regex the right place to look into this if I > > find the time, or does anybody know this enough to know the > > problem? > > > > Regards > > -- > > Eivind Nicolay Evensen > > Possibly a locale problem, or depending on what command line shell you > are using. > > Tried copy/pasting to command line, I got the result below. > > % printf "b\nhei\nl\n" | grep > b > l > > I'm using LC_ALL=ja_JP.UTF-8, LANG=ja_JP.UTF-8 as locale and > shells/zsh as command line shell. > > What happenes if you switch locale to nb_NO.UTF-8? > Indeed seems like a locale problem, because it works when I change it: elg!ene[~]> grep grep: trailing backslash (\) (i select UTF-8 encoding in the xterm menu here) elg!ene[~]> setenv LC_CTYPE nb_NO.UTF-8 elg!ene[~]> grep zzz ^D Perhaps for more of them, I just tried this (back to non-utf8 encoding in xterm): elg!ene[~]> setenv LC_CTYPE sv_SE.ISO8859-1 elg!ene[~]> grep grep: trailing backslash (\) and elg!ene[~]> setenv LC_CTYPE de_DE.ISO8859-1 elg!ene[~]> grep grep: trailing backslash (\) elg!ene[~]> grep grep: trailing backslash (\) elg!ene[~]> -- Eivind Nicolay Evensen From nobody Fri Feb 3 16:06:05 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7gW85SB4z3kTCf for ; Fri, 3 Feb 2023 16:06:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7gW66vWnz3lnZ for ; Fri, 3 Feb 2023 16:06:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 313G65eq049117 for ; Sat, 4 Feb 2023 01:06:05 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 4 Feb 2023 01:06:05 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: Grep with non-ascii Message-Id: <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> In-Reply-To: <20230203151853.02732bd6@elg.hjerdalen.lokalnett> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.57 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P7gW66vWnz3lnZ X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Feb 2023 15:18:53 +0100 Eivind Nicolay Evensen wrote: > Den Fri, 3 Feb 2023 19:12:32 +0700 > skrev Eugene Grosbein : > > > 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > > > Hello. > > > > > > I just noticed this today: > > > > > > elg!ene[~]> printf "bø\nhei\nøl\n" | grep ø > > > grep: trailing backslash (\) > > > elg!ene[~]> echo $LC_CTYPE $LANG > > > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > > > > > While I have the result I envisioned with gnugrep: > > > > > > elg!ene[~]> printf "bø\nhei\nøl\n" | ggrep ø > > > bø > > > øl > > > > > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper > > > result. > > > > > > Is lib/libc/regex the right place to look into this if I > > > find the time, or does anybody know this enough to know the > > > problem? > > > > Try single quotes instead of double quotes. > > And pleace specify system version and shell name, and shell version > > if its not in base system. > > This is > elg!ene[~]> uname -a > FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD 13.2-PRERELEASE > #1: Tue Jan 31 11:23:29 CET 2023 > ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv > amd64 > > Using the tcsh that comes with it. But I don't think the quotes matter > much because of this: > > elg!ene[~]> grep ø > grep: trailing backslash (\) > > The output was more just to have something to look for, like > with ggrep but anyway: > > elg!ene[~]> printf 'bø\nhei\nøl\n' |grep ø > grep: trailing backslash (\) > > And obviously: > > elg!ene[~]> printf 'bø\nhei\nøl\n' > bø > hei > øl > > And it seems to be the same for any 8859-1 character not part > of ascii: > > elg!ene[~]> grep ä > grep: trailing backslash (\) > elg!ene[~]> grep ß > grep: trailing backslash (\) > elg!ene[~]> grep ç > grep: trailing backslash (\) > > -- > Eivind Nicolay Evensen I recalled very, very old problem on Japanese characters. Does the characters you mentioned include 0x5c in nb_NO.ISO8859-1 charset? In dirty, ugly DOS era, Shift-JIS (CP932) was the mainstream in Japan. In this charset, some 2bytes kanji characters have 0x5c in its second byte. This caused imported, non-Japanese-aware softwares mis-handle Japanese texts, and the workaround was to add excessive 0x5c after problematic characters. :-( For example, 表示 in Shift-JIS bytestream was 0x95 0x5c 0x8e 0xa6, and as 0x5c was usually considered as backslash, escape character, it was modified to 0x95 0x8e 0xa6 in non-Japanese softwares. As this mis-conversion often happened recussively, the required numbers of excessive 0x5c varied, varied and varied!!!!! Crazily. If this is the case like above, the only solution is to move to character set containing ALL characters all over the world. AFAIK, the only candidates are only two, TRON code [1] and Unicode (UCS, ISO/IEC 10646) [2]. And TRON code is very rarely used, actual candidate would be Unicode only. Note that Unicode is usually encoded to any of UTF-8, UTF-16 or UTF-32 for data transfer (sometimes raw UCS-2?). [1] https://en.wikipedia.org/wiki/TRON_(encoding) [2] https://en.wikipedia.org/wiki/Unicode P.S. On UTF-8, character ø was encoded to UTF-8: 0xC3 0xB8. So it should be OK. -- Tomoaki AOKI From nobody Fri Feb 3 16:31:55 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7h2Y3V6qz3kV5j for ; Fri, 3 Feb 2023 16:29:57 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7h2Y1Xz6z3qx2 for ; Fri, 3 Feb 2023 16:29:57 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S7Hz8ARJ9fTDxV1Qe+3zA3E7qEgU3dPAOrCx8McYTgQ=; b=IJ7dQMjQKskn8cCzZ7+s/85mzO BDshtjEKAdo8rEJyyMqYQEdgN2p10fBGqJFhtaFijrz3Nl7+O7Sp1t0QImBLodKAxwt+eBt8MW8jn 2pOGwLHy8sPovY/kMIBa78GISH4ekgiJ21ZJazN9dBNq5hM/iBv8tH/Is9e57WWOV6T3urciNTHHt m1KyQWcujmW9IJsDpKzYYCbFCGVnomLzbV4RPqBYBFQetlvWQievDdSCL+mAxq4vUJ7MfiSsKgmQY onLp0BqEOn0IJU3NMS1IhoE/HBqcqbgNOTpgQkly1stAj/b2V9JX0n2zP2lwC/n3dCPdpx+1GYLvm P3sLR1fw==; Received: from ti0027q160-0136.bb.online.no ([37.200.21.137]:27596 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pNywj-004ERR-EW; Fri, 03 Feb 2023 17:29:54 +0100 Date: Fri, 3 Feb 2023 17:31:55 +0100 From: Eivind Nicolay Evensen To: Tomoaki AOKI Cc: stable@freebsd.org Subject: Re: Grep with non-ascii Message-ID: <20230203173155.179902a4@elg.hjerdalen.lokalnett> In-Reply-To: <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P7h2Y1Xz6z3qx2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Den Sat, 4 Feb 2023 01:06:05 +0900 skrev Tomoaki AOKI : > On Fri, 3 Feb 2023 15:18:53 +0100 > Eivind Nicolay Evensen wrote: > > > Den Fri, 3 Feb 2023 19:12:32 +0700 > > skrev Eugene Grosbein : > > > > > 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > > > > Hello. > > > > > > > > I just noticed this today: > > > > > > > > elg!ene[~]> printf "b\nhei\nl\n" | grep > > > > grep: trailing backslash (\) > > > > elg!ene[~]> echo $LC_CTYPE $LANG > > > > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > > > > > > > While I have the result I envisioned with gnugrep: > > > > > > > > elg!ene[~]> printf "b\nhei\nl\n" | ggrep > > > > b > > > > l > > > > > > > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper > > > > result. > > > > > > > > Is lib/libc/regex the right place to look into this if I > > > > find the time, or does anybody know this enough to know the > > > > problem? > > > > > > Try single quotes instead of double quotes. > > > And pleace specify system version and shell name, and shell > > > version if its not in base system. > > > > This is > > elg!ene[~]> uname -a > > FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD > > 13.2-PRERELEASE #1: Tue Jan 31 11:23:29 CET 2023 > > ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv > > amd64 > > > > Using the tcsh that comes with it. But I don't think the quotes > > matter much because of this: > > > > elg!ene[~]> grep > > grep: trailing backslash (\) > > > > The output was more just to have something to look for, like > > with ggrep but anyway: > > > > elg!ene[~]> printf 'b\nhei\nl\n' |grep > > grep: trailing backslash (\) > > > > And obviously: > > > > elg!ene[~]> printf 'b\nhei\nl\n' > > b > > hei > > l > > > > And it seems to be the same for any 8859-1 character not part > > of ascii: > > > > elg!ene[~]> grep > > grep: trailing backslash (\) > > elg!ene[~]> grep > > grep: trailing backslash (\) > > elg!ene[~]> grep > > grep: trailing backslash (\) > > > > -- > > Eivind Nicolay Evensen > > I recalled very, very old problem on Japanese characters. > Does the characters you mentioned include 0x5c in nb_NO.ISO8859-1 > charset? > > In dirty, ugly DOS era, Shift-JIS (CP932) was the mainstream in Japan. > In this charset, some 2bytes kanji characters have 0x5c in its second > byte. > > This caused imported, non-Japanese-aware softwares mis-handle Japanese > texts, and the workaround was to add excessive 0x5c after problematic > characters. :-( > > For example, ?? in Shift-JIS bytestream was 0x95 0x5c 0x8e 0xa6, and > as 0x5c was usually considered as backslash, escape character, it was > modified to 0x95 0x8e 0xa6 in non-Japanese softwares. > As this mis-conversion often happened recussively, the required > numbers of excessive 0x5c varied, varied and varied!!!!! Crazily. > > If this is the case like above, the only solution is to move to > character set containing ALL characters all over the world. > > AFAIK, the only candidates are only two, TRON code [1] and Unicode > (UCS, ISO/IEC 10646) [2]. And TRON code is very rarely used, actual > candidate would be Unicode only. > Note that Unicode is usually encoded to any of UTF-8, UTF-16 or UTF-32 > for data transfer (sometimes raw UCS-2?). > > > [1] https://en.wikipedia.org/wiki/TRON_(encoding) > [2] https://en.wikipedia.org/wiki/Unicode > > P.S. > On UTF-8, character was encoded to UTF-8: 0xC3 0xB8. So it should be > OK. In 8859-1, "" is: elg!ene[~]> printf |hexdump -C 00000000 f8 || 00000001 so this does not seem to be the problem here. And all those characters I tried are one-byte (all 8859-1 are): elg!ene[~]> printf "" |hexdump -C 00000000 e4 df e7 || 00000003 So I do not believe this is the same problem. I did, however, find it interesting that multi-byte character sets may have been in use longer than I imagined. -- Eivind Nicolay Evensen From nobody Fri Feb 3 17:13:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7j1X24plz3kXVG for ; Fri, 3 Feb 2023 17:14:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7j1X13Vdz43Ny; Fri, 3 Feb 2023 17:14:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675444448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mdcx8fhodRujGG2FNg45Ls2v9TQ3kuy4NJnJXCdE9W4=; b=TELfeDMaVKVzdUMsyW5mcGe8Yoseebu3w4kLIJYEy653weDd4iGUB6k6/VDzeX+1UkIBef IF13ZVlL6vHkdBvHcWqC1b8UGjbsSyFRiHBYtF4BYHmON/FtHr09G3fKrOoiGjTHaUw5+j YJ/Fjj/jqLFh5NFvwdF7NknXOAgM1hQy6ZPM8D12tJFmhgcYtNDOv9Qhemgdjtt5r53G8i dstuqA/KQkqm3nTc1IuVnE7PtkoLiUBhyFfRToDLTqzMhbfrf9oBOhHZfrRQmz7YwS+6Py 1xc+j1a4sk/4vExJK7eUbLz3OvC6T/FEscCoVzIBxGX/HU67FlC03I4pboMWZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675444448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mdcx8fhodRujGG2FNg45Ls2v9TQ3kuy4NJnJXCdE9W4=; b=PHls0P0JmPSs2MCzFpK+bLSN96CV3///9NapbL9tyMjnj2cUOXNeknb6q/JvLdvu/TfYLl l3yL9gADqDGh+P6XBf3Fe8lmyU/fva4OjJUTC/rS0p2T9UnEIzzSsdKYcPDo6OUyigKiC4 I7RHwLdiWZ5px+zyPclHk+Ugj/LZPIkOl+mC/dzGtjktd50zN8T0m7Va8pk0jzeV/DDdEI cQbgnGudXeqFMXy2cMqfLSyed1uFNxoflcZhVw99bE1Y4fqFeRQaQNolGAZ7niqVnhsCi/ CH7EoghzFz9RSYbBdiCqv5dzLn1dEHIAEONq2Lel8YPYGhz5UWyAoodTp+TjWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675444448; a=rsa-sha256; cv=none; b=VePFDVpwt99bUj5KLTCOwt04qABgOrRlzBw/aoDVZY6Y79bZz5ftHWAtdozqTCl2j3ZzLI Qm9L4pWq01KcWIBv/qAWLwFcG0IJPd+s6uFXWl++A3PJWpoC5I7ZBuSViNT0zqev2M3zWY D+dpgkTWrf2TkiC1Rtks51fv2LyfTleSJMSaixL6EMeCRb3eDxDDCQ2EFMDvXHV9NB7Pze CwWN03I9gJJJR/CmebVRzmqYsARFbERBj+k58S53TgOkZHxhWtXxlfkDchQk0LXDOXVKNA +z30TtLWXKJcoIiqyAT8bYasru6r3M0pcLYyI+DjR3dy8MPDwxcO5vsYERjbvQ== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4P7j1W6RvHz12Y3; Fri, 3 Feb 2023 17:14:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A681A4293C; Fri, 3 Feb 2023 18:14:06 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_2DA3923C-443B-451F-BB30-2E54AC0F0B56"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: buildworld fails with bhyverun.c:1270:6 unused variable??? From: Dimitry Andric In-Reply-To: <86a62bd7sf.fsf@virtual-earth.de> Date: Fri, 3 Feb 2023 18:13:48 +0100 Cc: freebsd-stable@freebsd.org Message-Id: References: <86a62bd7sf.fsf@virtual-earth.de> To: Mathias Picker X-Mailer: Apple Mail (2.3731.400.51.1.1) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_2DA3923C-443B-451F-BB30-2E54AC0F0B56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Jan 2023, at 19:55, Mathias Picker = wrote: >=20 > I have this for some time, had no time to look into this, but today I = deleted /usr/src, fetched source again, switched to stable/13, did a su = -l root, removed /etc/make.conf and rebuild, same error. ... > --- all_subdir_usr.sbin/bhyve --- > /usr/src/usr.sbin/bhyve/bhyverun.c:1270:6: error: unused variable = 'vcpu' [-Werror,-Wunused-variable] > int vcpu; > ^ I've looked at both the stable/13 and main branches, but in neither of them is line 1270 a line with the contents 'int vcpu;'. So I think something is wrong with your checkout. How exactly did you "switch to stable/13"? And what does "git status" report? -Dimitry --Apple-Mail=_2DA3923C-443B-451F-BB30-2E54AC0F0B56 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCY91AzAAKCRCwXqMKLiCW o1zPAKC1m4I1kcr6JbKVfy5YUPa9hlrDdACfYvYOxOGOcfJ6Pti0OzlYjNQqSAU= =6GOp -----END PGP SIGNATURE----- --Apple-Mail=_2DA3923C-443B-451F-BB30-2E54AC0F0B56-- From nobody Fri Feb 3 17:36:47 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7jWx3L1Jz3kYjK for ; Fri, 3 Feb 2023 17:37:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7jWw4yq3z46tc for ; Fri, 3 Feb 2023 17:37:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 313HalPH033132 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 3 Feb 2023 12:36:53 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Fri, 3 Feb 2023 12:36:47 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Grep with non-ascii To: stable@freebsd.org References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> Content-Language: en-US From: George Mitchell In-Reply-To: <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[freebsd]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[m5p.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P7jWw4yq3z46tc X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 2/3/23 11:06, Tomoaki AOKI wrote: > [...] > If this is the case like above, the only solution is to move to > character set containing ALL characters all over the world. > > AFAIK, the only candidates are only two, TRON code [1] and Unicode (UCS, > ISO/IEC 10646) [2]. And TRON code is very rarely used, actual candidate > would be Unicode only. > Note that Unicode is usually encoded to any of UTF-8, UTF-16 or UTF-32 > for data transfer (sometimes raw UCS-2?). > [...] The one positive development in the world of computing that I would credit to Java is the earliest big push toward the adoption of UTF-8. I strongly hope UTF-8 becomes universally used sooner rather than later. -- George From eugen@grosbein.net Sat Feb 4 01:41:17 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7wHP2s3Qz3kVlc for ; Sat, 4 Feb 2023 01:41:53 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7wHN6GF5z4012 for ; Sat, 4 Feb 2023 01:41:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Authentication-Results: mx1.freebsd.org; none Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 3141fgUk015904 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 4 Feb 2023 01:41:43 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: eivinde@terraplane.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 3141ffhZ013794 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 4 Feb 2023 08:41:41 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Grep with non-ascii To: Eivind Nicolay Evensen References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: Date: Sat, 4 Feb 2023 08:41:17 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 In-Reply-To: <20230203151853.02732bd6@elg.hjerdalen.lokalnett> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4P7wHN6GF5z4012 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 03.02.2023 21:18, Eivind Nicolay Evensen wrote: > Den Fri, 3 Feb 2023 19:12:32 +0700 > skrev Eugene Grosbein : > >> 03.02.2023 17:06, Eivind Nicolay Evensen wrote: >>> Hello. >>> >>> I just noticed this today: >>> >>> elg!ene[~]> printf "b\nhei\nl\n" | grep >>> grep: trailing backslash (\) >>> elg!ene[~]> echo $LC_CTYPE $LANG >>> nb_NO.ISO8859-1 nb_NO.ISO8859-1 >>> >>> While I have the result I envisioned with gnugrep: >>> >>> elg!ene[~]> printf "b\nhei\nl\n" | ggrep >>> b >>> l >>> >>> Also, on OpenIndiana, linux and Netbsd, grep gives the proper >>> result. >>> >>> Is lib/libc/regex the right place to look into this if I >>> find the time, or does anybody know this enough to know the >>> problem? >> >> Try single quotes instead of double quotes. >> And pleace specify system version and shell name, and shell version >> if its not in base system. > > This is > elg!ene[~]> uname -a > FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD 13.2-PRERELEASE > #1: Tue Jan 31 11:23:29 CET 2023 > ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv > amd64 > > Using the tcsh that comes with it. But I don't think the quotes matter > much because of this: > > elg!ene[~]> grep > grep: trailing backslash (\) > > The output was more just to have something to look for, like > with ggrep but anyway: > > elg!ene[~]> printf 'b\nhei\nl\n' |grep > grep: trailing backslash (\) > > And obviously: > > elg!ene[~]> printf 'b\nhei\nl\n' > b > hei > l > > And it seems to be the same for any 8859-1 character not part > of ascii: > > elg!ene[~]> grep > grep: trailing backslash (\) > elg!ene[~]> grep > grep: trailing backslash (\) > elg!ene[~]> grep > grep: trailing backslash (\) I checked it with ru_RU.KOI8-R locale and same problem manifested, with every Cyrillic letter. The following line shows codes and characters of affected positions in last half of 8-bit character table. $ jot -w '%o' - 128 255 1 | xargs -n2 -I^ printf '^ \^\n' | while read octal char; do grep -q "$char" /etc/motd 2>/dev/null; [ $? -gt 1 ] && echo $octal $char; done Note that this problem does not exist in 12.4 or earlier FreeBSD versions, so this is recent regression. Surely that's due to grep command being GNU grep in 12.4 but BSD grep in 13.x From nobody Sat Feb 4 03:46:02 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7z2w49Mpz3kcmd for ; Sat, 4 Feb 2023 03:46:16 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7z2t6L2Gz4Cnf for ; Sat, 4 Feb 2023 03:46:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 3143k2Af044157 for ; Sat, 4 Feb 2023 12:46:03 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 4 Feb 2023 12:46:02 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: Grep with non-ascii Message-Id: <20230204124602.abe78f4a441f747941d3f858@dec.sakura.ne.jp> In-Reply-To: <20230203173155.179902a4@elg.hjerdalen.lokalnett> References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> <20230203173155.179902a4@elg.hjerdalen.lokalnett> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.60 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P7z2t6L2Gz4Cnf X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Feb 2023 17:31:55 +0100 Eivind Nicolay Evensen wrote: > Den Sat, 4 Feb 2023 01:06:05 +0900 > skrev Tomoaki AOKI : > > > On Fri, 3 Feb 2023 15:18:53 +0100 > > Eivind Nicolay Evensen wrote: > > > > > Den Fri, 3 Feb 2023 19:12:32 +0700 > > > skrev Eugene Grosbein : > > > > > > > 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > > > > > Hello. > > > > > > > > > > I just noticed this today: > > > > > > > > > > elg!ene[~]> printf "bø\nhei\nøl\n" | grep ø > > > > > grep: trailing backslash (\) > > > > > elg!ene[~]> echo $LC_CTYPE $LANG > > > > > nb_NO.ISO8859-1 nb_NO.ISO8859-1 > > > > > > > > > > While I have the result I envisioned with gnugrep: > > > > > > > > > > elg!ene[~]> printf "bø\nhei\nøl\n" | ggrep ø > > > > > bø > > > > > øl > > > > > > > > > > Also, on OpenIndiana, linux and Netbsd, grep gives the proper > > > > > result. > > > > > > > > > > Is lib/libc/regex the right place to look into this if I > > > > > find the time, or does anybody know this enough to know the > > > > > problem? > > > > > > > > Try single quotes instead of double quotes. > > > > And pleace specify system version and shell name, and shell > > > > version if its not in base system. > > > > > > This is > > > elg!ene[~]> uname -a > > > FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD > > > 13.2-PRERELEASE #1: Tue Jan 31 11:23:29 CET 2023 > > > ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv > > > amd64 > > > > > > Using the tcsh that comes with it. But I don't think the quotes > > > matter much because of this: > > > > > > elg!ene[~]> grep ø > > > grep: trailing backslash (\) > > > > > > The output was more just to have something to look for, like > > > with ggrep but anyway: > > > > > > elg!ene[~]> printf 'bø\nhei\nøl\n' |grep ø > > > grep: trailing backslash (\) > > > > > > And obviously: > > > > > > elg!ene[~]> printf 'bø\nhei\nøl\n' > > > bø > > > hei > > > øl > > > > > > And it seems to be the same for any 8859-1 character not part > > > of ascii: > > > > > > elg!ene[~]> grep ä > > > grep: trailing backslash (\) > > > elg!ene[~]> grep ß > > > grep: trailing backslash (\) > > > elg!ene[~]> grep ç > > > grep: trailing backslash (\) > > > > > > -- > > > Eivind Nicolay Evensen > > > > I recalled very, very old problem on Japanese characters. > > Does the characters you mentioned include 0x5c in nb_NO.ISO8859-1 > > charset? > > > > In dirty, ugly DOS era, Shift-JIS (CP932) was the mainstream in Japan. > > In this charset, some 2bytes kanji characters have 0x5c in its second > > byte. > > > > This caused imported, non-Japanese-aware softwares mis-handle Japanese > > texts, and the workaround was to add excessive 0x5c after problematic > > characters. :-( > > > > For example, ?? in Shift-JIS bytestream was 0x95 0x5c 0x8e 0xa6, and > > as 0x5c was usually considered as backslash, escape character, it was > > modified to 0x95 0x8e 0xa6 in non-Japanese softwares. > > As this mis-conversion often happened recussively, the required > > numbers of excessive 0x5c varied, varied and varied!!!!! Crazily. > > > > If this is the case like above, the only solution is to move to > > character set containing ALL characters all over the world. > > > > AFAIK, the only candidates are only two, TRON code [1] and Unicode > > (UCS, ISO/IEC 10646) [2]. And TRON code is very rarely used, actual > > candidate would be Unicode only. > > Note that Unicode is usually encoded to any of UTF-8, UTF-16 or UTF-32 > > for data transfer (sometimes raw UCS-2?). > > > > > > [1] https://en.wikipedia.org/wiki/TRON_(encoding) > > [2] https://en.wikipedia.org/wiki/Unicode > > > > P.S. > > On UTF-8, character ø was encoded to UTF-8: 0xC3 0xB8. So it should be > > OK. > > In 8859-1, "ø" is: > > elg!ene[~]> printf ø |hexdump -C > 00000000 f8 |ø| > 00000001 > > so this does not seem to be the problem here. And all those > characters I tried are one-byte (all 8859-1 are): > > elg!ene[~]> printf "äßç" |hexdump -C > 00000000 e4 df e7 |äßç| > 00000003 > > So I do not believe this is the same problem. I did, however, > find it interesting that multi-byte character sets may have been > in use longer than I imagined. > > > -- > Eivind Nicolay Evensen > OK. Agreed. Sorry for the noise. Possibly, 8bits (non-7bits) characters which is not a part of UTF-8 or on-memory Unicode would not be converted properly in BSD grep? 0x5c (backslash) problem was a nightmare for Japanese programmers and early adopters (running IBM PC softwares on NEC PC98 with simulator) ATM, came in conjunction with Turbo C that was not yet properly ported for Shift-JIS. :-( Until then, it was a nightmare only for corporate, professional programmers only. -- Tomoaki AOKI From nobody Sat Feb 4 04:16:37 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P7zk22DK3z3kfCj for ; Sat, 4 Feb 2023 04:16:42 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P7zk069R2z4GMw for ; Sat, 4 Feb 2023 04:16:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 3144Gc6t048408 for ; Sat, 4 Feb 2023 13:16:38 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 4 Feb 2023 13:16:37 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: Grep with non-ascii Message-Id: <20230204131637.4e8e66e086eea57f4bb27b12@dec.sakura.ne.jp> In-Reply-To: References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.60 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P7zk069R2z4GMw X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Feb 2023 12:36:47 -0500 George Mitchell wrote: > On 2/3/23 11:06, Tomoaki AOKI wrote: > > [...] > > If this is the case like above, the only solution is to move to > > character set containing ALL characters all over the world. > > > > AFAIK, the only candidates are only two, TRON code [1] and Unicode (UCS, > > ISO/IEC 10646) [2]. And TRON code is very rarely used, actual candidate > > would be Unicode only. > > Note that Unicode is usually encoded to any of UTF-8, UTF-16 or UTF-32 > > for data transfer (sometimes raw UCS-2?). > > [...] > > The one positive development in the world of computing that I would > credit to Java is the earliest big push toward the adoption of UTF-8. > I strongly hope UTF-8 becomes universally used sooner rather than > later. -- George And FreeBSD already has UTF-8. ;-) Drawbacks of UTF-8 are... *Han unification. Not exactly same but lookalike characters in Japanese, Chinese and Korean are fatally missingly unified. *Lack of proper support for variant forms of characters. Maybe Unicode should have another 2 dimensions, one for classifying wrongly unified CJK characters and another one for variants. *Font sets. Very limited number of fonts covers the whole Unicode codepoints that are assigned any of actual character. *FreeBSD base does not have full Unicode font for vt yet. (Input methods are the different problem, though.) -- Tomoaki AOKI From nobody Sat Feb 4 09:17:27 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P86Y03gtWz3mtlx for ; Sat, 4 Feb 2023 09:24:20 +0000 (UTC) (envelope-from Mathias.Picker@virtual-earth.de) Received: from www94.your-server.de (www94.your-server.de [213.133.104.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P86Y01JCQz4Yvk; Sat, 4 Feb 2023 09:24:20 +0000 (UTC) (envelope-from Mathias.Picker@virtual-earth.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtual-earth.de; s=default_1811; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To:From:References:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=YQgMbU5519JegjTMj501o7VBkPBZ0TY+z+unFJIVbzg=; b=YkOv/uloRbm8WbYm0WTQHX4fmY k30P8myZu4Xj/znc2FEKFwx6uU7zIQe1+1HWGlQp43MEcoJ5d0ISLpzipuMXkY3RCOd5nOUBMwuzs Hclu7BplmjV3M40Tk8/ANAtxbWwJBp7B3Tz3avLyBjISUZqVe/bbOk5j07KNopJ3JazufGicvCKTV wExqbHdJxkHh+8f7mA0w9huCp9S5pwpP3ALporpo5eQju0KNQ+TcKP3GkPNrkh2FiJLtwtHk9eVEO xZarsmYjJrpTHJJIzUsEZipzy1FzSaMXhtFozjKytHWmtXDJnQ+EECyaSNsLAm+gnaoEGe+uczoPJ mlKqeKUg==; Received: from sslproxy05.your-server.de ([78.46.172.2]) by www94.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pOEmQ-000OKY-EV; Sat, 04 Feb 2023 10:24:18 +0100 Received: from [2a01:c23:c1f6:2000:4a2a:e3ff:fe1a:da58] (helo=danton.virtual-earth.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pOEmP-000SuV-SQ; Sat, 04 Feb 2023 10:24:17 +0100 References: <86a62bd7sf.fsf@virtual-earth.de> User-agent: mu4e 1.8.14; emacs 28.2 From: Mathias Picker To: Dimitry Andric Cc: freebsd-stable@freebsd.org Subject: Re: buildworld fails with bhyverun.c:1270:6 unused variable??? Date: Sat, 04 Feb 2023 10:17:27 +0100 In-reply-to: Message-ID: <86zg9tbx6m.fsf@virtual-earth.de> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: Mathias.Picker@virtual-earth.de X-Virus-Scanned: Clear (ClamAV 0.103.7/26801/Fri Feb 3 10:47:03 2023) X-Rspamd-Queue-Id: 4P86Y01JCQz4Yvk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N iTurns out I had somethng in /etc/src.conf that I didn=E2=80=99t think of=20 (never actually used it): WITH_BHYVE_SNAPSHOT=3D"YES" commenting this out resulted in a sucessful make run with the=20 exact same src checkout. Looking at my current bhyverun.c I also no longer see that =E2=80=99int=20 vcpu=E2=80=99 on line 1270. I=E2=80=99ll recompile everything with WITH_BHYVE_SNAPSHOT=3D"YES" again=20 this weekend and report if it=E2=80=99s still there. Thanks for looking into this, Mathias Dimitry Andric writes: > [[PGP Signed Part:Undecided]] > On 21 Jan 2023, at 19:55, Mathias Picker=20 > wrote: >>=20 >> I have this for some time, had no time to look into this, but=20 >> today I deleted /usr/src, fetched source again, switched to=20 >> stable/13, did a su -l root, removed /etc/make.conf and=20 >> rebuild, same error. > ... >> --- all_subdir_usr.sbin/bhyve --- >> /usr/src/usr.sbin/bhyve/bhyverun.c:1270:6: error: unused=20 >> variable 'vcpu' [-Werror,-Wunused-variable] >> int vcpu; >> ^ > > I've looked at both the stable/13 and main branches, but in=20 > neither of > them is line 1270 a line with the contents 'int vcpu;'. So I=20 > think > something is wrong with your checkout. > > How exactly did you "switch to stable/13"? And what does "git=20 > status" > report? > > -Dimitry > > [[End of PGP Signed Part]] --=20 Mathias Picker=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 Gesch=C3=A4ftsf=C3=BChrer Mathias.Picker@virtual-earth.de virtual earth Gesellschaft f=C3=BCr Wissens re/pr=C3=A4 sentation mbH http://www.virtual-earth.de/ HRB126870 support@virtual-earth.de Westendstr. 142 089 / 1250 3943=20=20=20=20=20=20=20=20=20=20=20=20 From nobody Sat Feb 4 09:47:27 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P871M6TQ6z3mvGS for ; Sat, 4 Feb 2023 09:45:27 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3006::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P871M4Nvzz4bbX for ; Sat, 4 Feb 2023 09:45:27 +0000 (UTC) (envelope-from eivinde@terraplane.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=terraplane.org; s=ds202212; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eblhaI9wT94S1qBo0AKIuZLBRpAokY03cXeRQ1FM+z0=; b=IaJa4AsAIcSgwi6GsOckMdSL6v H55auA8lzn+X5Np27IDzjPrBN4fa9RaDbrO0i5MiUyZiu6sBbDgiz2Sg/3D/AUQFWO1+0zqrDShBQ jzwjCOUMtNTaTxcXZpMxNDpsBc09Ks31Jmy6B0UEtR8HmgWh1gLu+ngdw7tP8M9oRACCC9TlSkgNt Z/SSVm0JPQc1bL5N1hxIlBJg7ClfDbZKwkSy7cv8MMj4LsV5XF6Ykzi+p7NTpNzHI1DIxBzv2t0sL 8PNF55xe5TzRrL0gEPCtnxeILam5m1TKg2pU3AEjoGUcrUNx7tKlnOKUOinUT4p9F4xd3VBf8rafS JtXFVbfg==; Received: from ti0027q160-0136.bb.online.no ([37.200.21.137]:38673 helo=elg.hjerdalen.lokalnett) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pOF6p-006wP6-5h; Sat, 04 Feb 2023 10:45:23 +0100 Date: Sat, 4 Feb 2023 10:47:27 +0100 From: Eivind Nicolay Evensen To: Eugene Grosbein Cc: freebsd-stable@freebsd.org Subject: Re: Grep with non-ascii Message-ID: <20230204104727.72bb3715@elg.hjerdalen.lokalnett> In-Reply-To: References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4P871M4Nvzz4bbX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12996, ipnet:2a01:5b40::/48, country:NO] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Den Sat, 4 Feb 2023 08:41:17 +0700 skrev Eugene Grosbein : > 03.02.2023 21:18, Eivind Nicolay Evensen wrote: > > > Den Fri, 3 Feb 2023 19:12:32 +0700 > > skrev Eugene Grosbein : > > > >> 03.02.2023 17:06, Eivind Nicolay Evensen wrote: > >>> Hello. > >>> > >>> I just noticed this today: > >>> > >>> elg!ene[~]> printf "b\nhei\nl\n" | grep > >>> grep: trailing backslash (\) > >>> elg!ene[~]> echo $LC_CTYPE $LANG > >>> nb_NO.ISO8859-1 nb_NO.ISO8859-1 > >>> > >>> While I have the result I envisioned with gnugrep: > >>> > >>> elg!ene[~]> printf "b\nhei\nl\n" | ggrep > >>> b > >>> l > >>> > >>> Also, on OpenIndiana, linux and Netbsd, grep gives the proper > >>> result. > >>> > >>> Is lib/libc/regex the right place to look into this if I > >>> find the time, or does anybody know this enough to know the > >>> problem? > >> > >> Try single quotes instead of double quotes. > >> And pleace specify system version and shell name, and shell version > >> if its not in base system. > > > > This is > > elg!ene[~]> uname -a > > FreeBSD elg.hjerdalen.lokalnett 13.2-PRERELEASE FreeBSD > > 13.2-PRERELEASE #1: Tue Jan 31 11:23:29 CET 2023 > > ene@elg.hjerdalen.lokalnett:/usr/obj/usr/src/amd64.amd64/sys/ENE-spurv > > amd64 > > > > Using the tcsh that comes with it. But I don't think the quotes > > matter much because of this: > > > > elg!ene[~]> grep > > grep: trailing backslash (\) > > > > The output was more just to have something to look for, like > > with ggrep but anyway: > > > > elg!ene[~]> printf 'b\nhei\nl\n' |grep > > grep: trailing backslash (\) > > > > And obviously: > > > > elg!ene[~]> printf 'b\nhei\nl\n' > > b > > hei > > l > > > > And it seems to be the same for any 8859-1 character not part > > of ascii: > > > > elg!ene[~]> grep > > grep: trailing backslash (\) > > elg!ene[~]> grep > > grep: trailing backslash (\) > > elg!ene[~]> grep > > grep: trailing backslash (\) > > I checked it with ru_RU.KOI8-R locale and same problem manifested, > with every Cyrillic letter. The following line shows codes and > characters of affected positions in last half of 8-bit character > table. > > $ jot -w '%o' - 128 255 1 | xargs -n2 -I^ printf '^ \^\n' | while > read octal char; do grep -q "$char" /etc/motd 2>/dev/null; [ $? -gt 1 > ] && echo $octal $char; done > > Note that this problem does not exist in 12.4 or earlier FreeBSD > versions, so this is recent regression. Surely that's due to grep > command being GNU grep in 12.4 but BSD grep in 13.x That makes sense, since I know for certain I have grepped for Norwegian words containing without seeing this problem before. And I switched from 11 to 13 very late, and only because I wanted to use hardware unsupported by the old one, so that would explain why it took me so long to discover. -- Eivind Nicolay Evensen From nobody Sat Feb 4 13:36:02 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P8D7f1S2Bz3nPLL for ; Sat, 4 Feb 2023 13:36:14 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P8D7d39g7z3pMS for ; Sat, 4 Feb 2023 13:36:13 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 314Da2MA037436 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 4 Feb 2023 08:36:08 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sat, 4 Feb 2023 08:36:02 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Grep with non-ascii To: stable@freebsd.org References: <20230203110642.70e4a076@elg.hjerdalen.lokalnett> <819a4336-9689-bdbe-a90d-8f1d7b842662@grosbein.net> <20230203151853.02732bd6@elg.hjerdalen.lokalnett> <20230204010605.4874609f80eed28543407807@dec.sakura.ne.jp> <20230204131637.4e8e66e086eea57f4bb27b12@dec.sakura.ne.jp> Content-Language: en-US From: George Mitchell In-Reply-To: <20230204131637.4e8e66e086eea57f4bb27b12@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.970]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[freebsd]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[m5p.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P8D7d39g7z3pMS X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 2/3/23 23:16, Tomoaki AOKI wrote: > [...] > And FreeBSD already has UTF-8. ;-) > > Drawbacks of UTF-8 are... > *Han unification. Not exactly same but lookalike characters in > Japanese, Chinese and Korean are fatally missingly unified. > > *Lack of proper support for variant forms of characters. > Maybe Unicode should have another 2 dimensions, one for classifying > wrongly unified CJK characters and another one for variants. I confess that I don't know enough to comment on those. > > *Font sets. Very limited number of fonts covers the whole > Unicode codepoints that are assigned any of actual character. > > *FreeBSD base does not have full Unicode font for vt yet. > (Input methods are the different problem, though.) > Yes, but FreeBSD is making progress on remedying these problems. Many fonts DO have support for the codepoints I need, though. I think these are less of a problem than the problems that UTF-8 solves. -- George From nobody Sat Feb 4 18:11:57 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P8LGD54Fpz3nh4x for ; Sat, 4 Feb 2023 18:12:20 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P8LGC58pzz3C4b for ; Sat, 4 Feb 2023 18:12:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.126.123) smtp.mailfrom=paul@gromit.dlib.vt.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 8CB12485E3; Sat, 4 Feb 2023 13:12:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Slow WAN traffic to FreeBSD hosts but not to Linux hosts---how to debug/fix? From: Paul Mather In-Reply-To: Date: Sat, 4 Feb 2023 13:11:57 -0500 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <95EDCFCA-7E3F-458F-85A6-856D606B9D98@gromit.dlib.vt.edu> <4ed8b724-041f-f561-ae60-ab966aefbb68@plan-b.pwste.edu.pl> <282AF730-E5E0-4A50-9F47-E7301B36E5C8@gromit.dlib.vt.edu> <2ed582b9-b544-74bb-2047-99d04924b46b@plan-b.pwste.edu.pl> <8AE3B49C-6C7F-4A20-B2DC-0D4B1343FB59@gromit.dlib.vt.edu> <83E43236-60F8-4949-8840-54E66D327EE9@gromit.dlib.vt.edu> To: David <2yt@gmx.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-1.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; FREEMAIL_TO(0.00)[gmx.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[paul]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P8LGC58pzz3C4b X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Feb 1, 2023, at 5:54 PM, David <2yt@gmx.com> wrote: > On 2/1/23 14:07, Paul Mather wrote: >> On Feb 1, 2023, at 3:14 PM, Marek Zarychta = wrote: >>> W dniu 1.02.2023 o 20:33, Paul Mather pisze: >>>> It looks like we may have a winner, folks. I built and enabled the = extra TCP stacks and for the first time was able to max out my = connection to the remote FreeBSD system. I get consistently higher = throughput over the 15-hop WAN path to the remote FreeBSD system when = using the RACK TCP stack than when using the default "freebsd" stack. >>>>=20 >>>> Although the speeds are consistently higher when using the setting = "net.inet.tcp.functions_default=3Drack", they are still variable. = However, rather than the 3--4 MB/s I saw that kicked off this thread, I = now average over 10 MB/s. >>>>=20 >>>> I actually get the best results with = "net.inet.tcp.functions_default=3Dbbr" (having loaded tcp_bbr). That = behaves very much like the Linux hosts in that speeds climb very quickly = until it saturates the WAN connection. I get the same high speeds from = the remote FreeBSD system using tcp_bbr as I do to the Linux hosts. I = will stick with tcp_bbr for now as the default on my remote FreeBSD = servers. It appears to put them on a par with Linux for this WAN link. >>>=20 >>> Thanks for the feedback Paul. Please bear in mind that BBR 1 which = is implemented in FreeBSD is not a fair[1] congestion control algorithm. = Maybe in the future, we will have BBR v2 in the stack, but for now, I = don't recommend using BBR, unless you want to act slightly as a hm.... = network leecher. Maybe Linux hosts behave this way, maybe they have = implemented BBR v2, I am not familiar with Linux TCP stack enhancements. = On the other hand, tcp_rack(4) is performant, well-tested in the FreeBSD = stack, considered fair and more acceptable for a fileserver, though not = ideal, ie. probably more computationally expensive and still missing = some features like TCP-MD5. >>>=20 >>> [1] https://www.mdpi.com/1424-8220/21/12/4128 >>>=20 >> That is a fair and astute observation, Marek. I am also not familiar = with Linux TCP stack implementations but it had occurred to me that = maybe Linux was not being an entirely good netizen whereas FreeBSD was = behaving with impeccable net manners when it came to congestion control = and being fair to others, and that is why Linux was getting faster = speeds for me. Then again, perhaps not. :-) >> In the case of the remote FreeBSD hosts I use at $JOB, they have low = numbers of users and so are more akin to endpoints than servers, so I'm = not worried about "leeching" from them. Also, my ISP download bandwidth = is 1/5th of each FreeBSD system, so hopefully there is still plenty to = go around after I max out my bulk downloads. (Plus, I believe $JOB = prefers my downloads to take half [or less] the time.) :-) >> Hopefully we will get BBR v2 (or something even fairer) at some = point. IIRC, the FreeBSD Foundation has been highlighting some of this = network stack work. It would be a pity for it not to be enabled by = default so more people could use it on -RELEASE without building a = custom kernel. I'm just glad right now I'm not stuck with 3--4 MB/s = downloads any more. >> Cheers, >> Paul. >=20 > Word of caution: >=20 > It would appear not all FreeBSD applications like BBR or RACK. I run a = Magento (e-commerce) VM and was getting weird pauses (hang for a bit = then resume) on the website. Running Magneto requires several other TCP = services and something wasn't happy. Not going to debug the problem, = just wanted to give a heads up. Thanks for the heads-up. Since posting the above I have also noticed = that BBR and RACK aren't unalloyed successes for me. In my experience, = I would also notice pauses and lockups/disconnections to FreeBSD systems = with BBR enabled. I only noticed pauses with RACK on some systems in my = testing, so that was much more usable. The problems I experienced were worst on 13.1-RELEASE. A 13.1-RELEASE = system I built and enabled BBR on was almost unusable to me. RACK was = better but also had issues. Much better in my tests is BBR and RACK on = 13-STABLE and -CURRENT. I had no issues with RACK (other with more = speed variability vs BBR), whereas BBR did lock up one of my FreeBSD = clients in testing. (That client uses a RealTek re NIC, so maybe BBR = tickles more bugs in that.) RACK caused no lockups and yielded good = enough speeds for it to be my go-to combo now over BBR. I figure the better results with enabling BBR and RACK on -STABLE and = -CURRENT vs -RELEASE servers reflects potential improvements/bug fixes = in the implementation since -RELEASE landed. (Disclaimer: the -RELEASE = test system uses em NICs whereas the -STABLE and -CURRENT systems I used = in testing use igb NICs, so maybe that is a factor?) Cheers, Paul.