Fixing Bits of pbarwin.cpp

I got to test out pbarwin.cpp on Edythe-III and found a couple of interesting side cases. The key difference between Edythe-III and Eileen-II is that the former has two batteries while the latter doesn't. That introduces issues like whether the battery enumeration will show the missing battery (it does), and what happens with respect to the different charging. I had anticipated some of these issues before hand and wrote up the mitigation, but nothing beats actually testing it on a true situation.

I had to fix one of the indicator mechanisms that I was using for the ``small battery gauge''. Here's a ghetto-photo version of how it looks like after fixing:

The original way did not show any of the filled out bar if there were any such indicators, which made it quite confusing to determine in this case which battery is being charged, and at what level it was on. While fixing that, I managed to update my source code to use std::fill() over the ghetto-C way of using a for-loop to fill it up (the ``hardcore-C'' way is to use memset()).

Going back to the ghetto-picture, let me highlight the changes. I added the indicator sigils for the small battery gauge: `>' is for charging, `!' is for critical status, and `?' is for unknown status. I also have a contextual output of hhh:mm:ss that shows either the estimated time left to fully charge the current battery, or the estimated battery life left for battery discharge. It becomes ---:--:-- if the batteries are not charging/discharging, and if it is running on AC power. That was a feature that I didn't update into pbarwin.py that I could somewhat more easily pull off now.

That's about it for now. Till the next update.

Typematic Rates

Okay, let's talk a bit about typematic rates.

The idea of a typematic rate is simple: when a key is pressed and held, there exists some amount of delay after registering the first key-down event before the operating system decides that the key is considered to be held and should emit the same key code repeatedly at a given rate. The most obvious manners in which this shows up is from using the arrow keys to navigate through a document, or to move the cursor/caret back and forth horizontally through a line of text, or to delete/backspace through a whole bunch of text.

Or if one uses the keyboard to play computer games, any form of keyboard-related navigation will reveal this behaviour as well.

With that out of the way, let's talk about how these two parameters (delay, repeat-rate) can be adjusted.

In the old days of DOS, one would use the mode command in the form of

mode con rate=32 delay=1

to set the keyboard repeat rate to the highest value [of 32] with the lowest delay [of 1]. The rate is given in units of characters-per-second, or just Hertz (Hz), while the delay is provided in units of 0.25 s. So the most rapid that the keyboard can go is 32 Hz (31.25 ms) with an initial delay of 0.25 s (250 ms).

When Windows came about, there was a new keyboard repeat rate/delay control mechanism. This can be easily reached through Windows+R, followed by typing ``control keyboard'' in the ensuing box. This will bring up the ``Keyboard Properties'' dialog box, where the typematic rate is to be set under the ``Speed'' tab. Instead of hard numbers like the mode command, we get sliders that state delays from ``Long'' to ``Short'', and then ``Slow'' to ``Fast''. A cursory search did not reveal any information about any exact numbers here, but considering how the values seem to mimic the range of the old mode command, I will assume that they are similar. I will get to why I believe so in a bit.

Anyway, eventually though, even the fastest settings that were available felt sluggish to me, and I don't mean it just in the ``repeated key hold'' sort of way. Even regular typing was starting to feel sluggish, and this is after applying the ``performance tweak'' (deselecting ``Animate controls and elements inside windows'' under the ``Visual Effects'' tab from the ``Performance Options'' window that is called from the ``Settings'' button under the ``Advanced'' tab of the ``System Properties'' window) to force the newest versions of Microsoft Office to not fuck around with the apparent cursor speed with their ``smooth animation'' bullshit that completely deconstructed the responsiveness of cursor movement. Maybe it is because my typematic rate has increased, or maybe it is due to the higher refresh rate of the screens that I am working on, but no matter the reason, the 32 Hz (31.25 ms) repeat rate with 250 ms delay was no longer cutting it.

I had to go faster. But how?

