Ubuntu File System Benchmarking

Image

 

I’ve been working to implement file system benchmarking as part of the test process that the kernel team applies to every kernel update. These are intended to help us spot performance issues. The following announcement I just sent to the Ubuntu kernel mailing list covers the specifics:

[EDIT] Fixed tags to enable the copied email text to flow.

——————————————————————————————

The Ubuntu kernel team has implemented the first of what we hope will be
a growing set of benchmarks which are run against Ubuntu kernel
releases. The first two benchmarks to be included are iozone file system
tests, with and without fsync enabled. These are being run as part of
the testing applied to all kernel releases.

== Disclaimers ==

READ THESE CAREFULLY

1. These benchmarks are not intended to indicate any performance metrics
in any real world or end user situations. They are intended to expose
possible performance differences between releases, and not to reflect
any particular use case.

2. Fixes for file system bugs reduce performance in some cases.
Performance decreases between releases may be a side effect of fixing
bugs, and not a bug in themselves.

3. While assessments of performance are valuable, they are not the only
criteria that should be used to select a file system. In addition to
benchmarks, file systems must be tested for a variety of use cases and
verified for correctness under a variety of conditions.

== General Information ==

1. The top level benchmarking results page is located here:
http://kernel.ubuntu.com/benchmarking/
This page is linked from the top level index at kernel.ubuntu.com

2. The tests are run on the same bare-metal hardware for each release,
on spinning magnetic media.

3. Test partitions are sized at twice system memory size to prevent the
entire test data set from being cached.

4. File systems tested are ext2, ext3, ext4, xfs, and btrfs

5. For each release, each test is run on each file system five times,
and then the results are averaged.

== Types of results ==

There are three types of results. To find performance regressions, we
(the Ubuntu kernel team) are primarily interested in the second and
third types.

1. The Iozone test generates charts of the data for each individual file
system type. To navigate to these, select the links under the “Ran” or
“Passed” columns in the list of results for each benchmark, then select
the test name (“iozone”, for example) from that page. The graphs for
each run for each file system type will be available from that page in
the “Graphs” column.

The second and third result sets are generated by the
iozone-results-comparator tool, located here:

http://code.google.com/p/iozone-results-comparator/

2. Charts comparing performance among all tested file systems for each
individual release. To navigate to these, select the links under the
“Ran” or “Passed” columns in the list of results, then select the
“charts” link at the top of that page.

3. Charts comparing different releases to each other. These comparisons
are generated for each file system type, and are linked at the bottom of
the index page for each benchmark. These comparisons include:

3A. Comparison between the latest kernel for each Ubuntu series (i.e.
raring, saucy, etc).

3B. Comparison between the latest kernel for each LTS release.

3C. comparison of successive versions within each series.

Posted in Open Source, Ubuntu | Tagged , , , , | 5 Comments

Baofeng Packet Radio Adventures

Recently, I decided to set up packet radio capability for my station. This is primarily in order to be able to reach the local Winlink Radio Message Server (RMS) gateway and have email access when power and/or internet are down, as has happened in the past after massive tornado damage in the area. I learned some interesting things while doing this, so I thought I’d share. I’ll include links and explanations of some of the radio-related terms, so I hope this is accessible to everyone.

I have a good station with excellent backup power sources, and I serve as an Official Emergency Station for Amateur Radio Emergency Services, (ARES). Adding Winlink email capability seemed like a good thing to do.

The RMS gateway station is in a facility a few miles from me, with redundant power and internet backup, and operates on the amateur radio two meter band.

Since the gateway is close to me and shouldn’t take much transmit power to access , I decided to try to put together a small package combining a handheld transceiver and interface which could serve me at my home location, or be portable if needed. For the interface, I chose a TinyTrak4 (TT4). While this device is commonly used as an APRS position reporter, it also functions as a Terminal Node Controller (TNC) which has a KISS Mode interface that can be used by the Winlink software.

TinyTrak4

TinyTrak4 (with my input level adjust modification)

I decided to try using one of the incredibly inexpensive Chinese handheld radios as the transceiver, and bought a Baofeng UV-3R for $30 on Amazon. It’s not hard to connect this to the TT4 – the radio has a four-wire plug and jack that connects the audio output, Mic input, and Push to Talk (PTT) signals.

The Baofeng puts out about 2 Watts of RF transmit power, which should be enough given that I’m close to the gateway and can transmit through a 3-element yagi antenna mounted on my roof, about 30 feet high.

