Category: Device support
If you’re planning to run DragonFly in KVM, remember this post from Matthew Dillon, giving the settings he uses. This will save you a bit of time.
I stole Sepherosa Ziehau’s email subject for the title of this post, because that’s exactly what has happened. Gigabit networking cards under DragonFly will perform very well under extreme load – all of them.
The Radeon KMS driver from FreeBSD has been imported to DragonFly by Francois Tigeot. It still has problems with ttm, but don’t let that stop you from taking advantage of it.
Francois Tigeot posted his work on the KMS driver for Radeon video cards. He’s looking for help since he’s low on time for the immediate future, and this is a project that could benefit everyone. (Well, everyone with the right video card.)
I’m just going to roll all these updates from Sepherosa Ziehau together into one post, because it’s a lot: He’s updated igb(4) to 2.3.10, updated em(4) to 7.3.8, merged the hardware abstraction layer of those two drivers, enabled TSO on all PCI-E em(4) chipsets, and added support for a whole slew of Realtek chipsets in the re(4) driver. Whew!
If you’ve got a MCP79 NVIDA-chipset board, Sascha Wildner’s commit of Ed Berger’s port from OpenBSD has you covered.
If you’re curious about the hardware being used for the colocated dragonflybsd.org servers (this includes the website, the repository, the mailing lists, dports build machines, etc.), here’s the ‘MicroCloud’ product page. DragonFly’s model was purchased from iXsystems. Apparently those Haswell processors have a fantastic power consumption to performance ratio. (via)
I’d be really surprised to find this affects anyone, but it’s possible: some kernel options specific to Cyrix processors have been removed, by Sascha Wildner.
If you have a computer with one of the very-very-new Haswell processors from Intel, Matthew Dillon has made some changes that will interest you. They shave off (in the example given) about 20% of CPU power usage without much effect on performance.
Thanks to the effort of a number of people, DragonFly (-current) now supports KMS and accelerated video on Intel 915 chipsets. It’s 2D and x86_64 only for now, but it’s much, much better than just using the vesa driver.
Thanks to the efforts of a large number of people, KMS support is showing up in DragonFly. This supports accelerated video on the new Intel graphics chipsets that seem to show up on many recent laptops.
From the man page: “The tpm driver provides support for various trusted platform modules (TPM) that can store cryptographic keys.” Crypto keys stored in hardware, where they are in theory unmangleable, instead of on the disk. At least, that’s my impression after 30 seconds of research.
John Marino brought up a point every operating system project will have to think about: when does support for i386 (i.e. 32-bit x86 processors) stop? Follow the thread for details. There’s no final answer, yet.
If you have a mfi(4) device – in other words, a LSI MegaRAID SAS driver – you can now see/import/clear/etc. foreign configurations, thanks to this commit from Sascha Wildner, tested by Francois Tigeot, and originally from FreeBSD.
For the confused, ‘foreign’ means any disk hooked to a RAID controller that isn’t part of a configuration the RAID device already knows about. A replacement disk, or more worryingly, a good disk gone bad/unrecognizable. (I’ve had both.)
If you have an ath(4), wpi(4) or iwi(4) wireless network link, and you’re running DragonFly-master, please update. Sepherosa Ziehau has pushed Johannes Hoffman’s wlan_serialize branch, which means bringing up wlan0 is a bit easier – and less crashy.
It needs to be tested for wpi(4) and iwi(4), however, so if you have success or failure with those devices, please say so in reply.
(new post category starting now: “Please test”)
It seems Sepherosa Ziehau won’t rest until he’s reached peak performance for every network card in DragonFly; he’s added multiple ring/MSI-X support for Broadcom 5709/5716 chipsets in DragonFly. In more concrete terms, this means better speeds when transmitting and receiving multiple streams of data.
(at least, I think so.)
Sepherosa Ziehau has posted more statistics on his ifnet/ifaddr per-CPU stats work. It’s doing so well that he’s very close to reaching the maximum physical capacity of the 4x gigabit ethernet hardware he’s using.
The emx(4) driver now has support for multiple TX queues, but it’s not on by default. There’s scenarios where multiple queues work out with that hardware, but you have to be sure you are actually in the right setup for that first. Check Sepherosa Ziehau’s commit message for the details.
Quick summary, the multiple TX queue support gives me: +200Kpps for 2 bidirectional normal IP forwarding (now 4.40Mpps) +160Kpps for 2 bidirectional fast IP forwarding (now 5.23Mpps)
Will Backman has a new BSDTalk episode up, with a bit of Peter Salus from BSDCan 2011 and a bit of Raspberry Pi on FreeBSD.
We need more fiddling-with-BSD-on-hardware stuff out there. That would be a good thing for Youtube – hint, hint.
Sepherosa Ziehau makes commits almost daily to DragonFly’s network infrastructure, but I have a hard time quantifying it into Digest posts in part because it’s often very technical. His most recent commits come with an explanation, however. He has done plenty of work to improve overall transmission speeds in DragonFly, and now he’s working on ‘fairness’. Fair, in this case, means ensuring that packet transmitting and receiving happen without either one monopolizing the connection. In real world terms, this translates to much more constant speeds. His recent commit details what he’s doing and some numbers to prove it.
Remember I said he’s improved speeds? Note that in his example, he’s reaching stable peaks of 981 Mbps. This is on a line that I assume theoretically maxes out at 1000.
I’m not sure what IFQ stands for, but Sepherosa Ziehau’s added it. It appears to be based on an idea from Luigi Rizzo called ‘netmap‘. In this case, network packets are grouped together before being placed onto the network interface’s hardware queue. That means better packet per second performance without a corresponding increase in CPU usage, as Sepherosa Ziehau’s report lists, along with needed sysctls.
Sepherosa Ziehau has been making a lot of commits to increase packet-per-second rates without increasing CPU usage. He’s published a sort of progress report/benchmark to show current performance levels. It sounds like he’s expecting even better performance in the future, though I’m not sure how much more he could push out of it, since the bulk performance appears to be close to the rated capacity of the copper…
Sascha Wildner has added system management BIOS (SMBIOS) support, visible with kenv, from FreeBSD. Use it for getting things like the BIOS revision, system manufacturer, and so on. For example:
smbios.bios.reldate="12/04/2006" smbios.bios.vendor="Dell Inc. " smbios.bios.version="2.1.0 "
This may seem minor, but this can be very helpful when dealing with hardware you aren’t physically able to access.
Sepherosa Ziehau is switching a number of network cards over to use ifpoll, which means they will have capabilities similar to MSI-X, even if the network card doesn’t support it. My suspicion is that it will make these cards perform better in busy situation where they would otherwise get bogged down… but that’s based on hunch rather than empirical testing. As Sepherosa Ziehau pointed out, it certainly can’t hurt.
Sascha Wildner has committed Markus Pfeiffer’s port of USB4BSD to DragonFly. USB network, input , audio, and storage devices (including xhci/USB3 items) may work, though there’s no guarantee for each driver. This is added but not on by default, so see the first link for instructions on how to rebuild your kernel to use it. This will be in (but not default) the DragonFly 3.2 release.
(This is shaping up to be a much bigger release than I anticipated!)
Much of this new document has been around in other forms for a while, but now, there’s a brief guide on porting drivers to DragonFly in the source tree.
I noticed that this recent commit from Sepherosa Ziehau is a bug fix for jme(4). The commit thanks a JMicron employee for help. It’s always appreciated when a vendor is helpful to an open-source project for hardware support. It’s also something you should consider the next time you are shopping for computer parts.
Pierre Abbat is curious about using Hammer on an SSD. The discussion that came from that has some useful points, including notes that a straightforward SSD as disk works for most anything with Hammer other than very intensive database use, due to the history retention. If space is an issue, swapcache on the SSD and attaching a normal HDD is a fine alternative. A SSD with Hammer can leave some features off, though I’d argue that dedup is totally worth is. Also, SSD speed is directly correlated with size.
Sepherosa Ziehau’s added TSO support (that’s TCP Segmentation Offloading”, or “Large Segment Offload” going by Wikipedia) within IPv4 on DragonFly, pushing segmentation work from the CPU to the network card. There’s also some DragonFly-specific improvements.
There’s been a lot of commits from him lately focused around network card improvements; they haven’t been easily summarizable, but it’s worth watching if you are interested in high-bandwidth usage and the hardware to support it.
Not all flavors of Atom CPU support frequency scaling, as Sven Gaerner found out. This means more heat and more power usage. There’s further details scattered through the thread, but Sascha Wildner found what seems to be the definitive answer of which variants do and do not.
Someone trying DragonFly couldn’t get it to start, and appeared to have a confused disk. It looks like the system BIOS were at fault, and Matt Dillon has an explanation of this minefield. (Including some comments on 4k physical disk sectors.)
New company Gainframe is offering up OpenBSD dmesg/pcidump/usbdevs output for every system they build. I was originally going to link to this in a Lazy Reading entry, but then I realized it’s also a new company specializing in BSD-compatible hardware. Read the interview; I met Michael Dexter at the last NYCBSDCon and he is a decent guy.
We need more of this sort of specifically targeted work. Sites that rely on crowd-sourced contribution are good, but it’s not necessarily comprehensive, and you need a very large crowd for it to work.