Salvation came from a completely unexpected source: FilterKeys. Traditionally, this is one of those options that any person who games will want to look at immediately because of the triggering shortcut: holding the shift key for 8 s, an action that will often happen when one is trying to run for long periods of time in an FPS. FilterKeys when activated normally are bad for the reason that they tend to drop extra keystrokes as part of their accessibility slant---it allows people who have unsteady typing to have longer delays in between the emission of key code events to allow their slower finger movements to not generate spurious characters especially in typing.

But FilterKeys have a dark secret: they actually provide a means to fine-tune keyboard-related settings down to millisecond precision. And because of that, I have been using the following registry tweak to obtain my favoured typing rate:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response]
"AutoRepeatDelay"="188"
"AutoRepeatRate"="10"
"BounceTime"="0"
"DelayBeforeAcceptance"="0"
"Flags"="59"
"Last BounceKey Setting"=dword:00000000
"Last Valid Delay"=dword:00000000
"Last Valid Repeat"=dword:00000000
"Last Valid Wait"=dword:000003e8

The delay is now set to 188 ms instead of the 250 ms lowest value available, while the repeat rate is set to being every 10 ms (100 Hz) as opposed to being every 31.25 ms (32 Hz); a 25% shorter delay with slightly more than 3× the repeat rate---this is extremely noticeable. It really makes my typing much more comfortable than before.

That would have been the end of the story for today's post, except for one thing: there were some games on Steam that mysteriously destroy my keyboard settings after I exit out of the game. I could restore the typematic rate, but it would require me to log out and back in again to effect the changes that were in the Windows Registry. The notorious game that kept giving me this problem was N++. It was very problematic because I liked to play N++ in short bursts instead of having a long marathon session as a means of relaxing in between through a paradoxical hyper-concentration process on something completely unrelated. It started to get old each time this happened, and eventually I was annoyed enough that I uninstalled it from Edythe-III and never installed it on Eileen-II at all.

Unfortunately, my favourite game, Jupiter Hell started showing similar symptoms recently. I didn't want to have it go the way N++ did, and wondered if there was a more direct way of making the change happen without having to log out and back in again. It led me to the SystemParametersInfoA() Windows API using SPI_GETFILTERKEYS/SPI_SETFILTERKEYS with associated information set in the FILTERKEYS C-struct. I wrote a simple bit of C++ code and compiled it with g++ in Cygwin, where I had my Win32 API headers installed. The first thing I did was to use SPI_GETFILTERKEYS to probe and output the information for FilterKeys both before running Jupiter Hell and after to see if my hypothesis was true.

And yes, the probe program proved that the FilterKeys settings were nuked after running.

I brought it up to Kornel, and we had a discussion about it. Turns out that the upstream library used to support the changing of keyboard typematic rate from within Jupiter Hell did not actually preserve the original settings due to various technical reasons, and there were some strange Windows-based fuckery that would randomly trigger off the keyboard-related accessibility options. There was no obviously elegant way of solving this in a portable fashion in time for the full release, and a quick fix which nuked all accessibility options was done to ensure that most people would not be affected by it.

Converting the probe program into one that would set the values that I wanted was quite straightforward---the only thing left was to see if the changes would stick. I mean, it's so straightforward that I can put the code (with my personal settings as talked about earlier) here:

#include <windows.h>
#include <winuser.h>

#include <iostream>

int main(void) {
  FILTERKEYS filterKeys;
  BOOL fResult;

  filterKeys.cbSize = sizeof(FILTERKEYS);
  filterKeys.dwFlags = 59;
  filterKeys.iWaitMSec = 0;
  filterKeys.iDelayMSec = 188;
  filterKeys.iRepeatMSec = 10;
  filterKeys.iBounceMSec = 0;

  fResult = SystemParametersInfoA(SPI_SETFILTERKEYS, 
      sizeof(FILTERKEYS), &filterKeys, SPIF_SENDCHANGE);
  if (fResult) {
    std::cout << "Success." << std::endl;
  } else {
    std::cout << "Failed." << std::endl;
  }

  return 0;
}