Hooking all this up, I found I could not get a good connection to the gateway. My first thought was that it was low transmit power, but I decided to troubleshoot the entire functionality in a sensible order, and switched to monitoring APRS packet transmissions on 144.39 MHz. Received packet decode was terrible. I was successfully decoding less than 10% of what I could hear.

I know from prior experience that some packet decoders are very sensitive to input level, and I spent a lot of time fiddling with this. There’s a good procedure in the TT4 documentation, and I followed this.

Carrier Detect (CD) is a signal that’s present when another station is transmitting, and is used by the TT4 to determine when it’s OK to transmit, and also (presumably) when to try to decode received packets. The TT4 has three selectable options for determining that Carrier Detect (CD) has been asserted. The first is with an external wired connection. This option is not available for most radios, including the Baofeng, so I was limited to the second and third choices. The second is “Level” detection, which detects when the audio level exceeds a certain threshold. The reason that this works is that most radio transceivers are set to Squelch the audio output, or turn it off, unless there’s a signal present. The third method used by the TT4 is to detect the presence of the tones used to transmit the packet data.

I noticed that with the squelch turned on, and CD mode set to “Level”, I was unable to successfully decode a single packet. I figured that this was because the radio was slow to break squelch, and the beginning of the actual data was getting chopped off. With the squelch turned off on the radio, I was able to get a few packet decodes.

The next thing I did was to hook the TT4 up to another radio, an Icom 2200H. I immediately got decode of most packets I could hear, and when I adjusted the audio level, it went to near 100%. I tried this with the squelch both on and off on the Icom, and had good results both ways. There’s a software adjustment for “Audio Gain” as a configuration option in the TT4, and after playing with that in combination with actual input voltage level, it seems that any audio level between about 200 mV and 1.5V P-P will work well with the TT4.

A digression about what I can infer about the way the TT4 works:

The input circuit on the TT4 is worth understanding. The schematic diagram is in the kit manual, which is available here as a PDF document.

The TT4 audio input has a DC blocking capacitor (.1 uF) and is biased by two 220K resistors in a ladder from the A/D Reference pin of the MEGA644P microcontroller to ground. The ATMEGA controller allows you to output a selectable reference voltage on this pin, and that’s what the designer is using to bias the input. The choices are 1.1V or 2.56V. The input to the A/D converter sits at about 1.2 Volts, from which I infer that he’s using 2.56V. This can be seen in the following oscilloscope captures. It’s impossible to tell what the software design actually does (TT4 is not open source software), but with a 2.56 reference voltage for the A/D converter, this makes 2.56V the highest voltage that can be read accurately.

So in theory, input signals up to 2.5V Peak-to-Peak are fine, depending on how they’re processed. This pretty much matches with what I observed while using the Icom.

This brings us to the first examination of the receive problem with the Baofeng UV-3R. At the lowest volume setting, the voltage into the TT4 is about 600mV P-P, biased at about 2V. This is the very lowest volume setting on the Baofeng, one click off of silence. This level should work with the TT4, based on what I was seeing with the Icom. But it’s more complicated than just having the right input level . . .

Here’s what the beginning of the radio breaking squelch looks like:

Baofeng Breaking Squelch

Baofeng Breaking Squelch

The bottom trace is the A/D input pin, and is about the same (600 mV P-P). Note that the scales for the traces are different.

Another thing to notice here is that there are some large DC transients as the radio breaks squelch, with the A/D input going negative half a volt! It takes almost 80 mS before the bias level settles out (bottom trace). This could account for why it never decodes successfully when I have squelch enabled, but it sometimes decodes with the squelch off. I think that it just takes too long to break squelch and settle, and loses the beginning of the packet.

Here’s what the end of a packet looks like on the Baofeng:

Baofeng end of reception

Baofeng end of reception

You can see the end of the packet data, then a very short period of low signal (at the center of the image), then noise after the transmitting carrier stops. 100 mS later, the radio drops back into squelch. There are also DC changes from the radio here, and it takes another 150 mS for the input bias to settle.

When the squelch is turned off on the Baofeng and audio is output all the time, there are no DC shifts, so it appeared to be only related to squelch operation (more on this later).

Now, on to The Icom. Here’s a trace at the beginning of a packet when it breaks squelch:

Icom breaking squelch

Icom Breaking Squelch

Differences:
1. Much lower DC bias on the speaker line
2. Much less DC transient on breaking squelch
3. Much less time to settle – about 12 mS at the A/D input as opposed to 80 mS

