Move along, nothing to read

I was doing some statistics about Gentoo mirrors to see about future plans, and thought that the indirect crowd that read my blog via the various aggregators might be interested in numbers.

These are the traffic for boobie.gentoo.org, which is a newer box in the official rsync.gentoo.org box directly maintained by the Infrastructure team. Hardware specs are 2x Xeon 3050 @2.13Ghz, 4GB RAM. Disk is mostly irrelevant - the rsync workload is served purely from RAM (tail-packing reiserfs, backed via loop device pointing to a file on tmpfs).

Inbound traffic is spiky, but does not exceed 10Mbit by more than a little bit - we can the inbound rsyncs from the rsync1 master to 10Mbit. Outbound traffic varies between 4Mbit and 9Mbit, with an average around 6-7Mbit.

( Numbers )

As a recent random time-waster, I went and read all of the bugs in the "Recruitment" product of the Gentoo Bugzilla. In doing so, I found twelve developers (ebuild or other) that weren't listed in our LDAP or historical tracking at all. I added them back now, I have gentoo-core announcements from when several of them joined as well that I double-checked.

The "lost" developers

• pihta - bug 20756
• ct - bug 22211
• srcerer - bug 23184 (retire date approximate)
• fede2 - bug 25464
• vlaci - bug 31795
• teval - bug 36753
• mccabemt - bug 43029
• rip7 - bug 46353
• twk-b - bug 53723
• dj-submerge - bug 57051
• little_bob - bug 69742
• ruth - bug 70469

Other LDAP changes from my review:

• svyatogor - bug 20756 - updated join date for original docs work, he had commit rights two years before his previously stated join date
• archaelus - bug 30835 - data fixup
• apokorny - bug 70188 - add join date

Further plans:

There are 92 developers without join dates. We need to find join dates for them via BugZilla and CVS/SVN. Also audit all join dates for every other developer. Lastly, discover and capture retirement dates for every past developer.

Present statistics: 673 developers total. 247 active, 426 retired.

Migrating data and cleaning up my old desktop display head machine, I decided to check out my ccache statistics. This is a very old cache, having first started 2006-01-13. The oldest item in the present cache is 2008-01-12, but the statistics are valid for the entire period. hits 229k and 834k misses = approximately 21% hit rate. This wasn't any crazy repeated compiling of my own code, just a dedicated ccache directory for Portage to use.

( Raw numbers )

Edit 2008/09/16:

Code fixed now, no specs available yet See my patches here.

Edit 2008/09/05:

A private source that I inquired of indicates that the AD2000B part was only a special run of the AD1989B part. There shouldn't be any functional differences. On the side of a spec sheet, the AD1989B specs should be available "shortly" from Analog Devices.

Original posting:

So in more details to follow, I picked up hardware for a new workstation to replace my G5. The only part of the hardware that isn't working yet, is the digital audio (SPDIF/Toslink) output. My motherboard is an Asus P5Q-Premium, and the specifications claim to have "ADI® AD2000B 8-Channel High Definition Audio CODEC" as the audio chip. This chip is apparently the successor to the AD1988B chip. The analog audio part works fine, just that I use optical to overcome an interference issue on the run between my computers and my actual working area of my desk (with a small digital decoder and stereo speakers).

Digging around in the ALSA drivers, it just seems I need to find a different set of controls to toggle the digital lines to be outputs or enabled - and that this data would be in the public datasheet, just like previous versions of the chip. I submitted a technical request to Asus a few days ago, with no response yet. I also contacted Analog Devices directly. Their customer support referred me to their application engineers, whom I phoned, and they then proceeded to deny the existence of the chip, and I quote: "It's not in my system, we don't manufacture it." That's really interesting, because I've got it on my motherboard!

Either the divisions of Analog Devices aren't talking, or Asus is using chips from a 3rd party that's ripping off Analog Device's trademark amongst other things.

Here's the text off the chip:

AD2000BX
14??793.1
#0816 0.3
SINGAPORE

I tried to take a photo, but it's really annoying and hard to read, without dis-assembling my machine, which I'd prefer not to do at this point.

However, I did find another photo on the web, of the same area from a review of the motherboard. The Analog Devices logo is also clearly visible after the 'BX' portion of the text. From the photo I could make out:

AD2000BX
1383055.1
#0808 0.2
SINGAPORE

If I had to make a guess about it, the chip is AD2000BX, the second line is the serial number, the third is the year and week of manufacturer, plus the revision of the chip, and the last line is the manufacture location.

If you're from Asus or Analog Devices, and you're reading this, where's the datasheet for the chip? Is it a real ADI part? I simply want the public datasheet like the rest of models so that I can fix digital audio output in Linux myself, and contribute it back to the ALSA project.

P.S. The upstream ALSA bug is here. There's no downstream Gentoo bug.

This is a copy+paste from my email to the gentoo-dev mailing list, simply because some developers and users follow the RSS feeds rather than read email. If you want the bot in your channel and you are a channel founder/lead op, please respond on the thread in the mailing list

Hi folks,

Sorry that it's taken this long to get completed, but the Jeeves
replacement, Willikins, is finally 99% done, and ready to join lots of
channels.

Getting the bot out there
-------------------------
If you would like to have the new bot in your #gentoo-* channel, would
each channel founder/leader please respond to this thread, stating the
channel name, and that they are the contact for any problems/troubles.

Bug reports
-----------
Please open a bug in the Gentoo Infrastructure product, using the
'Other' component, and assign it directly to me.

Custom bot functionality:
-------------------------
Here's all the functionality that we have assembled, beyond the standard
rbot stuff.
Bugzilla
========
!bug [ZILLA] ID
Looks up bug #ID in the per-channel default or specified bugzilla.

!bugstats [ZILLA]
Totals of bugs per the bugzilla 'status' field.

!archstats [ZILLA] [STATUS] [RESO]
Totals of bugs per architecture, optionally with some specific set of
status or resolution values, comma delimited.

status = OPEN, DONE, UNCONFIRMED,NEW,ASSIGNED,REOPENED, RESOLVED, VERIFIED, CLOSED
Reso = FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME,
       CANTFIX, NEEDINFO, TEST-REQUEST, UPSTREAM
zilla = gentoo xine sourcemage redhat mozilla kernel fdo abisource
        apache kde gnome
If you want another bugzilla, file a bug.

Gentoo-specific
===============
!meta [-v] [CAT/]PACKAGE
Print the metadata and optionally herd members for a given package.

!changelog [CAT/]PACKAGE
Changelog stats for a package

!devaway list
List all away developers.

!devaway DEVNAME
Display .away message for a single developer.

!herd HERD
Show herd members

!expn NAME
Show the expansion of any public Gentoo mail alias

!glsa GLSAID
Shows the title and external IDS for any given GLSA ID.

!earch [CAT/]PACKAGE
Earch output for a given package

!rdep [CAT/]PACKAGE
Reverse RDEPEND for a given package

!ddep
Reverse DEPEND for a given package

What isn't supported yet
------------------------
1. !glsa -s TEXT
This used to search for GLSAs that matched that string in their title or
external IDS.

2. New bug announcements
Jeeves used to announce brand new bugs to #gentoo-bugs as well as
targeted channels or users, depending on the product, component,
assignee, cc and a number of other factors (deeply nested if/else
trees). The old implementation had this in code entirely, and it would
be nice to avoid having to modify the code whatsoever, and instead have
some domain-specific language for doing this.

Source availability
-------------------
Gentoo specific:
http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-gentoo.git
Bugzilla support:
http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-bugzilla.git
(flameeyes has his own tree as well, but he's been sick lately, so it
was lagging behind my development)

Right now, if you want to run your own instance of the bot, you will
need the latest Git tree of the rBot itself, as upstream only fixed the
last remaining issue a couple of hours ago.

Thanks to
---------
solar:
Running the old Jeeves Eggdrop till now, and helping to document all of
the Eggdrop functionality we used.

flameeyes:
Bugzilla plugin development

halcy0n:
Gentoo-specific stuff

tango_, jsn-:
(rbot upstream developers) For fixing the bugs as I found them :-).

Having my bike stolen has made me wonder about locks more. Defeating most forms of bike locks are trivially easy with some lateral thinking.

This was my lock:

Lock properties and attacks against

key-based

bumpkey (given a suitable blank or other key of same style), pick the lock, drill or freeze the lock (either LN₂ or just adding in warm water on a day that's below freezing)

combination-based

guess or shoulder-surf the combination

Cable/Chain

Large bolt cutters, wire cutters or hacksaw

U-Lock/D-Lock

Use a jack inside the arms to apply outward force

Any other bicycle lock types or different attacks that you can think of? Any way to effectively defeat one of more of the above attacks? From a security perspective, we need to consider not only the permitted attacks, but all possible attacks.

In my case, they either defeated my combination (probably by shoulder-surfing), or just used some form of cutting attack. Since the lock wasn't left behind, I suspect the former more than the latter.

On Tuesday for OLS2008, I attended the wireless mini-summit. In past years, fellow Gentoo developer dsd has attended, and was remember by some of the attendees. I'm not so much involved with wireless stuff these days, but I have a good grasp of it from back when I worked at Net-Conex doing point-to-point links using Airaya WirelessGRID 802.11a gear doing 108Mbit w/ AES256, plus personal experimentation.

The vendors (Intel, Marvel, Broadcom, Atheros, Ralink, Nokia and others) and major distributions (Fedora/RH, Ubuntu, Debian, Suse) were present, but I was the only attendee from the smaller distros. Also present were some of the other core wireless developers, incl. Johannes Berg.

Most of the talk focused on 802.11 stack and driver issues, with a presentation about WiMax from Intel.

One of the really interesting things was the work from Luis R. Rodriguez, on the new Central Regulatory Domain Agent (CRDA). There were some large questions from the Intel crowd about API and interaction, but the general concept was very well received. The support for signing the domain file is probably going to not be used for the most part, as there are too many other places to subvert usage of the data even if the file is signed. 802.11d and 802.11h are mostly considered as useless as apparently no regulatory agencies have signed off on them.

Another interesting discussion came out of the discussion on power management. Stuff on the usage of the CARRIER interface flag. It's apparently quite inconsistent, and the UP/DOWN status on some wireless devices has large implications. Some devices go totally away on DOWN, and need firmware loaded on UP. In some, the power consumption in reset state prior to loading firmware is lower than any other powered-down state. Multiple power levels may be added later to try and allow devices to define what states are best/available for their power saving. Implications of firmware loss and DOWN state on associations to APs, esp. when some parts of WPA are in play. This all also sucks with some DHCP clients as they perform DOWN on release or failure, which loses the firmware - such behavior from userspace really needs to be stamped out.

For lunch, we went to a buffet resturant, Tuckers. I was a little dubious of this at first, as buffet is really not my thing, however I can say that it was quite decent, esp. their roast beef carvery, with some nice whole-grained mustard. The salads weren't so great, but overall I think I'd eat there again in a group if there was sufficient group demand.

On the way out of lunch, I ran into a cute girl (I'll call her A) with a rubber-spiked laptop bag, and started chatting to her. As she was an Ottawa resident, she was prepared with an umbrella for the torrential summer rain that started during lunch. Sharing her umbrella we returned to the hotel conference rooms, splitting up thereafter as she was in the virtualization mini-summit.

Post-lunch, resuming the wireless mini-summit, we discussed more issues about the CRDA, core mac80211 development, and then breakout sessions on power-management and ??? (I can't remember what the other side was, even though I was in it).

For dinner, I took a clear walk out via parliament, and a very long way, full route. Ended up at "Elgin Street Freehouse" for dinner, had an Indian-fusion twist on steak, and did manage to find virgin Mojitos successfully. Nice 5km walk for exploring.

As one talk I was really interested in, I went to John Hawley's talk entitled "Issues in Linux Mirroring: Or, BitTorrent Considered Harmful", as seen from the perspective of the kernel.org mirrors.

This paper was really interesting for me, both as the Gentoo releng infra liasion (I get the bits from releng onto the mirrors), as well as working for IsoHunt, since he was complaining about BitTorrent.

Before the actual material about BitTorrent, he had some harsh words about distributions and space usage, and the lack of co-ordination. Having multiple major distributions doing their releases in the same week really only hurt themselves, because the mirrors get saturated by users. Between two major distros, they use up fully half of the 5.5TiB at kernel.org, and having them doing new material at the same time just blows out the cache, even with stupid amounts of memory. (Comments were made about Mark Shuttleworth having the money to buy some boxes with TiB of RAM for kernel.org). Co-ordination between distributions is needed to resolve this issue, and the audience discussion suggested we should try the distributions@freedesktop list first, and if that's too much noise, start up a list at kernel.org instead.

Moving onto BitTorrent, he noted that in large Linux torrent swarms, the standard tracker balancing algorithms end up with a net effect that a few slow peers joining greatly slow down the swarm speed at present (based on analysis of the tracker used by Fedora for the F8 release). If mirror are performing seeding, in many cases, it will still be faster for the mirror to provide content for a given user than other client peers. If the objective is to move content as fast as possible, this is needed vs. the normal BT objective of balancing total bandwidth usage.

Issues for distributions in handling bittorrent to make life easy for mirrors, he had several complaints about the level of manual interaction needed, to which I responded with the Gentoo structure of symlink trees under experimental, which is used for mirrors to run torrents easily, as well as powering the HTTP seeding additions to the BitTorrent protocol.

In using rtorrent(libtorrent), he complained that it wasn't using sendfile at all, which had a large negative performance impact, should be tackled upstream.

The BitTorrent community also needs to look at tweaking the peer decision protocol in the announce protocols, to hand out a smarter selection of fast peers. Where fast is local (look at BGP looking-glass for clues) or is a designated fast mirror that should be used as a fast peer.

Lastly, he noted that the trackers seem to be badly run, as somebody from isoHunt, I offered to post up my own work on running effective trackers to the inter-distro discussion.

• 07:49 Mirrormanager from fedora shows promise for better gentoo mirroring #

Automatically shipped by LoudTwitter

So my carry-on laptop backpack got a full going-over because of a little folding tripod that apparently looked weird on the scanner...

And they saw and removed the small zipties that I use for securing my suitcase normally, claiming that I could use them to tie people up.

Nevermind the 6ft ethernet cable, or the laptop cable, I was going to be able to tie somebody up with a couple of zip-ties, each 5cm in length, with a width of less than 4mm.

The American TSA side has never complained about them, and now on a Canadian domestic flight they did. Just simply crazy.