I compiled it, ran it, and double checked with my probe program. It works perfectly.

So now I have a perfectly working workaround to handle this issue without having to do the log out/in dance. And so, N++ has been installed on Eileen-II now.

I think that's all I have for today. Till the next update.

Nomadic Programming with Eileen-II

Okay, something a little different. This was written on Eileen-II, but outside of the apartment, and definitely not plugged in, i.e. just running on batteries.

I just wanted to see how long Eileen-II could last without being plugged in, doing some programming, the kind of things that I would normally like to do when I'm roaming outdoors and wanting to do something more different from just reading.

I must say, the battery life is... interesting. I unplugged Eileen-II at around 0900hrs, packed her away, went for the Good Friday service at church till about half-past noon, then set up shop at Morganfeld's @ Buona Vista at about 1254hrs. At that point, the power had fallen to around 91%. Eating/reading for about 30 min, then I spent the rest of the time working on Eileen-II, with only the tethered Wifi turned on only at about 1602hrs.

As at 1640hrs, the battery is now at 62%. So it works out to around 7% or so of battery capacity per hour of ``active'' work.

That's actually not too bad. In fact, considering the heavy machinery that is within Eileen-II, I am rather surprised at just how well the battery life is. Eileen-II also fits in my back-pack---I was a little worried because she is 15", as compared to Edythe-III who is around 13.3".

Now, for some more gory details.

I set the Windows power plan to using ``Balanced'' instead of the hidden ``High Performance'' setting. In addition, I used ThrottleStop again to adjust the offset. The old value that I was using was −90.8 mV, which was too aggressive---I kept Eileen-II up overnight while setting a tool to monitor the CPU voltages. The lowest untouched CPU voltage that I saw was around 0.56? V. I knew that any CPU voltage lower than 0.500 V was an issue for display instability, and with the recorded value, I decided to undervolt just enough to give myself about 0.02+ V of leeway.

So I undervolted to ``only'' −40.0 mV instead. I left all the TurboBoost ratios back to factory defaults for all four profiles, reasoning that I don't care about spikey high temperatures (with the workaround of using an external keyboard to play games that ended up using all cores all the time), but deliberately set them to the tweaked versions for the profile that was designated ``Battery'' in ThrottleStop. I also set the SpeedStep EPP to be more aggressive in down-ratio---a setting of 255 instead of the default 128.

So far, everything seems good. I'm not going to complain.

In many ways, I think that CPU design has really evolved quite a fair bit compared to the old days of the 80486/Pentium. The last time I studied CPU features in such detail was back in my undergraduate years, when I was still actively studying CPU design to better understand them for programming. But in those days, I was looking at CPUs from the perspective of performance rather than the balance between performance and being power efficient. CPUs have gone a really long way in that department---I was still under the mentality that a single battery charge can last a laptop at most 4 hours brand new, with an average use-time of about 3 hours before degrading down to just 2+ hours.

And just as I hit the publish button, the power capacity is 59%.

That's all I have for now. Till the next update.

Eileen-II with Hyperthreading and Lowered Temperatures

Okay, I left it as a question. The answer to that is ``no''.

I think this though is the final solution to Eileen-II's temperature issues.

First, let me put up the final numbers, then I will do the explanation:

Okay, the last time I was talking about this, I mentioned that for heat-related issues, I had turned off hyperthreading, undervolted by 90.8 mV, and adjusted the Turbo Boost ratios to [40×,39×,35×,33×,31×,30×] for 1 to 6 active cores respectively. This was all done through using Prime95 as the load-tester, and ThrottleStop as the adjustment tool.

All that work meant that the peak temperature of Eileen-II's CPU never exceeded 85°C.