Now, here’s the Icom end of reception:

Icom end of squelch

Icom End Of Reception

There’s a larger transient here, but it probably doesn’t matter because we’re done decoding, and again, the A/D input settles fast – under 40 mS as opposed to 150 mS for the Baofeng.

After all this, I decided to add a 10K ‘volume control’ to the TT4 input, so I could turn up the Baofeng audio output a bit and then set the TT4 input level to exactly match the Icom levels which were working well.

Having done that, and doing A/B testing while monitoring APRS 144.390, with similar settings for both (Squelch enabled/disabled/ same settings for carrier detect), I got almost 100% decode with the Icom with or without squelch, zero decode on the Baofeng with Squelch enabled, and perhaps 5-10% decode with squelch turned off.

Lacking test equipment to examine the signals in more depth, I did try viewing audio from the Icom and Baofeng simultaneously on the two scope channels during packet reception, and they were nothing alike. This may be because the Baofeng claims to use “DSP”. This could lead to a delay in the audio, which would prevent it from correlating with the Icom. Or perhaps Baofeng is doing some audio processing for voice clarity, which is interfering with packet decode.

At this point, I decided that I didn’t want to put any more engineering time into looking at a $30 radio, and decided to move on and use the Icom to communicate with the gateway. I’ve been told by other local hams that they have successfully used this very same Baofeng model for packet radio, so I’m not sure why it doesn’t work for me.

And then . . .

Yesterday, this blog post was made, in which the author describes adding a Carrier Detect output signal to a different model of Baofeng radio. He was able to do this because the software in the radio only turns on power to the audio amplifier when it wants to make a sound. By connecting to the amplifier power supply inside the radio, he was able to implement hardware Carrier Detect.

AHA!

Turning on the audio amplifier when squelch breaks would explain the crazy DC transients that are seen as the the UV-3R comes out of squelch. It makes sense that Baofeng would do this on multiple models, as it saves battery power. I think the mystery of the slow squelch and DC transients has been solved, but I still don’t know why packet decode is so bad with the Baofeng.

Posted in ham | Tagged , , , , | Leave a comment

Seriously?

No really? Have I abandoned this blog for that long? I’ve been posting updates on projects and such to g+, but that’s not very discoverable, so I think I’ll come back here and post about some longer-form topics.

Posted in Uncategorized | Leave a comment

Politics – Things we can agree on, and discovering a method

Larry Lessig is a brilliant guy.

Lately he’s been focusing on things that Americans across the political spectrum can agree on.

I think that this keynote he gave recently is worth the hour it takes to watch. I strongly encourage you to watch it.

The whole thing is great, but I’m going to seize on the content from 30:00-33:00 minutes to make a connection . . .

That section is about how temporary extensions of tax policy have become an engine for raising campaign funds. Judging from Larry’s comments, this is openly acknowledged and understood. The recipients of the (tax) benefits become predictably dependent on the grantors of their benefits, and value is exchanged.

Can this method of establishing a dependent class of beneficiaries be extended beyond legislation? Yes, and you don’t have to look far to find an example:

As a man in the business of shaping intellectual environments, Hertog has been described as the “the epitome of the conservative benefactor who bases his politics on conservative intellectualism and moves patiently and strategically to create, support and distribute his ideas.” Norman Podhoretz, the former editor of Commentary, said of his longtime friend that, “Roger thinks of philanthropic endeavors as investments. The return he expects is long range.”

Hertog has been a staunch advocate of a conservative, results-based “new philanthropy” – the replacement of open-ended funding for endowed university chairs with money for selected projects, made available on a two- or three-year basis. He makes little distinction between the nonprofit and for-profit ventures that he funds, and has spoken of “retail” and “strategic philanthropy” as “leverage” to transform American universities.

Although the article that quote is taken from focuses on the content of the programs being established at universities, it’s the implementation of these programs I wish to point out, not the program content. They’re designed with short-term funding, to guarantee that the results suite the Patron.

Although “patronage” may be a correct name for these relationships, that word has fairly benign connotations in English today. Perhaps we need a new word or term to describe this sort of thing more accurately.

Posted in politics | Leave a comment

Antenna modeling, part 2

Disclaimer: I’m going to start using Amazon affiliate links for books that I recommend.

I’ve prepared another video about how to use xnec2c.

Here’s the link to the video on blip.tv

