Udgiv indhold
Planet OpenSource DK -
Opdateret: 36 minutter 11 sekunder siden

Erwin Lansing: FreeBSD Developer Summit – BSDCan 2014 – Ports and Packages WG

juli 16, 2014 - 11:16

Baptiste Daroussin started the session with a status update on package building. All packages are now built with poudriere. The FreeBSD Foundation sponsored some large machines on which it takes around 16 hours to build a full tree. Each Wednesday at 01:00UTC the tree is snapshot and an incremental build is started for all supported released, the 2 stable branches (9 and 10) and quarterly branches for 9.x-RELEASE and 10.x-RELEASE. The catalogue is signed on a dedicated signing machine before upload. Packages can be downloaded from 4 mirrors (us-west, us-east, UK, and Russia) and feedback so far has been very positive.

He went on to note that ports people need better coordination with src people on ABI breakage. We currently only support i386 and amd64, with future plans for ARM and a MIPS variant. Distfiles are not currently mirrored (since fixed), and while it has seen no progress, it’s still a good idea to build a pkg of the ports tree itself.

pkg 1.3 will include a new solver, which will help 'pkg upgrade' understand that an old packages needs to be replaced with a newer one, with no more need for 'pkg set' and other chicanery. Cross building ports has been added to the ports tree, but is waiting for pkg-1.3. All the dangerous operations in pkg have now been sandboxed as well.

EOL for pkg_tools has been set for September 1st. An errata notice has gone out that adds a default pkg.conf and keys to all supported branches, and nagging delays have been added to ports.

Quarterly branches based on 3 month support cycle has been started on an evaluation basis. We’re still unsure about the manpower needed to maintain those. Every quarter a snapshot of the tree is created and only security fixed, build and runtime fixed, and upgrades to pkg are allowed to be committed to it. Using the MFH tag in a commit message will automatically send an approval request to portmgr and an mfh script on Tools/ makes it easy to do the merge.

Experience so far has been good, some minor issues to the insufficient testing. MFHs should only contain the above mentioned fixes; cleanups and other improvements should be done in separate commits only to HEAD. A policy needs to be written and announced about this. Do we want to automatically merge VuXML commits, or just remove VuXML from the branch and only use the one in HEAD?

A large number of new infrastructure changes have been introduces over the past few months, some of which require a huge migration of all ports. To speed these changes up, a new policy was set to allow some specific fixes to be committed without maintainer approval. Experience so far has been good, things actually are being fixed faster than before and not many maintainers have complained. There was agreement that the list of fixes allowed to be committed without explicit approval should be a specific whitelist published by portmgr, and not made too broad in scope.

Erwin Lansing quickly measured the temperature of the room on changing the default protocol for fetching distils from MASTER_SITE_BACKUP from ftp to http. Agreement all around and erwin committed the change.

Ben Kaduk gave an introduction and update on MIT’s Athena Environment with some food for thought. While currently not FreeBSD based, he would like to see it become so. Based on debian/ubuntu and rolled out on hundreds of machines, it now has it’s software split into about 150 different packages and metapackages.

Dag-Erling Smørgrav discussed changes to how dependencies are handled, especially splitting dependencies that are needed at install time (or staging time) and those needed at run time. This may break several things, but pkg-1.3 will come with better dependency tracking solving part of the problem.

Ed Maste presented the idea of “package transparency”, loosely based on Google’s Certificate Transparency. By logging certificate issuance to a log server, which can be publicly checked, domain owners can search for certificates issued for their domains, and notice when a certificate is issued without their authority. Can this model be extended to packages? Mostly useful for individually signed packages, while we currently only sign the catalogue. Can we do this with the current infrastructure?

Stacy Son gave an update on Qemu user mode, which is now working with Qemu 2.0.0. Both static and dynamic binaries are supported, though only a handful of system call are supported.

Baptiste introduced the idea of having pre-/post-install scripts be a library of services, like Casper, for common actions. This reduces the ability of maintainers to perform arbitrary actions and can be sandboxed easily. This would be a huge security improvement and could also enhance performance.

Cross building is coming along quite well and most of the tree should be able to be build by a simple 'make package'. Major blockers include perl and python.

Bryan Drewery talked about a design for a PortsCI system. The idea is that committer easily can schedule a build, be it an exp-run, reference, QAT, or other, either via a web interface or something similar to a pull request, which can fire off a build.

