If DragonFly is going to participate in Google Summer of Code for 2013, we need project ideas, and lots of them, at any size. There’s an existing project page that anyone can add to, especially if you’re a student and looking to add your ideas.
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.
As Sepherosa Ziehau mentions in his latest commit, DragonFly now collects IFNET/IFADDR statistics on a per-CPU basis. This makes it more accurate, but may mess with any third-party program that accessed it directly. I don’t know if there’s anything in pkgsrc that does that…
I know OpenSSL in DragonFly was just updated, but Peter Avalos has done it again, bringing it to version 1.01e. I assume this new version is to fix some recently-exposed problems. He also has updated libdialog, which was previously not located in contrib/, as sime third-party software needed a more modern version. As a side effect from that, tzsetup in DragonFly now matches the version in FreeBSD and NetBSD. And, Sascha Wildner has updated the locale files on DragonFly, also to match FreeBSD and NetBSD.
If you’re near Germany, or like IPv6, the Schlund Technologies mirror for DragonFly is for you – it supports HTTP, FTP, and rsync.
The machines at dragonflybsd.org are now on a different part of the Internet, so if you were having problems connecting over the past few days, it should be better now. Matthew Dillon wrote up details of what he changed and why he changed it, including a note about future blade server plans.
Added: Peter Avalos has updated OpenSSL to version 1.0.1d – see the changelog.
Removed: support for ISA sound cards, by Sascha Wildner. Goodbye sb16; I’ll remember you fondly.
It’s announced! If DragonFly is going to participate again for the sixth year in a row (wow!), we need mentor volunteers…
Matthew Dillon is moving dragonflybsd.org’s network link to a new VPN today. (It may have already happened; I only just read the email.) This may help the people that have reported their network path to dragonflybsd.org seems to die somewhere in the Cogent network…
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.
Sepherosa Ziehau has merged the hardware abstraction layer (HAL) for em(4) and igb(4), along with updating em(4)/emx(4) to version 7.3.4 and igb(4) to version 2.3.7.
John Marino has set gcc 4.7 as the default compiler in DragonFly. This replaces the previous default of gcc 4.4. The 4.4 version is still available, and while you can set NO_GCC44 to keep it from being built, John’s commit message notes that it’s still useful especially for some ports that don’t work with gcc 4.7.
If you have git installed, and you are trying to upgrade it, you may have problems. The scmgit-docs package dependency requires some DocBook files that aren’t always accessible. If you do run into this problem, there’s 3 separate options:
- You can just install scmgit-base and ignore scmgit-docs. The program ‘git’ still runs.
- You can download the prebuilt DocBook files separately.
- You can rebuild some XML-related dependent files and then rebuild without issue.
Sepherosa Ziehau has posted a detailed message showing the speeds he gets with multiple transmission queues, using igb(4). The short version:
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)
GCC version 4.7 is already available now in DragonFly 3.2, but it’s not the default compiler. John Marino intends to make it default for the next release. What’s that mean for us? Nothing other than a new compiler, since he’s already fixing related issues.
Markus Pfeiffer reports success using Xen HVM to run DragonFly, which may be useful for any of you Xen users. He reports not being able to use more than 2 virtual CPUs, though Scott Tincman reports successfully using 4 (with qemu), so your mileage may vary.
Updated: noting qemu usage as Markus pointed out in comments.
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.
Based on this bug report on the recently updated m4, you may need to perform some extra steps to update m4 as part of a normal upgrade:
# cd /usr/src/usr.bin/m4 # make # make install clean
If you have a DragonFly 3.3 system with DPorts, can you install xorg, then ssh -Y from another machine to there, and see if you can remotely run an X program like xterm with local display? I’ve done this twice on two different machines with DPorts and it won’t work. xorg won’t write the security info to ~/.Xauthority, with ssh or xhost or whatever. It’s driving me crazy.
(Yeah, slow news day.)
Peter Avalos has updated m4 for DragonFly. This will bring us a little more in sync with the other BSDs. Also, John Marino has updated flex, which is apparently 17 years old? Meaning it hasn’t been updated in DragonFly ever, and then not in FreeBSD before that, for a long time. Looking at the timeline on the flex web page appears to match.