This one begins to explain the input file format which is used to describe antennas for modeling. I only noticed one major mistake I made, toward the end, I say “vertical dipole”, when this is actually a model of a quarter-wavelength vertical antenna over a ground plane.

I also briefly touch on the fact that these models shouldn’t be taken as absolutely accurate for any specific installation. The types of modelling used accounts for some types of interactions with the ground, but does not model refraction effects, and has a very limited number of ways you can model the shape of the ground under an antenna.

As I mentioned in the video, the limitations of NEC modeling and the input file format are well described in the Arrl Antenna Book. If you’re interested in antennas, this is probably the best single book to have. The book comes with a bunch of windows software, and the text is in reference to that, but the section on NEC input files is also useful for using Linux modeling applications, including xnec2c.

If you’re using Ubuntu for amateur radio applications, be sure to check out Ubuntu Hams.

Let me know what you think and what you’d like to see next.

Posted in Uncategorized | Leave a comment

Antenna modeling using nec2c on Ubuntu Linux

New Thing! Video!

I’ve been playing with antenna modeling, and decided to make a video series introducing this to other people who may be interested.

I’m new to this, but I think it came out pretty well. I only misspoke a couple of times, but it will probably only be noticed by the technical pedants (I count myself among these).

The first episode covers the basic user interface and some basic concepts. I already have plans to make more episodes, possibly with these topics:

  • Basic data input file format for xnec2c
  • Antenna tuning, resonance
  • Single band beam antennas, more elements for more directivity
  • The dB (Decibel) – as a unit AND a referenced quantity
  • SWR – what it is, why it matters, and when it doesn’t
  • How antenna height affects gain and impedance
  • How to model traps in xnec2c
  • Near field analysis – why do you need it and what does it mean?

I need to figure out where to place show notes for these, as there are a lot of good information sources about these topics on the internet already, and I need to reference those in each episode. I’ll get smoother at all that.

For the first episode, here’s how you can fetch the example files:

git clone git@github.com:sconklin/Antenna-Modeling.git

Here’s a link to my show page on blip.tv

And here’s the embedded episode:

Posted in ham, Open Source, Ubuntu | Tagged , , , , , , , | 2 Comments

I feel like I found an easter egg!

I was jotting some notes for a future wiki page about how to debug network connections to dx clusters, and for my examples, I decided to use the host name dxspots.com.

and I ran across this:

sconklin@xps-1:/src/ubuntu$ whois dxspots.com

[ snip ] – some stuff removed

Registrant:
Ron Stordahl
701 Brooks Ave So
Thief River Falls, Minnesota 56701
United States

Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: DXSPOTS.COM
Created on: 20-Nov-01
Expires on: 01-Jan-13
Last Updated on: 04-Oct-10

Administrative Contact:
Stordahl, Ron xxxxxxxxxxxx@xxxxx.com
701 Brooks Ave So
Thief River Falls, Minnesota 56701
United States
+1.2186817900 Fax — +1.2186817901

Technical Contact:
Stordahl, Ron xxxxxxxxxxxx@xxxxx.com
701 Brooks Ave So
Thief River Falls, Minnesota 56701
United States
+1.2186817900 Fax — +1.2186817901

Domain servers in listed order:
NS2.DXSPOTS.COM
NS1.DXSPOTS.COM
NS2.ONVOY.NET

Interesting. Almost any hardware hacker recognizes Thief River Falls as the home of Digi-Key, in the same way as one might hear a bell when someone mentions Benton Harbor.

Looking a little deeper:

sconklin@xps-1:/src/ubuntu$ nslookup dxspots.com
Server: 172.31.0.1
Address: 172.31.0.1#53

Non-authoritative answer:
Name: dxspots.com
Address: 204.221.76.52

sconklin@xps-1:/src/ubuntu$ whois 204.221.76.52
#
# Query terms are ambiguous. The query is assumed to be:
# “n 204.221.76.52″
#
# Use “?” to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=204.221.76.52?showDetails=true&showARIN=false
#

Digi-Key Corporation DIGIKEY1 (NET-204-221-76-0-1) 204.221.76.0 – 204.221.77.255
Onvoy ZAYO-204-220-0-0-15 (NET-204-220-0-0-1) 204.220.0.0 – 204.221.255.255

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Ooooh, Digi-Key is actually hosting the dx cluster. Cool!

Final discovery? The registrant of the domain is Ron Stordahl, the founder and CEO of Digi-Key. Read the history for your self.

Nice! Thanks, Ron.

Posted in ham | Tagged , , | Leave a comment