Steve Wills talked about using Jenkins for ports. The current system polls SVN for commits and batches several changes together for a build. It uses 8 bhyve VMs instances, but is slow. Sean Bruno commented that there are several package building clusters right now, can they be unified? Also how much hardware would be needed to speed up Jenkins? We could duse Jenkins as a fronted for the system Bryan just talked about. Also, it should be able to integrate with phabricator.

Erwin opened up the floor to talk about freebsd-version(1) once more. It was introduced as a mechanism to find out the version of user land currently running as uname -r only represents the kernel version, and would thus miss updates of the base system that do no touch the kernel. Unfortunately, freebsd-version(1) cannot really be used like this in all cases, it may work for freebsd-update, but not in general. No real solution was found this time either.

The session ended with a discussion about packaging the base system. It’s a target for FreeBSD 11, but lots of questions are still to be answered. What granularity to use? What should be packages into how many packages? How to handle options? Where do we put the metadata for this? How do upgrades work? How to replace shared libraries in multiuser mode? This part also included the quote of the day: “Our buildsystem is not a paragon of configurability, but a bunch of hacks that annoyed people the most.”

Thanks to all who participated in the working group, and thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the Ports and Packages WG meet up at EuroBSDCon in Sofia in September.

Related posts:

  1. FreeBSD Developer Summit – BSDCan 2014 – DNS WG The DNS Working Group at the FreeBSD Developer Summit at...
  2. Ports and Packages Summit at EuroBSDCon 2013 The FreeBSD project has provided pre-built ready-to-install binary packages for...
  3. Vendor Summit at EuroBSDCon 2013 For the third year in a row, we’ll be organizing...

YARPP powered by AdBistroPowered by

Erwin Lansing: FreeBSD Developer Summit – BSDCan 2014 – DNS WG

juli 16, 2014 - 10:19

The DNS Working Group at the FreeBSD Developer Summit at BSDCan this year was off to a good start by noticing that DNSSEC validation could not work on the University of Ottawa’s wireless network. The university’s resolvers added additional records to the root zone, thus failing validation at the root. This led to some discussion on how to provide a user-friendly way to explain this in an understandable way to the user and giver the user a choice of turning off validation or find another network. This certainly is going to be a major problem when turning on validation by default as broken resolvers are very common at hotels, coffee shops, etc. etc.

On a more positive note, all the FreeBSD projects zones are DNSSEC signed and all project-owned servers have SSHFP records in the zone. Dog food was eaten.

Dag-Erling Smørgrav started off by giving an overview of the current state of affairs. ldns and unbound are imported into base in HEAD and 10.x. unbound is meant to act as a local resolver only and as it is not linked to libevent, it will not scale to anything else. For a network-wide resolver or any other configuration, it is recommended to install unbound from ports. DES further went into some of the implementation details on how the base unbound is installed to make sure it does not conflict with an unbound installed from ports.

DES explained some issues he encountered with local and RFC1918 zones which are filtered by default by unbound. Others reported no issues with the right configuration options, so more investigation is needed.

Some people reported having difficulty getting patches accepted upstream by NLNetLabs, which gave some cause for concern as we clearly want a good and active working relationship with our DNS vendor. Others reported no problem working with NLNetLabs, quite the opposite, they are very interested to see the work going on in operation systems, so we’ll just need to build upon that relationship and make sure to invite them to the next WG meeting. Patches that are currently being worked on, DES has some code cleanups, Björn a DNS64 feature, should be submitted through the “normal” submission process and review with NLNetLabs and we’ll see how that goes.

Erwin Lansing started the brainstorm session on future work. Some command line tools would be nice to have; drill does most things one wants, but people are too used to writing dig and dig has many more options; Peter Wemm would like to see contrib scripts line ldns-dane, which are just really easy to use; the control socket should be a unix socket, there’s a patch floating around and should be submitted upstream.

The “Starbucks” problem came up again, with a proposal to turn on val-permissive-mode by default. Another solution may be by looking at how unbound-trigger does its magic.

After a coffee break, Peter Losher, ISC, went over some of the recent changes at ISC. BIND10 development has been handed over to a new project and ISC will concentrate on BIND9 and a stand-alone project for the DHCP component. BIND 9.10 was recently released and plans are in place for 9.11. ISC is open to suggestions and feature requests.