That is all well and good, but as I continued to use Eileen-II, I realised that I was losing some performance from the lack of hyperthreading. Specifically, the benchmarking from WinRAR under multi-threaded computation was giving me a rough throughput of 7 MB/s. It is definitely faster than the 4 MB/s processing speed of Edythe-III, but is actually quite bad, especially since I seem to be operating on RAR files pretty often (in the form of archiving e-books, and compiling comic book archives from web comics).

I remembered that with hyperthreading on, I was getting more than 10 MB/s of processing, or something like 14 MB/s, if memory serves me well---this is anything from 42% to 100% improvement over no-hyperthreading (I'm not much of a speed demon and am not really going for something super rigorous, and so a rough ballpark is good enough for me).

With the system relatively stable, and me getting rather bored(!) at 0000hrs in the morning, it is back to more recalibration to squeeze more output.

I turned on hyperthreading from the BIOS, and proceeded with the same methodology as before. Since I was about to load my processor with about 100% more load, it seemed prudent to undervolt as much as I can to reduce the initial pre-stress thermal load as possible. I started at −90.8 mV as it was, and gradually lowered it by 1 mV for both CPU Core and CPU Cache, waiting each time for a lowered idle CPU use to drop the voltage enough to test for stability---remember that when undervolting the CPU, we are finding the lowest effective voltage that does not stall the CPU.

I managed to lower it as low as −98.8 mV, however, the results were unstable, with the screen flickering when the voltage dipped low enough to ``stun'' the CPU into cranking its voltage higher up. Getting low-enough idle CPU use with hyper-threading on was very finicky and hard, and it was at −99.8 mV when I hit my first blue screen of death. It was funny, because the main display was showing the blue screen, while the side display [that I use for reading PDFs---see this earlier entry for details of that display] was still showing the desktop background.

When I finally rebooted Eileen-II, I noped out and just cranked the offset voltage to −92.8 mV, a number that I was confident that would not allow the lowest voltage of the CPU to drop below 0.5 V---I noticed that when the voltage dropped lower than 0.5 V was when the screen flickering would start and things would Get Weird.

Armed with that new offset voltage, I started up the stress tester and ran the same protocol. With the original turbo ratio limits, I was (as expected) getting very high spike temperatures in the 90+°C range. And so, I used the same protocol as before to fine tune the ratios for the n hottest physical cores, for n in 6 to 1.

Due to hyperthreading being turned on, I needed to alter the protocol a little, and adjust the affinities by the pairs of logical CPUs that would run on a physical Core. Thankfully, the formula relating them is straightforward enough. Each time after tuning, I would just take away the two logical CPUs for the coolest physical Core in the affinity, and rinse/repeat.

The final turbo ratio limits were [37×,34×,32×,31×,29×,28×]. On average, I would be taking away anything between 1× to 3× from the original no-hyperthreading tuned ratios.

It sounds like I have reduced my CPU's capabilities through all these lowered ratios, but really I haven't, since hyperthreading meant that I was getting double the number of processing cycles per active physical Core. Take 6 active cores for example. Without hyper-threading, the total work done in ratio of base clock speed is 6 by 30×, which is 180×. With hyper-threading, the total work done in ratio of base clock speed is now 12 by 28× which is 336×, which is about 87% more available raw clock cycles in comparison to being without hyper-threading, with similar thermal loads (≤85°C). Of course, hyper-threading doesn't quite work that way since there is an actual overlap from synchronisation issues of hyper-threaded CPUs that share the same physical Core, but the point remains that I am increasing the total available capacity for the given generated thermal load despite having lowered turbo ratios.

Oh, and all these led to WinRAR benchmarking at about 13 MB/s compared to 7 MB/s, an overall 86% increase in throughput between no-hyperthreading and with hyperthreading. So, it is more performance overall, in the multi-threaded case.

Definitely a win in my book. By the time I was done, it was already 0145hrs...

------

In other news, I had finally updated my LilyPond installation from v2.20.0 to v2.22.0. The reason for the delay was waiting for Cygwin version to be updated first before updating the tooling for my Windows version that I use with Frescobaldi for music writing. The reason for that is due to my auto-building scripts being designed to run under Cygwin or Linux.

Well, v2.22.0 broke all my sources for v2.20.0/v2.18.0. Reading the changelog revealed that a couple of features that I used, namely \compressFullBarRests and \partcombine, had been renamed to \compressEmptyMeasures and \partCombine respectively, with no real backward compatibility despite the existence of the \version statement.

It was a straightforward enough fix, and I completed it using my favourite combination of

find -type f -iname '*.ly' -print0 | \
  xargs -0 sed -e 's/\\partcombine/\\partCombine/g' -i

No biggie, but it was something that needed to be done.

Alright, that's about all that I have to write for now. Till the next update.

Chomp Chomp & [No] Hyper-threading

I needed some sunlight today, and so, I went out of the apartment to meet up with my friend for a late lunch out at Serangoon Garden Market & Food Centre (SGMFC in this entry). This is the superior food place compared to the [in]famous Chomp Chomp Food Centre that is within walking distance of the previous one.

The superiority of SGMFC against Chomp Chomp comes from three big points:

1. Wider variety of food types for selection;
2. Much more open and airy feel to it;
3. Lack of an ``oppressive'' feel.

For comparison, when my friend and I were at Chomp Chomp, the seating was very claustrophobic, and there was even a police presence---how much more ``oppressive'' can it get? All that seriously undermines the type of good/open food centre that one is more accustomed to in Singapore.

The unfortunate thing is that SGMFC seems to be too much of a mouthful to remember, and is often incorrectly referred to as ``Chomp Chomp'', which was why when my friend suggested that we ``met at Chomp Chomp'', I counter-offered just waiting for him at the bus stop at the circus instead, since all the buses that entered that general region would end up stopping there. As it turned out, it was the right choice, since he really had meant SGMFC instead of Chomp Chomp after all.

We spent some time trying the different foods at SGMFC. I had some kway chap, some beef hor fun, some ming jiang kueh, and some soya bean drink with dessert of grass jelly with attap seeds. We then walked about the roads just seeing what was available, including entering the myVillage mall off Maju Road. The last time that I was at myVillage was nearly ten years ago, when I was much more active in the Singapore Geocaching scene. The place felt much smaller than I had remembered, and I think it was partly due to how the roof-top garden was cordoned off for whatever reason.

All in all, it was a nice couple of hours outside of the apartment.

------

In the first month of my sabbatical, I have basically come up with some kind of rough routine for myself to ensure that it is both productive and restful for me. Roughly speaking:

1. No zero days---I need to do something each day.
2. Weekly, attend church services.
3. Daily devotionals from Bible in One Year 2020 with Nicky Gumbel---am already on Day 285
4. Daily reading from my reading list.
5. Daily, either play some music, or play some video game.
6. Daily, try to write something, either a piece of music, a poem, a story, a computer program, or a blog entry.
7. Weekly, get out of the apartment to do something different, or meet up with someone.
8. Keep to OMAD for at least five days each seven-day week.

I think that is a pretty good set of activities to keep me going.

The thing about sabbaticals, I feel, is that there is a need to get some manner of new stimulation back into one's life to ensure that there is actually some thing that can lead to change. As an old programmers' adage goes, insanity is doing the same things and expecting different results. If doing the same things were making me happy, then I think there would be no need for a sabbatical in the first place.

Doing new things for new stimulations isn't the same as running away from an old life though. It has all the hallmarks from running away from an old life, but is different in the sense of the intention---it is not about running away from an old life, but discovering how to run towards a new life. For me personally, this is really about how to reshape my new life such that it is more Christ-centric.

``Hol up MT,'' one might begin, ``I thought you weren't the religious sort. Why are you starting to talk about this `Christ-centric' thing like you are one of those fundie-goons? Have you lost your marbles?''

No, I have not lost my marbles. One of the things that I have realised over the past fifteen years or so is that greed is the one big reason why things are the way they are in the world today. But to overcome the basic nonsense that is greed requires a different perspective, a different 座右铭, or motto for those of us who are not so conversant in Mandarin Chinese. There are many different ways of creating/finding/discovering such a motto, but for me, the idea of leading a Christ-centred life-style is the one the makes the most sense.

Am I disdaining other people's beliefs? No, you are free to think what you want. I know what I believe in, but it is not my place to force what I believe in on you, even though I may think that you are wrong. Belief is about faith, and faith is not science---the evidence behind faith is qualified through personal experience and third-party testimonies of experience and not quantified through repeatable and falsifiable hypotheses through the Scientific method. Faith is not something that is debatable, principally because faith defines the axioms from which all other reasoning (via regular logic) stem from.

Thus, to ``debate'' about faith is an impossible and unproductive approach---by definition, we can already have issues with agreeing with what are the basic tenets (axioms) that are innately true, and proceeding from there would just be a terribly angry waste of time by all. But I digress.

The reshaping of my new life through the filling of the emptiness within from the rejection of greed is one of the key reasons behind the need of a sabbatical. Mayhaps all that has happened thus far (the break-up of a five-year long relationship, the strong ``push'' factors out of my previous job) are mere pointers leading to this moment where I start to really think and meditate about what it is I want out of my life.

After all, I have been surviving on ``magical coincidences'' for too long, I think. Eventually, luck can and will run out, and at that point, what happens? But I will leave that discussion for another time.

------

In other news, I have decided to turn off hyper-threading on Eileen-II. Recalling the specifications of Eileen-II, she sports an Intel i7-10750H processor (6-core, 12MB cache, up to 5.1GHz with Turbo Boost). With hyper-threading on, that 6 [physical] cores appear as 12 [logical] cores, which, in theory, improves the overall throughput by reducing the idle time on each of the cores. So in cases where there are a lot of ``light'' threads that need to be run, hyper-threading can be a good way to squeeze out some extra level of performance.

It all sounds great, but I had been carefully monitoring the temperatures of Eileen-II while I was running The Outer Worlds. The GPU temperatures are generally alright (sub 80°C), but the CPU temperatures were ridiculous (staying at 95°C, spiking to 100°C where the turbo-boost from 2.6GHz to 4.7GHz was throttled back to about 3.5GHz sustained). Bear in mind that I am operating Eileen-II in a semi-open air apartment in hot and humid Singapore with no air-conditioning. Excess thermal energy is a big deal---running components that hot for too long is a great way to get the effective life span greatly reduced.

Anyway, I did more reading up, and realised that the hyper-threading model was not the right computation model for the types of loads that I was throwing at Eileen-II. I don't have a tendency to run many small tasks which use many threads---I tend to throw one or two heavy tasks at once instead. And since I actually have six physical cores (as opposed to the two physical cores of Edythe-III, hyper-threading is not a good trade-off.

With hyper-threading turned off, I was getting much lower CPU temperatures (about 80°C now), and not much change in GPU temperatures (still sub 80°C) while running the same The Outer Worlds. That's a big win for me.

I did not notice any slow downs or anything. That's also a big win for me.

And thus, that is my current set up for Eileen-II.

I don't have anything else to add for now, and so that's all for today. Till the next update, I suppose.

Eileen-II and Other Stories

To say that the past week-and-a-half is a roller coaster is a bit of a cliché, but it is an unfortunate consequence of my lack of imagination in the use of the English language. Let's see what I can say here today.

I've bought a new 22-inch 16:9 monitor from Dell (P2219H) that can swivel, and is primarily set up to be vertical in nature. No name for this device, though it can technically be called ``Eirian-V'' since its role is similar to the Eirian series of devices---but I'm not going to. The problem I was facing was the reading of certain PDF forms of e-books that had the two-column layout. On a normal screen, no matter what resolution and dimension, if we keep it in the usual landscape format, each column ends up taking up at most one quarter of the screen by width. It is basically unreadable. What I needed was something that had more physical dimension in the height department. I could get a tablet like Eirian-III, but I didn't want to have to lug it around with my hands just to read the document---I have grown used to the smaller form factor. Eirian-IV has superior pitch density, but even then, it can be a challenge to read really tiny text that was supposed to be ``normal sized'' in a more traditional A4/letter sized setting. And so, the monitor was obtained.

Edythe-III is still hale and hearty, but her 3-year warranty is almost up. And if the behaviour of Edythe-II was of any indication, it was clear that I needed to get a replacement soonish. At the same time, Elysie-II was starting to become a little... unstable, partly because of age, partly because of hardware (old school spindle HDD), partly because of software (Windows 7), and partly because of circumstance (it was hard/impossible to head out to the venerable Sim Lim Square to source for parts, with the COVID-19 pandemic raging and stores closing left and right). So I decided to spend a little more than what I had originally saved for and get a new iteration of Eileen, now known as Eileen-II.

So, what's Eileen-II?

She's an Alienware m15 R3, with an Intel i7-10750H processor (6-core, 12MB cache, up to 5.1GHz with Turbo Boost), 32GB DDR4 RAM at 2666MHz, and an Nvidia GeForce RTX 2070 Super 8GB DDR6 discrete graphics card. Her screen is 15.6" (1920×1080) with a refresh rate of 144Hz, and her storage is a 1TB SSD.

Her specs are on par with Elysie-II in many ways, except for a slightly better parallelisation capability with 50% more cores and a faster secondary storage, and a much more portable form factor (laptop vs desktop). She's pretty portable for a stronk person like me, but I think I may actually need to use the provided carrier bag instead of whatever I had---she is a little larger than the 13" laptops that I have.

For a portable machine running the specs like the beast that is Elysie-II, Eileen-II runs surprisingly cool. Let's hope this continues.

------

On more different matters, it had been quite trying for the past week-and-a-half. Work had some extra certification thing that needed to be done to address a tender, and I was tasked to get it with a colleague. The whole process was a little harrowing, partly because the item that we were getting certification on wasn't exactly directly aligned with my interests/area of work/domain of expertise per se, and partly because of the super shortened duration we had to actually prepare for it, even though we managed the expectations of that to have two attempts instead of the one that was originally envisioned. Then there was the need to book a time slot to actually take the certification exam---it had to be online proctored, and the only time slot that fit the original planned schedule was at six in the morning (or any time between three and six in the morning in roughly fifteen-minute intervals). Thankfully it is now over; well it had been over since the Wednesday just passed. I passed by the grace of God---the score I had was exactly the one needed to pass, no more and no less. Just to be clear, this was one of those exams that the passing grade was a ``high'' percentage that was not fifty percent.

The Friday before, I had a near breakdown. I don't know why---suddenly I felt completely useless for some reason. I felt as though I would just fade away if I didn't pay attention to myself. I think I was just overwhelmed with the stress of not willfully failing that certification exam, and the combined stresses of a general lack of coping mechanisms (no Chinese Orchestra rehearsals, no meet ups with friends, no more confidante in general) with additional social stresses (what is the new norm for me now that I am a believer, am without a wife-to-be-candidate, basically having my life rewritten to the past) meant that I just sort of lost sense of where I was. I mean, yes, I'm a believer now, I know God is with me because I've chosen to walk with Him in my life, but I'm still a neophyte in the ways of Christ, and more importantly, I'm still a mortal.

Given all that I felt, I did something pretty uncharacteristic; I posted a plea for reassurance on my ``wall'' in Facebook.

I am really heartened by the responses that came in. Friends, colleagues, and even acquaintances started coming out of the wood work to send me private messages, asking my well-being, and giving me really positive encouragement that I had indeed impacted their lives in a positive way during the times when we were walking closer together than now.

I teared up. I tear up still. I wasn't expecting all that love and concern to come in like that. Don't ask me why---I don't know. I've never really had these kinds of feelings before.

It definitely helped ground me back into reality. That I was, and am here.

------

On yet another note, I've also bought some Oval-8 finger splits by 3-point products. They are for my two pinky fingers---they have a mild form of swan neck deformity. They only show up when I need to be playing the dizi or when I'm going for the pinky-notes of the right hand (instrument C♯, C, B), in which case it is bad. Most of the time I don't have to actually ``stretch'' my fingers, but under those circumstances highlighted, I have to, and it is a problem. The Oval-8 finger splits block the middle joint from bending backwards, which allows me to safely stretch out the pinky without jamming the joint up. It is super useful. I first learnt of them at the Flute Forum on Facebook, and bought mine from Fu Kang, a Singapore company.

And that's about it for now. Till the next update I suppose.

Goodbye Edythe-II

The inevitable has happened. Edythe-II decided to give up the ghost about a fortnight ago, and I was stuck in a strange position of not having a portable machine to get [some] things done.

I was, by no means, completely machine-less, since there's always Elysie-II to fall back on. But it is different---Elysie-II was built to be a gaming machine, and as a result, had much of the set up favouring that of playing games than actual working. Explained simply, it meant that the set up was more amenable to having wonderful visuals and large-ish text over the tiny text that I would use for ``work''-related manipulations.

The failure of Edythe-II came very suddenly. The night before, I suspended her and went to sleep, and by the next morning, it was no longer possible to wake her up. I tried various combinations of power/power button manipulations, but none of them were working. In the end, I had to go back to technical support because it is fast becoming apparent that there was a hardware issue that I had no chance of resolving on my own.

Later tests confirmed that it was a motherboard issue, and the price in replacing it was high enough that it didn't make any sense for me to do so when I can triple the amount and get a brand-new replacement with three more years of warranty (Edythe-II's warranty was just expired by 2 months, which led to the really crazy high price for the replacement).

