A quick introduction: by day, I'm a DevOps Engineer at Red Gate, a software company in Cambridge, UK. Outside of work, I enjoy both amateur radio (hence the callsign, M0VFC) and community broadcast radio at Cambridge 105. This blog aims to span all those interests - so feel free to ignore the posts that aren't relevant!
Feel free to get in touch on Twitter (@rmc47).
73 / Best wishes,
Most modern processors allow their clock frequency to be scaled with demand: when CPU load is low, the clock speed is reduced, saving a considerable amount of energy. When demand is higher, it's increased, so performance should be unaffected. In theory.
Most modern processors also have multiple cores, allowing parallel execution of tasks, and increasing performance over a single-core processor of the same clock speed.
However, some workloads only make use of a single core - sometimes by their nature, sometimes because of the way they're implemented. On a 4-core CPU, a single-threaded task will consume 25% of the CPU - one of the four cores. This is where the problem starts. It seems that, at least on Windows Server 2012 R2, such a task will not cause the frequency to be scaled up, despite the task being CPU-constrained.
You can force the CPU to always run a maximum speed by using the "high performance" power plan, but this comes at the cost of increased energy consumption and heat generation. Here's an example:
Throughout the time of that graph, VMWare's OVFTool is extracting a virtual machine image. It's a CPU-bound operation, and single-threaded. The blue line on the CPU graph shows frequency; the green usage (as a proportion of maximum over four cores running at maximum frequency).
Approximately 75% through that period, I switched to the high performance power plan. This scaled frequency to maximum, and the result is clear: CPU use increases (because the single thread is now running at a higher clock frequency), and so does disk throughput. The task is now able to complete its work roughly three times faster.
It seems a little more intelligence in the frequency governor wouldn't go amiss for single-threaded workloads where clock frequency rather than the degree of parallelism is the main determining factor.
This morning, Cambridge 105 covered the Remembrance Sunday service at the war memorial on Hills Road, Cambridge. You can listen again to the coverage here.
We are no strangers to outside broadcasts, covering everything from the Cambridge Rock Festival to the Addenbrookes Hospital Christmas Concert, but this was a little different.
The war memorial stands in a very public location, and the adjacent roads were only due to be closed for a short period. This, combined with a need for our presence to be discrete and avoid distracting from the service, meant we opted for a completely wireless microphone rig.
The readings and prayers were given from a stand-mounted handheld microphone near the memorial - the only one the public were probably aware of. This also fed a pair of PA speakers (an independently mixed output from the broadcast audio).
The band of the Salvation Army was captured using a radio mic cable tied to a nearby tree when they were in their final position, and while approaching as part of a parade, another clipped to a convenient traffic light did the job. Finally, a shotgun microphone provided ambient crowd noise and filled in as required.
Julian Clover, presenting for the broadcast, wore a further radio mic as well as a wireless in-ear monitor. This meant he was able to move within the crowd to offer commentary on the proceedings while being able to hear the broadcast mix.
The OB went very smoothly, with the only real technical challenges being wind noise on microphones, and a slightly enthusiastic singer a little near to one of the mics during one hymn!
While operating at GB15NH, we managed to let the magic blue smoke out of two radios: Gavin M1BXF's IC-756ProIII, and my Elecraft K3.
The cause was entirely self-inflicted: our 20m and 17m antennas were probably 1m apart, and we didn't have a 17m band-pass filter to hand. We survived a day like this, but on the second day, the beams ended up facing each other, and this proved too much. The ProIII let out some smoke. We swapped it for the K3, which showed the "HI RFI" warning, then went suspiciously deaf.
A bit of searching online pointed to D25, a double PIN diode. Iain M0PCB also reported problems with D5 on the KXV3A board.
Inspecting D25 (on the bottom of the RF board, near the LPA) showed it looking a bit supicious, and trying to remove it to test led to it disintegrating:
D25 is a BAR 64-05 PIN diode, and costs all of £0.40 from Mouser - plus a £12 delivery charge for small orders! I ordered 10, to give me plenty of spares if it happens again...
The new part installed:
Everything sprung back into life, with a -40dBm test signal from the Rigol DSA815's tracking generator lighting up the S-meter to 9+50dB, a much more reasonable value.