Peter brought up the topic of clientID for which a IETF draft (draft-edns0-client-subnet) is available. This would help client find the nearest CDN node, etc. ISC wants this to be an opt-out in operating systems as it will peel off a layer of anonymisation, and should be controllable by the user.

Next up was Michael Bentkofsky, Verisign, who, while not involved in the project himself, gave an introduction into the getDNS API, which is a replacement for getaddrinfo and allows the stub resolver to get validation information down at the client level. It’s available in ports. The discussion went into more of a brainstorm on how applications should get DNS and DNSSEC information and who gets to make decisions about its security. There should be a clear separation between policy and mechanism, where application programmers should not have to worry about this; it should be a system policy. There should be a higher level API where an application basically can ask the operating system for a “connection” and the operation system takes care of everything behind the scenes, DNS, DNSSEC, SSL, DANE, etc. and just return a socket, with some information on how the connection was established and which security mechanisms were used. In FreeBSD, it would make sense to let the Casper daemon hand out the different sub-tasks to ensure all lookups, cryptography, etc. are properly compartmentalised. One potential problem with passing on additional information is that all DNS lookups currently go through nsswitch, which would need to grow knowledge about that data as well. Are people still using other mechanisms for hostname lookups besides the hosts file and DNS? We can probably just remove nsswitch for the hostname lookups.

The session ended with some aims for the 11.0 release. We’ll need to have a wider discussion about the aforementioned removal of nsswitch out of the hostname lookups. We’ll also need a better understanding of what API capabilities applications may need. Can Casper provide all these? Can it run unbound behind the scenes to do all the DNS “stuff” for it? Can we capsicumize unbound and will that be accepted upstream? Enough food for thought and even more for writing code.

Thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the DNS WG meet up at EuroBSDCon in Sofia in September.

Related posts:

  1. Ports and Packages Summit at EuroBSDCon 2013 The FreeBSD project has provided pre-built ready-to-install binary packages for...
  2. Vendor Summit at EuroBSDCon 2013 For the third year in a row, we’ll be organizing...

YARPP powered by AdBistroPowered by

Klavs Klavsen: Elasticsearch graphs

juli 16, 2014 - 09:35

After having worked with Elasticsearch and thrown quite a lot of data at it (we add about 100 million documents a day), I have built a very nice set of graphs, that helps me visualize problems and activity in the cluster, and figured I'd share them to hopefully give some inspiration :)

p.s. the jvm_heap_usage graphs - the two lines which are very jumpy, are the ones I switched to using G1 Garbage Collector, which does seem to be of help when you're running close to your heap limit :) 

p.s. view image alone, to see it in full size.

read more

Søren Bredlund Caspersen: Datafællesskabet

juli 15, 2014 - 13:52

For tre uger side, tirsdag d. 24. juni, afholdtes stiftende generalforsamling i

Foreningens formål er ifølge vedtægterne:

Foreningen ønsker at stille digital infrastruktur til rådighed for sine medlemmer, på en måde hvor foreningens kerneprincipper — privatlivsbeskyttelse, kryptering, decentralisering og zero-knowledge for foreningen som tjenesteudbyder — er i fokus. Ydermere vil foreningen advokere for sine kerneprincipper, hjælpe folk til at at agere på nettet på forsvarlig vis, samt samarbejde med andre datafællesskaber/hjælpe andre i gang med lign. foreninger.

Motivationen for stiftelse af foreningens formuleres nok bedst af Mikkel her:

Efter en længere process på den stiftende generalforsamling med småændringer til et sæt standardvedtægter blev disse endelig godkendt, og der blev valgt en bestyrelse (og yours truly fik tilranet sig en plads).



…hvad så nu?

Lige nu er der vist gået sommer(ferie) i den.

Men på et tidspunkt skal der selvfølgelig gang i det praktiske datafællesskab. Første trin er vist en fornuftig e-mail løsning. Hvad der derefter komme af data-hosting, Dropbox alternativ eller lignende må tiden vise.
Hvilke konkret tekniske løsninger der skal benyttes, hvor data skal hostes osv. vil jeg slet ikke forholde mig til, men det er min oplevelse at der er blevet tænkt en del over dette af folk med mere teknisk indsigt end jeg.

Bestyrelsen skal nok også afholde et møde, forholde sig til eventuel økonomi og lignende.