So, what is Edythe-III?

She's a Fujitsu S937, Intel Core i7-7500U, 8GiB RAM (8GiB soldered, going to get a 16GiB RAM stick to max it up to 24GiB) with Intel HD Graphics 620. Her form factor is almost identical as that of Edythe-II, but with ``worse'' display (instead of 2560×1440, we're looking at 1920×1080), and ``better'' storage (Crucial 525GB SSD as primary storage as opposed to the original 1TB HDD---it was an upgrade that I decided to get because I realise that many things that I was doing had a lot of disk I/O, and so having an SSD is likely to improve the performance). Writing and compiling are the primary tasks that I do on the Edythes, so an SSD would make everything run much better. The original HDD is not tossed into the bin---it is going to live its life in the modular bay HDD kit to act as secondary storage for when I intend to sit down somewhere and stay plugged in (i.e. less need for the modular bay battery).

Thus, after three years of glorious Unifont use for the console, I'm back to using the Proggy series or even the Tom Thumb-esque font. I haven't actually managed to successfully convert that into a form that Windows can use, so I'm likely to be using Proggy (8×8) or some 5×7 font instead.

My biggest pet peeve is that I am literally stuck with Windows 10 with no reprieve. I did my best to reduce the amount of suck it could generate, but I have no idea just how much of it I managed to avoid through careful reading and adjusting of the underlying configuration settings. Classic Shell is a definite must, but even then it seems to act a little buggy with regard to the start menu.

Only time will tell.

And that's all I have to write about for now. It's really says something when the only times I have a ``proper'' blog entry is when something bad happens.