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

Bringing some unity to international keyboard layouts

▼ As most people who’ve used a keyboard in (another) European country can attest to, all the other countries use really crazy keyboard layouts. An effort like EurKEY tries to solve this by coming up with a keyboard layout that works for all latin script languages. Apple’s ABC Extended (formerly US Extended) is also a pretty good effort.

However, coming up with a really good keyboard layout is pretty easy. Getting people to abandon the keyboard layout they’re used in favor of a “better” one to is the big problem. (Insert old joke: standards are great, there are so many to choose from!) So what I wanted to do is come up with something that works for people who find themselves behind a foreign keyboard, but also those who appreciate having a layout that makes it easier to type their most-used language.

This is the idea. On a keyboard where the basic letter and number keys are not where you expect, such as the Turkish F keyboard, you just can’t type. So if the A-Z, 0-9, the comma and period are in unexpected places, you really can't have international guests for your keyboard without changing keyboard layouts.

So A-Z 0-9 , . are in their expected (US / western Europe) locations:

For all the other letters, we accept that they can be in unexpected places. But we're going to help out visitors by having all those letters in a default backup location: if the normal key doesn't give you what you expect, just use alt. So when I type on a Spanish keyboard and I need the semicolon, I'm going to discover that that key gives me ñ instead. Rather than having to scan the keyboard to find the location of ; on Spanish keyboards, I can just type alt-; and get my semicolon. And of course alt+shift+; for : because shift+; produces (unsurprisingly) Ñ on a Spanish keyboard.

So just one thing to remember: if a key doesn’t give you the letter you expect, try again with the alt key pressed. This way, it’s still possible to have different keyboard layouts for different languages, but without leaving foreigners who find themselves behind such a keyboard in the cold. So:

We can now type all the regular ASCII characters on any keyboard. Note that the alt and alt+shift combinations are always as specified here, even if that means that the characters with and without alt are the same, like on a US keyboard. This way, it's always possible to type the alt combination and get the expected result.

Keyboard layouts for different languages also use various alt key combinations to type additional characters and accents. That's a fairly big problem because those characters are usually not printed on the keys, so good luck finding out how you type a French ç with a German keyboard layout or a Polish ł on a Dutch keyboard. So part of the unified keyboard layout is having alt combinations for (almost) all characters used in (almost) all languages written with the latin script today. And use that set of alt keys with all keyboards, so these characters can be typed in the same way on all keyboards, even tough keys like - = [ ] ; ' / (without alt) are used for characters that make the most sense in the local language.

I think it makes sense to reuse Apple’s extended layout here, as this makes it possible to type any diacritic I’ve ever heard of and more. This layout allows for no fewer than 22 different diacritics using 22 dead keys.

A dead key works like this. Suppose you need an é, but there’s no é key on your keyboard. So you type dead key for the acute accent (alt-e) and after that the e key. Result: é. Need a ú instead? Alt-e and then u = ú. And so on.

The Apple extended layout also allows for another way to reach the same result: Unicode combining characters. With these, you first type your letter and then the combining character. So a and then alt+shift-e (for the combining acute accent) results in á.

The interesting thing about the combining characters is that unlike dead keys, they work on all characters and you can can combine as many as you like.

Because we had to evict a lot of alt and alt+shift characters from the non-alphanumeric keys, and because the combining characters mostly duplicate the dead key functionality, I’m getting rid of the combining characters under alt / alt+shift. However, those remain available using their own dead key.

I tried to move all the keys that need to be moved to a logical place, but this is of course debatable. æ and Æ went from alt(+shift)-' to alt(+shift)-R as that is the only place I could free up both the unshifted and shifted alt combination. I avoided having both alt and alt+shift dead keys under the same key in order to avoid confusion and to make the combining characters dead key work better.

I also thought that having dead keys for Greek characters as well as math characters was a useful EurKEY feature, so I’m adding those. And a dead key to cover business, currency and additional typographical symbols. Superscript and subscript digits 0 - 9 can go under the math dead key. (I’m not going to specify all the math and business characters at this point.) Those dead keys, as well as two “weird character” dead keys from Apple Extended all move to the bottom row (Z - M) with alt+shift.

Finally, I added the Turkish ı (latin small letter dotless I) because that one seems to be missing from Apple extended. There’s also the capital I with dot = İ, but you can simply type that using alt-w (dead key for the “dot above” diacritic) and then I, so like all other accented letters, it doesn’t get its own alt key combination. This is the result:

This leaves five alt combinations unused for now. That seems like a good number, allowing some room for future expansion, but not wasting too much real estate. Combining it all:

But really, that's just the start. The idea is to combine these new alt and alt+shift layers with existing keyboard layouts that conform to QWERTY, 0-9, comma and period, and thus have different layouts for different languages.

This means that people typing the “default” language can do so without having to relearn anything. At the same time, those who find themselves behind a foreign keyboard have a much easier time, as well as those of us who type in multiple languages.

If you want to see what the results look like, go to this page. You can select keymaps from a list and then click "unify". They will then be compared to the original. Green outline means no change, red means the unification rules were broken, and gray means there's differences, but they fall within the rules.

After quickly checking the list of keyboard layouts on the Mac, it looks like unification could work for the following layouts: Croatian, Danish, English, Estonian, Dutch, Faroese, Finnish, French (Canada), Icelandic, Italian, Maltese, Norwegian, Portugese, Romanian, Serbian, Slovenian, Spanish, Swedish.

It won't work for French (because of the AZERTY layout) or Turkish, even Turkish QWERTY. German and other languages almost get there, but they use QWERTZ, with the Z and Y keys swapped. They could still benefit from the unified alt / alt+shift layers, though.

Permalink - posted 2021-02-05

My keyboard and key rollover tester

▼ I have a new mechanical keyboard on order, which lets you hot swap the keyboard switches. When you do that, it's a good idea to do a quick test to see if all the keys still work. There are many tools to do this, but I decided to make my own web-based one. I think it came out pretty nicely.

You can see if the keys work by typing them one at a time, or (usually) by running your finger along each row.

In addition to that, you can also see how much key rollover your keyboard supports, i.e., how many keys you can type at the same time. Higher end keyboards usually support "n-key rollover" (NKRO), which means that any combination of keys will be recognized correctly. This is useful for some types of games.

Old keyboards usually don't support any additional rollover, so they can only correctly recognize arbitrary combinations of two keys. (This limitation doesn't apply to shift/control/alt or command/windows.) Additional keys may or may not be recognized. However, it doesn't really matter too much if you can't type Z F6 . For non-gamers, what matters is that when you type quickly, it can happen that one finger hasn't released the previous key yet while another finger is already pressing the next key. Turns out that on many keyboards that don't support real 3-key rollover, you can still type three (or more) keys at the same time, as long as those keys are all on different columns. Which means: you type them with different fingers. After all, how are you going to type E, D and C at the same time, as touch typists type all three of those with their left middle finger?

A common additional limitation (to avoid more complex USB communication) is a 6KRO limitation.

What the rollover tests (for 3 - 7 KRO) do is test combinations of all the regular alphanumeric keys and most punctuation and then tell you if it looks like you have full key rollover, enough for touch typing or no real rollover for that number of keys. You can of course also just press as many keys as you like at the same time and see if they register.

So have a look and let me know what you think.

Permalink - posted 2020-12-24