Der bør nok også oprettes en hjemmeside, med mere udførlig kontakt-info, mail-lister osv. Det arbejde er vist også så småt sat i gang.

Hvis du har lyst til at være med er det letteste nok at holde øje med hjemmesiden, hvor der sikkert dukker yderligere info op i den nærmeste fremtid. Alternativt kan du forsøge at at kontakte (medlemmer af) bestyrelsen.

Image by: Bob Mical

Sune Vuorela: CMake and library properties

juli 9, 2014 - 08:30

When writing libraries with CMake, you need to set a couple of properties, especially the VERSION and SOVERSION properties. For library libbar, it could look like:

set_property(TARGET bar PROPERTY VERSION “0.0.0″)
set_property(TARGET bar PROPERTY SOVERSION 0 )

This will give you a => => symlink chain with a SONAME of encoded into the library.

The SOVERSION target property controls the number in the middle part of the symlink chain as well as the numeric part of the SONAME encoded into the library. The VERSION target property controls the last part of the last element of the symlink chain

This also means that the first part of VERSION should match what you put in SOVERSION to avoid surprises for others and for the future you.

Both these properties control “Technical parts” and should be looked at from a technical perspective. They should not be used for the ‘version of the software’, but purely for the technical versioning of the library.

In the kdeexamples git repository, it is handled like this:


And a bit later:

set_target_properties(bar PROPERTIES VERSION ${BAR_VERSION}

which is a fine way to ensure that things actually matches.

Oh. And these components is not something that should be inherited from other external projects.

So people, please be careful to use these correct.

Poul-Henning Kamp: Og jeg gentager:

juli 3, 2014 - 12:27
Nej, jeg er faktisk så træt af at gentage mig selv at jeg ikke gør det. Kan I ikke bare finde nogen af mine tidligere brok om IT havarikommission og om hvorfor mainframe-miljøer er en sikkerhedstrussel i arkivet ? Og ja, jeg synes det er i særklasse ironisk at det er netop de borgere der har gj...

Peter Toft: Næsten snydt af email-scam... Er du blevet snydt?

juli 2, 2014 - 20:55
Jeg modtager - sikkert ligesom jer - et hav af emails, der prøver at franarre mig penge. I dag fik jeg en, jeg var "tættere" på at tro på. Personen - vi kan kalde ham Kim - er en bekendt, som sagtens kunne tænkes at være den rigtige afsender. I dette tilfælde kontaktede jeg personen, som kunne b...

Jesper Dangaard Brouer: The calculations: 10Gbit/s wirespeed

juli 2, 2014 - 12:18
In this blogpost, I'll try to make you understand the engineering challenge behind processing 10Gbit/s wirespeed, at the smallest Ethernet packet size.

The peak packet rate is 14.88 Mpps (million packets per sec) uni-directional on 10Gbit/s with the smallest frame size.

Details: What is the smalles Ethernet frame
Ethernet frame overhead:

Thus, the minimim size Ethernet frame is: 84 bytes (20 + 64)

Max 1500 bytes MTU Ethernetframe size is: 1538 bytes (calc: (12+8) + (14) + 1500 + (4) = 1538 bytes)

Packet rate calculations

Peak packet rate calculated as:  (10*10^9) bits/sec / (84 bytes * 8) = 14,880,952 pps
1500 MTU packet rate calculated as: (10*10^9) bits/sec / (1538 bytes * 8) = 812,744 pps

Time budget
This is the important part to wrap-your-head around.

With 14.88 Mpps the time budget for processing a single packet is:

  • 67.2 ns (nanosecond) (calc as: 1/14880952*10^9 ns)

This corrospond to approx: 201 CPU cycles on a 3GHz CPU (assuming only one instruction per cycle, disregarding superscalar/pipelined CPUs). Only having 201 clock-cycles processing time per packet is very little.

Relate these numbers to something
This 67.2ns number is hard to use for anything, if we cannot relate this to some other time measurements.

A single cache-miss takes: 32 ns (measured on a E5-2650 CPU). Thus, with just two cache-misses (2x32=64ns), almost the total 67.2 ns budget is gone. The Linux skb (sk_buff) is 4 cache-lines (on 64-bit), and the kernel e.g. insists on writing zeros to these cache-lines, during allocation of an skb.

We might not "suffer" a full cache-miss, sometimes the memory is available in L2 or L3 cache.  Thus, it is useful to know these time measurements.  Measured on my E5-2630 CPU (with lmbench command "lat_mem_rd 1024 128"), L2 access costs 4.3ns, and L3 access costs 7.9ns.

The "LOCK" operation
Assembler instructions can be prefixed with a "LOCK" operation, which means that they perform an atomic operation. This is uses every time e.g. a spinlock is locked or unlocked, cmpxchg and atomic_inc (some operations are even implicitly LOCK prefixed, like xchg).

I've measured the cost of this atomic "LOCK" operation to be 8.25ns on my CPU (with this program). Even for the completely optimal situation of a spinlock only being touch by one CPU, we have two LOCK calls which costs 16.5ns.

System call overhead
A FreeBSD case study of sendto(), in Luigi Rizzo netmap paper, shows that the cost of only the system call is 96ns, which is above the 67.2 ns budget.  The total overhead of sendto() were 950 ns.  These 950ns corrospond to 1,052,631 pps (calc as 1/(950/10^9)).
On Linux I measured the system call getuid(2), to take 87.77 ns and 201 CPU-cycles (TSC measurement) (the CPU efficiency were 1.42 insns per cycle, measured with perf stat). Thus, the syscall itself eats up the entire budget.

  • Update: Most of the syscall overhead comes from kernel option CONFIG_AUDITSYSCALL, without it, the syscall overhead drops to 41.85 ns.

How to overcome this syscall problem?  We can amortize the cost, by sending several packets in a single syscall.  It is not very well known, but we actually already have a syscall to send several packets with a single syscall, called "sendmmsg(2)". Notice the extra "m" (and the corresponding receive version "recvmmsg(2)"). Not many examples exists on the Internet for using these syscalls. Thus, I've provided some example code here for sendmmsg and recvmmsg.

RAW socket speeds
Daniel Borkmann and I recently optimized AF_PACKET, to scale to several CPUs (trafgen, kernel qdisc bypass and trafgen use qdisc bypass). But let us look at the performance numbers for only a single CPU:

  • Qdisc path = 1,226,776 pps => 815 ns per packet (calc: 1/pps*10^9)
  • Qdisc bypass = 1,382,075 pps => 723 ns per packet (calc: 1/pps*10^9)

This is also interesting, because this show us the cost of the qdisc code path, which costs 92 ns.  In this 10Gbit/s context it is fairly large, e.g. corresponding to almost 3 cache-line misses (92/32=2.9).

Poul-Henning Kamp: Gettys principper

juli 2, 2014 - 10:18
Jeg sider og prøver at stoppe noget sund fornuft ind i HTTP/2.0 standardiseringsprocessen. Det er hårdt arbejde som ville være nemmere hvis flere mennesker kendte og respekterede "Gettys Regler" For rigtig mange år siden formulerede Jim Gettys nogle grundprincipper for X11 udviklingen, som desv...

Martin Schlander: Jolla and KDE Connect

juni 29, 2014 - 18:08
KDE Connect

KDE Connect is a piece of software that integrates your KDE desktop with Android devices. It enables you to share the clipboard, share files, use your Android device as a mousepad or remote control for MPRIS enabled media players on your desktop, have a battery indicator for your Android device on your desktop and more. Even more features are planned. All this is done over wifi.


Jolla is of course the coolest smartphone on the market, it runs SailfishOS, but it comes with an Android runtime (Alien Dalvik) which lets you run most Android apps perfectly fine on the Jolla.

KDE Connect on the Jolla

So I had to see if KDE Connect would work with the Jolla, and at least some of the main features work perfectly. I can now use my Jolla as a wireless mousepad for my KDE desktops, and I can use my Jolla as a remote control for e.g. Amarok. I can also work with the filesystem in the Dolphin file manager, but only the Android runtime folders of the Jolla filesystem are exposed to KDE this way.

Quite a few of the features don’t seem to work – notifications, battery indicator, sending files via the Dolphin context menu (right click) and clipboard sharing.

How to set it up

1) Install KDE Connect on your desktop (on openSUSE install the package ‘kdeconnect-kde’ from the KDE:Extra repository. Also install ‘sshfs’ if you want to be able to mount the Android folders on the Jolla in Dolphin.

2) Install KDE Connect on your Jolla (personally I installed the binaries from the F-Droid app store, but binaries are also available in Google Play and 1MobileMarket).

