Friday, 24 January 2020

Testing a Bakeey microSD card

Is the Bakeey Extreme 64GByte any good?

The claims

Hard to see specs
The rough surface makes it hard to identify the markings. But as far as I can see, it claims to have the following characteristics:

  • 64 GByte capacity
  • Class 10
  • UHS: U3
  • Video Class: V30
  • Class A1
  • UHS1 (Bus Logo: I)
The question is: What does it all mean, and can I test that?

I bought the set (card/adapter/reader (usb-c / usb-a) here from Banggood.

I use h2testw to test the capacity and read/write speed. So from the results, I can see:
  • It really has the 64GBytes, so no fake that overwrites itself: OK
  • Class 10: I get a 13,4MByte/s write speed, so it meets the class 10 specs: OK
  • U3: With the supplied USB adapter, I could not get anywhere near 30MByte/s write speed. So for the moment the answer is: No!
  • V30: Again not with my adapter: No!
  • Class A1: That's 10MByte/s write speed and a low number of IOPS. So: Very likely OK
  • I logo: With the UHS-1 logo, the bus speed can be 12,5 to 104 MByte/s: Again likely OK
The read-speed I got was 17,4MByte/s with the supplied USB Card reader. Again not fantastic, but ok for a class 10.

EDIT: I re-tested with an USB3 card reader. The results were somewhat better:

  • 18.9MByte/s write rate
  • 31,6MByte/s read rate

I wanted to try 4k video streaming in my Olympus OM-D, but with the Micro-SD to SD adapter, the camera reported a card error. So I have no way to verify the 30MByte/s claim. But I have a compatibility issue with either the card or the adapter and the Olympus camera.
No issues in a Macbook Pro with the same adapter, though. Seems like a real compatibility issue.

Bottom line

For the card and the two adapters, I paid 10 USD. That appears fair for the set, but cards with similar specs are available from Transcend or Kingston in the same price range. An ok deal, but no need to rush. For my camera, I'll stick with a SanDisk Ultra that guarantees 40MByte/s for 4K recording.
All in all nothing to write home about.

Monday, 20 January 2020

Blitzwolf BW-UPC2 Test and Review

BW-UPC2 Blitzwolf UDB Thumb drive

What's special about it?

You probably wouldn't read this if you didn't know that: The BW-UPC2 has both an USB-C and a USB 3.0 A connector.

Cooool... two connectors
So it should be great for me to exchange files between my "old" Surface Laptop 2 and my "new" iPad Pro (3rd gen, 11"). More on that further down the page.
The look&feel is good, but the rotating cover does not (unlike what they claim on their web site) protect the connectors against dust.

At the time of writing, the 128GByte version of the drive was around 25USD and I got it here from my favorite Chinese reseller.

Benchmark test

I used h2testw (from the renowned German computer magazine CT) to benchmark the drive through it's USB A port.
One thing to look for in USB drives is, if they actually have the capacity they report to the PC. h2testw also checks that by filling and verifying the whole drive. This is not a fake-capacity drive.

The Blitzwolf web site claims "up to 150MByte/s" read, and "up to 50MByte/s" write rate. "Up to" seems like something that does not happen in real life.
Still the measured rates are not bad:

Test results
Still not in the same range as a Sandisk extreme, but very acceptable. A lot better than my awful "Intenso Alu Line 32GByte"


  • Write rate: a little under 40MByte/s
  • Read rate: a little over 60MByte/s
Whereas Intenso Alu Line:
  • Write rate: a little under 4MByte/s (= 1/10th of the Blitzwolf)
  • Read rate: a little over 13 MByte/s
All of this was done on the USB A Port of a Surface Laptop 2.

So the Blitzwolf UPC2 is clearly a massive leap ahead for me when it comes to speed. For very short write bursts, it appears to have some kind of cache, because for low data volumes (some MByte), I get over 70MByte/s write- and over 80MByte/s read rates. That is not sustainable, of course.
It does not appear to be the operating system's file cache, as the Intenso drive does not exhibit this behaviour.
(Funny: the 70MByte/s write rate is over the claimed "up to 50Mbyte/s")

Also interesting: The write-performance was very poor on the USB-C port of a new Surface Laptop 3 15" (17MByte/s write / 70MBytes read), while on the USB A port of the same machine, it was 24MByte/s write / 62MByte read). So there appears to be a dependency on the Computer and it's drivers.

iPad pro (3rd gen.) compatibility

The drive comes pre-formatted with an exFAT file system. This is a good thing, as iOS / iPadOS13 currently only supports MSDOS FAT and exFAT (and APFS/MAC OS extended, which is irrelevant for Windows users)

USB-C & iPad pro
The iPad recognizes the drive and shows it in the "Files" app. Both reading and writing works well.


Exactly what I needed. I'll move my stuff over from the dog slow Intenso drive.

Thursday, 2 January 2020

RSA WebAgent: AceInitialize failed

RSA WebAgent Troubles

I had the following problem with my RSA WebAgent:
For secure remote access, I have a linux system, running the RSA WebAgent. After an Upgrade of the RSA ACE server, the web portal only responded with an error

106: The Web server is busy. Please try again later.

There was nothing busy about the web server, of course.
As I have a strong networking background, one of my standard trouble shooting methods is to have a look at the network traffic to see what's going on:

tcpdump -vvv -i eno16777984 port not 22 and not 443
(Your interface will have a different name, of course)

Apart from the usual DNS chatter which I didn't filter explicitly, there was no traffic from or to the machine. Especially not, when running
Which returned a
AceInitialize failed

So the machine was not even trying to play ball :-(

There is not much of a debug function in RSA's command line tools, and a
strace ./acetest
showed that all dependencies were ok.

The solution

Then I set the environment variable to use TCP
export USEUDP_ENV_VAR=false
and got a much better chance of getting a response. (Not 100%, though)
With both the acestatus and the acetest utils running successfully, I still did not fully understand the problem, but could fix it.

1) reconfigure Apache
So I needed to modify the apache config to use TCP, rather than UDP:
In /etc/httpd/conf/httpd.conf (or wherever your apache config lies) add:

2) enable rpcbind
The other thing is, that it now seems to rely on a running rpcbind service, so rpcbind needs to be anabled and started.
To check if that is the case, run:
systemctl list-units --type=service --state=active
and see if you get a
rpcbind.service            loaded active running RPC bind service
in the reply.