Martin – Page 37 – WirelessMoves

Real World Performance – Part 5 – Fast SATA to USB Adapters

In episode 4, I was able to push my LUKS encrypted disk to disk data transfer rate to around 300 MB/s which already saves a lot of time over my previous methods for migrating a lot of data from an old to a new SSD. However, I wasn’t fully satisfied because even older SATA SSDs can often be read at the full 6 Gbit/s SATA speed, i.e. at around 500 MB/s. The bottleneck in my case thus might have been the the 5 GBit/s SATA to USB 3 adapters. However, there are now 10 Gbit/s SATA to USB 3.1 Gen 2 adapters available so I bought one of those for around 20 euros to see if I could further push the limit.

Real World Performance – Part 4 – partclone

Another thing I have to do every now and then is to clone a partition to a new drive, e.g. for backup purposes or when upgrading. Depending on the amount of data to transfer, this can be quite a lengthy procedure. Copying 2 TB worth of data from one drive to another, for example, can take quite some time. rsync is a great tool to do this but it seems to be rather slow in practice. So far, I can’t get more than 120 MB/s out of it, even if both source and destination are local SSDs. Furthermore, when copying very small files, the transfer rate plunges into a back hole. So in practice with my mix of data, the whole operation usually takes half a day at least. So perhaps there’s a better way? How about partclone?

Real World Performance – Part 3 – Another NVMe

In the first part of this “Real World Performance” blog series, I’ve been looking at the performance of a 2 TB Crucial P2 NVMe SSD I installed in my Lenovo X13 notebook. While it did it’s job well, I was rather underwhelmed with performance. So after a few weeks, I replaced that drive with a 2 TB Samsung 970 Evo Plus NVMe SSD. As the specified write capabilities of that drive goes far beyond the speed I could read data from any other drive I have for testing, I set up a RAM disk with a huge file on it in the second part of this series. So here’s part 3 with my performance results for the Samsung 970 Evo Plus in combination with my X13 notebook when reading from RAM disk, and performance results for my real world scenarios:

Real World Performance – Part 2 – The RAM Disk

In the first part of this “Real World Performance” series, I’ve been looking at the performance of the 2 TB Crucial P2 NVMe SSD I bought for my new notebook. While it does its job, its major weakness is that continuous write throughput is only 100 MB/s. So I bought a top of the line Samsung 970 Evo Plus drive that, according to the specs, should have a much higher continuous write performance.

To be able to test the SSD in a “real world” scenario, i.e. by writing huge files to it, I needed a way to write data to the drive as fast as possible. Writing 0-bytes is probably quite straight forward, but I wanted to have random data to escape any type of compression anywhere in the software chain. The solution: A file with random data on a RAM disk.

When You Read About 0-Days, It’s Probably Too Late Already

Last week on Thursday, I read about the release of a fix for a new Apache 0-day vulnerability that was already exploited in the wild. At first I was a bit concerned, because I run quite a number of VMs with Apache on it. Fortunately, it turned out pretty quickly that my servers were not affected. However, after checking my web server logs, I noted that if my systems had been vulnerable, I would have been hacked long before I read the first article in my RSS stream. Hackers don’t sleep, the press is slow, and I’m even slower!

Real World Performance – Part 1 – NVMe SSD

When I recently bought my new Lenovo X13 notebook with an AMD Ryzen 7 4750U CPU with 8 cores / 16 threads, I had to make a small compromise: I had to buy a rather low end 2 TB NVMe SSD to replace the small SSD it came with, as more expensive but better SSDs would not have reached me in time. It turned out pretty quickly however, that this SSD had a significant downside: The amount of data that can be written to it at full speed is quite limited and any write operations afterward are very slow.

Eduroam Certificate Changes at the University of Vienna

When I was recently in Vienna, I was asked to have a look at an Ubuntu notebook that wouldn’t connect to University of Vienna’s Eduroam network for some time now. It turns out that they have changed their root certificate provider from Digicert to USERtrust.

Moving from Gitlab to Codeberg

Three years ago, when Github was bought, I and many others decided to take their Open Source projects elsewhere and headed over to Gitlab Inc. However, I was never really completely happy about this move as I was just moving from one closed source platform to a (somewhat less) closed source platform with my code. What I really wanted, however, was make my code and projects available on a community driven platform. Three years later, I have found what I was looking for: Codeberg.

USB-C Charger Cable With a Power Display

A quick blog entry today about a nice tool I recently stumbled upon: A USB power delivery cable with a tiny built-in display that shows the power that is currently flowing through the cable. Ideal to see if a USB PD charger keeps what it promises and to get an idea how much energy goes into a battery. There don’t seem to be many manufacturers and I just stumbled over it by accident so I’ll make an exception and link to it on Amazon.de. Also interesting: I couldn’t find the product on Amazon.com. The image above shows the cable in action with a 65W USB PD charger connected to my notebook. Also, I tried the cable with a mobile phone with the same PD charger that requires 5V or 9V. It works as well and properly shows 15 Watts, the maximum the phone would charge with.

Fighting Buffer Bloat With OpenWrt and Traffic Shaping

Earlier this year, I discovered ‘wondershaper‘ a great Linux tool that configures traffic shaping on my notebook to fight buffer bloat on an upstream router. Without it, video calls and other interactive Internet use become impossible to use on some connections when sending large amounts of data in the uplink direction. This works on a device basis, so several devices in the local network, all sending data to the Internet at the same time, can still cause buffers to bloat in unsophisticated access routers. The solution: Apply traffic shaping on a local Wi-Fi access point that is inserted before the router where the bloat happens. It turned out that configuring traffic shaping on OpenWrt is a piece of cake!