3) Connect your Jolla to the wifi of the same network as your desktop computer and make sure you don’t have a firewall running (or allow traffic for the range of ports 1714-1764 for both TCP and UDP).

4) Launch the KDE Connect app on the Jolla and go to KDE ‘systemsettings’ -> KDE Connect and pair your phone with the desktop.

Poul-Henning Kamp: Historiske IT success/katastrofer

juni 27, 2014 - 09:07
Der existerer en konference for historisk IT i de nordiske lande, "HiNC" og den når til Danmark d. 13-15 august. Det er ret fantastisk hvor vidt omkring programmet kommer, fra megasuccessen CPR over "APL i de nordiske lande" til gigantfiaskoen EPJ. Jeg er godt klar over at det ikke er alle der ...

Peter Toft: Python profilering efter hukommelsesforbrug?

juni 26, 2014 - 00:27
Jeg holder meget af at programmere i Python. Det er klart det bedste programmeringssprog, jeg har arbejdet med. Det er to ting jeg jævnligt har brug for - at finde ud af hvor i min kode, jeg bruger mest CPU-kraft hhv. mest hukommelse. Til C/C++ kode har jeg meget godt styr på det men til Python k...

Poul-Henning Kamp: En fyr med en god tidsmaskine...

juni 25, 2014 - 10:54
...afslører hvordan Keynote foredraget lyder til Perl konferencen 2034. Fremtiden er ikke hvad vi blev lovet. Det relevante spørgsmål er ikke "tidsmaskine ?" eller "Perl konferencen 2034 ?!" men "Er det den verden vi vil leve i?" Charles Stross styrke som "near-term" science fiction forfatter...

Peter Rude: Omvendt betalingspligt

juni 13, 2014 - 08:28

Vores regering arbejder hård for at lette de administrative byrder, påstår de.

Men virkeligheden er en ganske anden.

Momslovens regler om omvendt betalingspligt kan kun opfattes som ren chikane.

Nedenstående er sakset fra

Døm selv…

Kenneth Geisshirt: Emacsforum 2011

juni 11, 2014 - 21:06
Emacsforum 2011
Peter Toft and I are in the process of preparing Emacsforum 2011 with some help by Troels Henriksen (at DIKU) and Keld Simonsen (from KLID). The program is almost ready for publication, so I will not say too much - but there will be something for scientists and developers. Even our Evil Twin will be represented.

The mini-conference takes place 12th November 2011 at DIKU. The is no conference fee - and there will be no benifits.

If you are using Emacs (and even XEmacs) and live in the Copenhagen area, Emacsforum is a good place to meet fellow users.

Poul-Henning Kamp: Dronningens Trojanske Cybergarde

juni 11, 2014 - 10:35
Alt tyder på at Folketinget vedtager den Forsvarets nye ceremonielle cybergarde idag. Lovforslag L.192 indeholder i bund og grund hjemmel til at stille en soldat på parade ved alle offentlige IT-systemers firewalls hvor han kan stå og se om nogen turister prøver at komme forbi. Den absolut mest...

Peter Rude: Flere i arbejde.

juni 8, 2014 - 20:13

Vi har stadig mange uden arbejde. Det kan vi gøre noget ved.

1. Fjern momsen på ydelser. Det mistede provenu vil vil komme igen i form af besparelser på overførselsindkomst og øgede skatteindtægter. Flere i arbejde og bedre betalingsbalance.

2. Erstat ejendomsværdiskatten af fast ejendom med skat af fortjenesten ved ejendomshandel – fratrukket dokumenterede udgifter til forbedringer og vedligehold. Så bliver værditilvækst skabt af sort arbejde beskattet = mere hvidt og mindre sort.

3. Hæv reparationsgrænsen for totalskade af motorkøretøjer fra de nuværende 75% til 100% af værdien. Det vil give arbejde til rigtigt mange pladesmede og mindre import af nye køretøjer. Flere i arbejde, bedre betalingsbalance og mindre miljøbelastning.

4. Erstat licensbaseret software i den offentlige sektor med fri software og brug den årlige besparelse på mere end 3 mia. til at forbedre denne software. Flere i arbejde, højere vidensniveau, bedre betalingsbalance og højere national sikkerhed.

Find selv på flere – det er ikke så svært.

Poul-Henning Kamp: Behovet for fundering...

