I did it again... I made another keyboard tester

▼ The other day I noticed how dirty my VT420 terminal's keyboard was, so I decided to take off the keycaps to clean them.

Then of course it's always good to put the keycaps back where they belong. That's a task made a lot easier with a keyboard tester app such as the online one I made a while ago. However, I don't think the VT420 supports the latest Javascript features...

So I whipped up a command line keyboard tester: kbdtest.php. Save the page, rename to kbdtest.php, then run with "php kbdtest.php". Works on the Mac, haven't tested other systems.

The script draws an image of the main part of a keyboard, with the keys that should work displayed in red. Then as you type them, they're made the default color and bright or bold. Typing the same key multiple times adds and removes an underline. The first number is a count of how many different keys you've typed, the second one only counts printable characters and tab, backspace and enter. (Upper vs lower case is ignored.) When you've typed all 71 of those, the program ends. You can of course also use control C. When there's 8 characters left, the remaining ones start to blink.

Note the box drawing characters. These are actually produced by issuing an ANSI escape code to switch to the DEC special graphics character set. In that mode, the lower case characters become line/box drawing characters. Turns out: this also works in the Terminal on the Mac!

I couldn't find a workable way to get the actual keyboard scan codes or something similar on the command line, so I can't do anything with keymaps, like the web keyboard tester does. However, turns out you can still read special keys such as the function keys and arrow keys. These produce ANSI escape codes. And again, that works in the Terminal exactly like it does on the VT420 terminal.

Permalink - posted 2021-03-16

A new life for the 2003 Apple Wireless Keyboard

▼ Back in 2003, Apple released the Apple Wireless Keyboard:

(Not to be confused with later keyboards of the same name that look like laptop keyboards.)

The keyboard still works with an ancient MacBook Pro, but it won't pair with anything from the 2010s. That's too bad, because I think it looks pretty nice. So I decided to see if I could bring its essence into the 2020s by transplanting the keycaps to my Drop CTRL keyboard.

Here on the left is a regular MX style keycap, and to the right one from the AWK2003. Not so different.

Until we turn them over:

However, the AWK2003 keycap will fit on a Cherry MX style switch, especially a Kailh box switch:

But the fit is too loose. However, we can fix that with some teflon tape.

Three layers seems to work well:

And there it is: the Drop CTRL keyboard with 2003 Apple Wireless Keyboard keycaps:

The keycap profile is a bit different, especially on the bottom row, as you can see with the alt key:

It's not possible to replace the entire bottom row with keys from the AWK2003, as only the alt key has a standard size.

So I used the regular keycaps for the bottom row and the cursor keys:

With three layers of teflon tape, the keys mostly stay put, but this is what can happen after a good long typing session...

Permalink - posted 2021-03-05

Review: Cable Matters USB 2.5 Gigabit Ethernet adapter

▼ I think it was in 2016 that 2.5 and 5 Gigabit Ethernet was standardized. After a year or two the first USB to 5GE adapters started to appear at about €/$ 100 and about two years ago the first €/$ 50 2.5GE ones. Right now, there's a ton of USB 2.5GE adapters at good prices.

The hardware

I got a Cable Matters one for € 31 off of Amazon. The adapter is a simple black rectangle with a short and relatively stiff (but not too short or too stiff) USB cable sticking out one end, and space for an RJ45 plug at the other end. There's an always-on blue light at the top of the adapter and a green link light and a yellow activity light where the Ethernet cable plugs in. The blue light is not annoyingly bright and the other two will probably face away from you in normal use. The USB cable is type A, but there's a USB-A to USB-C dongle attached to the cable in case you want to plug the adapter into a USB-C port.

The adapter supports 10, 100, 1000 and 2500 Mbps. Unlike even higher speeds (5GE and 10GE) 2.5GBASE-T (2.5GE) uses the same cat 5e wiring and the same 100 meter maximum cable length as 1000BASE-T (Gigabit Ethernet).

The system reports that the adapter requires a modest amount of power at 304 mA (1.5 W).

Drivers

Cable Matters points towards a RealTek download page to get a driver. There is one for MacOS 10.9 - 10.15. I tried installing the driver on a laptop running MacOS 11 "Big Sur", and... that didn't work.

However, even without installing a driver, MacOS recognizes the adapter and the basic features work. These are the features reported by the ifconfig command:

supported media:
    media none
    media autoselect
    media 10baseT/UTP full-duplex
    media 100baseTX full-duplex
    media 1000baseT full-duplex

(I removed the word "mediaopt".)

There is no support for jumboframes or any type of offloading. And: no half duplex, not even for the original 10 Mbps mode. However, the adapter will autonegotiate 2500 Mbps mode, even though the OS reports 1000 Mbps. So you do get the extra speed, even without installing the driver. But it does look like the computer has trouble sleeping with the adapter plugged in.

Under MacOS 10.14 "Mojave", the driver installs without issue. After that, it turns out the adapter has a range of additional capabilities:

capabilities=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
supported media:
    media none
    media autoselect
    media 10baseT/UTP half-duplex
    media 10baseT/UTP full-duplex
    media 10baseT/UTP full-duplex flow-control
    media 100baseTX half-duplex
    media 100baseTX full-duplex
    media 100baseTX full-duplex flow-control
    media 1000baseT full-duplex
    media 1000baseT full-duplex flow-control
    media 2500Base-T full-duplex
    media 2500Base-T full-duplex flow-control
    media 100baseTX full-duplex energy-efficient-ethernet
    media 100baseTX full-duplex flow-control energy-efficient-ethernet
    media 1000baseT full-duplex energy-efficient-ethernet
    media 1000baseT full-duplex flow-control energy-efficient-ethernet

So now the adapter can do half duplex at 10 and 100 Mbps, energy efficient Ethernet is supported at 100 and 1000 Mbps, as well as checksum offloading and TCP segmentation offloading for IPv4. Also, we can now enable jumboframes up to an MTU of 9194 at 1000 and 2500 Mbps. And wake-on-LAN works.

Performance

As my Ethernet switch tops out at 1000 Mbps, I connected the adapter to my Mac Mini with a direct cable to run some speed tests. I used iperf 3.1.4 for this, with the Mac Mini as the server and a 2016 MacBook Pro as the client. this means I only tested in one direction, which probably matters for the CPU usage I'll discuss below.

With or without the driver, iperf reports 280 megabytes per second (MB/s) and 2.35 Gbps for IPv4 and about a percent less at 277 MB/s and 2.32 Gbps for IPv6.

However, there is a significant difference in CPU usage for IPv4: the no driver 30-second iperf run used 0.8 s CPU time in user mode and 17.5 s for the system for a total of 18.3 s. So:

IPv4: 280 MB/s, 2.35 Gbps, 0.8 + 17.5 = 18.3 s
IPv6: 277 MB/s, 2.32 Gbps, 0.8 + 21.1 = 21.9 s

With the driver installed, that becomes:

IPv4: 280 MB/s, 2.35 Gbps, 1.3 + 9.3 = 10.6 s
IPv6: 277 MB/s, 2.32 Gbps, 0.7 + 19.7 = 20.3 s

So a 40% reduction in CPU use for IPv4 and only 7% for IPv6. This is probably because there is no TCP segmentation offloading for IPv6, only for IPv4. With TSO, the software delivers a very large packet to the Ethernet chip, which will then split that large packet into standard 1500-byte ones. And maybe without TSO6, the TCP checksum must also be calculated in software for IPv6 packets.

I retried my tests with larger packets, but only with the driver installed as this isn't supported without the driver. With a 9000-byte MTU, I got the following results:

IPv4: 270 MB/s, 2.27 Gbps, 1.7 + 8.5 = 10.2 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.9 = 6.6 s

So IPv6 got faster as expected, reaching 99% of the maximum line rate. IPv4, on the other hand, got slower, going from 94% efficiency to 91%. Turns out that something weird happens between the 8000- and 9000-byte maximum packet size, as these are the results for 8000 bytes:

IPv4: 284 MB/s, 2.38 Gbps, 1.1 + 5.3 = 6.4 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.7 = 6.4 s

IPv4 still isn't faster than without jumboframes, but at least it's not slower, and the CPU use is about a third for both IPv4 and IPv6.

Conclusions

This is a very nice USB Ethernet adapter. If you need a new USB Ethernet adapter, get this one or one like it, the Gigabit Ethernet era is coming to a close.

Permalink - posted 2021-03-03