juni 5, 2014 - 10:14
Idag er Grundlovsdag og politikere kværner løs med floskler osv. Grundloven hedder sådan fordi de er fundamentet under vores civilization, i bund og grund er den det eneste der forhindrer mig i at myrde folk jeg ikke er enig med, resten af lovene er bare detaljelovgivning der skal give Grundlove...

Jesper Dangaard Brouer: Pktgen for network overload testing

juni 4, 2014 - 19:38
Want to get maximum performance out of the kernel level packet generator (pktgen)?
Then read this blogpost:

  • Simple tuning will increase performance from 4Mpps to 5.5Mpps (per CPU)

You might see pktgen as a fast packet generator, which it is, but I (as a kernel developer) also see it as network stack testing tool of the TX code path.

Pktgen have a parameter "clone_skb", which specifies how many time to send the same packet, before freeing and allocting a new packet for transmission.  This affects performance significantly, as it can remove a lot of memory allocation and access overhead.

I have two distinctly different use-cases for stack testing:

  1. clone_skb=1      tests the stack alloc/free overhead (related to the SKB)
  2. clone_skb=100000 tests the NIC driver layer
Lets focus on case 2, driver layer.

Tuning NIC driver layer for max performance:The default NIC setting are not tuned for pktgen's artificial overload type of benchmarking, as this could hurt the normal use-case.
Specifically increasing the TX ring buffer in the NIC: # ethtool -G ethX tx 1024
A larger TX ring can improve pktgen's performance, while it can hurt in the general case, 1) because the TX ring buffer might get larger than the CPUs L1/L2 cache, 2) because it allow more queueing in the NIC HW layer (which is bad for bufferbloat).
One should be careful to conclude, that packets/descriptors in the HW TX ring cause delay.  Drivers usually delay cleaning up the ring-buffers (for various performance reasons), thus packets stalling the TX ring, might just be waiting for cleanup.
This "slow" cleanup issues is specifically the case, for the driver ixgbe (Intel 82599 chip).  This driver (ixgbe) combine TX+RX ring cleanups, and the cleanup interval is affected by the ethtool --coalesce setting of parameter "rx-usecs".
For ixgbe use e.g "30" resulting in approx 33K interrupts/sec (1/30*10^6): # ethtool -C ethX rx-usecs 30
Performance data:Packet Per Sec (pps) performance tests using a single pktgen CPU thread, CPU E5-2630, 10Gbit/s driver ixgbe. (using net-next development kernel v3.15-rc1-2680-g6623b41)
Adjusting the "ethtool -C ethX rx-usecs" value affect how often we cleanup the ring.  Keeping the default TX ring size at 512, and adjusting "rx-usecs":
  • 3,935,002 pps - rx-usecs:  1 (irqs:  9346)
  • 5,132,350 pps - rx-usecs: 10 (irqs: 99157)
  • 5,375,111 pps - rx-usecs: 20 (irqs: 50154)
  • 5,454,050 pps - rx-usecs: 30 (irqs: 33872)
  • 5,496,320 pps - rx-usecs: 40 (irqs: 26197)
  • 5,502,510 pps - rx-usecs: 50 (irqs: 21527)
Performance when adjusting the TX ring buffer size. Keeping "rx-usecs==1" (default) while adjusting TX ring size (ethtool -G):
  • 3,935,002 pps - tx-size:  512
  • 5,354,401 pps - tx-size:  768
  • 5,356,847 pps - tx-size: 1024
  • 5,327,595 pps - tx-size: 1536
  • 5,356,779 pps - tx-size: 2048
  • 5,353,438 pps - tx-size: 4096
The performance of adjusting cleanup interval (rx-usecs), seems to win over simply increasing the TX ring buffer size. This also proves the theory of TX queue is filled with old packets/descriptors that needs cleaning.(Edit: updated numbers to be clean upstream, previously included some patches)

Tools: Want easy to use script for pktgen look here
More details on pktgen advanced topics by Daniel Turull.

Sune Vuorela: Bringing KDE forward

juni 3, 2014 - 22:31

The almost-yearly large KDE-sprint in Randa, Switzerland is doing a fundraiser to get this year’s event running. See

This year, it is besides the recurring multimedia topics, a lot about improving the new KDE Frameworks, the related documentation and the development experience with IDE’s and such.

It is also a good way to come full circle, since it was back in 2011 when I was at the Randa Meetings that the KDE Frameworks initiative was started.

So once again: