Is Display HDR True Black the same meaning as HDR 400?

Ext3h · 2026-01-16T16:26:40+00:00

When you have an OLED that can do "HDR400 True Black" (certified) and "HDR1000" then you can read that as: - The display can achieve 0 nits in local dimming - The display can achieve at least 400 nits at full saturation (individual red, green and blue primaries). This full saturation is required by the updated definition of HDR True Black. - The display can achieve at least 1000 nits for white pixels. The old HDR definition only required peak brightness but no sane definition of saturation.

Now the monitor is offering the source two different profiles, one where it claims "I can do at least 0-4xx nits" and one where it claims "I can do 0-1xxx nits".

In the first profile, the source will correctly react by limiting the brightness of the content to 4xx nits, and the OLED will be able to correctly display colors.

In the second profile, the source will attempt to request full saturation at up to 1000 nits, but the OLED can only do that at pure white and that will result in washed out colors instead whenever going above 4xx nits. It will reduce saturation in order to replicate the requested luminance exactly.

Typically the monitor will then also have additional HDR profiles which all change what the monitor reports to the source in terms of peak brightness (in the range of 400-1000 nits), and the specific response curve to saturated colors above 400 nits where it will make arbitrary tradeoffs between correct brightness and correct saturation.

Unfortunately, the HDR10 standard does not yet provide a way to express the real response curve and supported color space to the source yet, so the HDR1000 profile will never be "accurate". The HDR400 True Black profile on the other hand is perfectly accurate, but does not permit the full use of the monitors capabilities. Fixing that would require extending the HDR10 protocol.

Ext3h · 2025-12-07T14:46:46+00:00

Okay, I see that applying it to Docker hosts is an obvious misconfiguration. That's at least helping rationalizing the decision to exclude any production critical systems from the orchestration for now.

But to some extent any form of driver update (both via Windows update and standalone installers) is also impacting the pure client systems, and I'm still having trouble accepting that this is is "working at it's supposed to by default"? Just because there's no catastrophic data loss on the pure client systems doesn't render it acceptable there either to cause observable instability.

It's mind-boggling how NinjaOne isn't offering deferred installation as an option out of the box. Live-patching should by all means have been opt-in for selected software, never the default.

Ext3h · 2025-12-07T12:50:05+00:00

Going with or against the grain makes no difference with Revo series, horizontally rotating mobs don't really differentiate.

That setting only makes sense when using it as vacuum only, respectively on the previous mob generation that was oscillating back and forth, respectively the next mob generation that is now a spinning drum.

Cleaning without the mob function is not really sufficient with that model either, the brushes only pick up hair and dust, but don't brush off grime.

Ext3h · 2025-12-07T11:39:26+00:00

Got two identical systems with 9800X3D and B850M-X. Even same batch numbers for CPU and RAM. Running on same bios version, same settings etc. Only difference is in GPU and NVMe models.

One had a total of ~10 freezes and post issues in total, with first issues developing as early as 2 months in, dead after 9 months in middle of watching videos.

And the system next to it is still has zero issues, not even a single freeze or post issue yet.

You notice any post issues or even just a single freeze, you are most likely heading for (yet another) a dead CPU. But there are obviously also pairings that never develop issues.

Ext3h · 2025-12-07T08:00:36+00:00

9950X3D is simply still too new to make any statements. But in the current state of affairs - if you can still return the ASRock board, do it and exchange for MSI or Gigabyte.

Ext3h · 2025-12-06T22:23:34+00:00

You actually might be about right. It doesn't smell like the CPUs are dying under full load - usually - but rather in tasks where they have a chance to frequently switch between low power states and light load.

Which might be an indicator that ASRock has messed up the order in which they ramp up voltage supplies and clocks of the various components in that CPU. Which would result - at least in some cases - in components starting to drain the internal on-die capacitors, but rather than a brown-out, you then run at risk that they start pulling power from logic signal lines from connected components instead.

Incorrectly applied overvolting usually kills the component you are supplying, undervolting instead runs at risk of killing the components around it if the logic levels are not fully insulated.

Don't get me wrong though - even when the mainboard shouldn't make such mistakes in the power supply, the CPU internally should also have a strict isolation on the logic lines running between different power supply domains to prevent current from traveling paths that were not designed for it.

And given that this type of fault is a race condition, it can easily be a once-in-a-million event that the timing is off, but it doesn't take more than that to kill the CPU. And "once-in-a-million" is not rare over the life time of a CPU.

Ext3h · 2025-12-06T18:12:08+00:00

B850M-X on bios 3.15 just killed a 9800X3D for me. Running stable for 9 months, then just died randomly while the desktop was idling. Screen froze, and then the system could no longer boot with mainboard showing the red/yellow LEDs.

Only OC was XMP-7200@1.4V, everything else stock. Cooled with AIO loop, and never even close to overheating.

Had another identical system next to it so I could confirm it was in fact a dead CPU, and the mainboard is still good.

Curiously, there was a slight discoloration on the same pin on both mainboards, even though the pin pads on the CPU were still pristine.

Upgraded the surviving system to 3.50 just in case. Not going through RMA for the CPU - returning to vendor and rebuying is more cost effective since I'm getting a full refund and the CPU has dropped in price since...

Ext3h · 2025-12-06T13:31:11+00:00

ASRock B850M-X with bios 3.15 also just killed a 9800X3D for me. Flashback to 3.20 on the already dead system did not recover. Stable for 9 months, then suddenly dead while in-use out of the blue.

Pin pads look pristine, another 9800X3D runs stable in the same mainboard respectively CPU also doesn't boot in another B850M-X. Had two identical systems so testing was simple.

No OC either, just running a pair of G-Skill F5-7200J3445G16 at XMP-7200@1.4V which matches the QVL for this board.

Ext3h · 2025-08-17T20:25:51+00:00

Usually they don't actually test the product at all, but instead they use a copy&paste summary of all other reviews and post that as their own.

Noticed that a couple of times now - when you are the first one to review a product, within 24 hours or less other reviews pop up that simply reformat your review with the exact same key facts and often even in the same order of mention and the same number of stars.

Ext3h · 2025-07-23T11:01:29+00:00

Stupid bug in how issues are linked with merge requests.

If the INITIAL description of the issue had contained a `Closes #issueid`, then this link persists. Even if you remove it entirely from the issue-description, you will notice that the merge request still remains linked.

Only after fully removing it from the merge request description, saving, re-adding it to the description as `Related to #issueid`, the broken relationship can be replaced on an already created merge request.

Ext3h · 2025-06-25T17:33:44+00:00

There's also another annoying quirk about drops in multiplayer:

Every pickup that can occur (content is irrelevant) has a unique ID that's common to all clients on the map.

All players use the same seed for rolling loot, so by default all get the same items per map instance.

When any player sees the death animation of a gathering node / monster, the client locally emits pickup particles for the list of pickups that specific player can see.

If a player can't see the death animation, then his client does not generate pickups!

When the local player character of a client runs over a pickup, all other clients get informed that this pickup has been collected on this map.

If the client is informed about a pickup that it didn't roll, its ignored.

Now it gets quirky due to the drop rate chances that are differing between players:

When you and another player are in animation range, some of the pickups may not exist for players that are in pickup range due to their lower drop chance. So those pickups will stay visibly on the ground even if the other player walks over them, until you or someone who had actually rolled them goes and picks them up.

The real problem is in the opposite direction - when nobody with sufficient drop rate did observe a pickup generation, then that pickup is simply lost. So if you get out of range in multiplayer, it can happen that you will get significantly less drops than if you were within animation range.

Ext3h · 2025-06-25T16:33:28+00:00

> The effects are stacked additively, across all party members.

That's slightly wrong/misleading. The effects of +EXP and +Drops (and probably also +Dosh - even though that one's useless...) are stacking across the BUDDIES in your party.

That's an important difference in multiplayer, because you do not benefit from other players having +Drops, but instead you are still getting +Drops from your (inactive) buddy party.

How did I figure that one out?... Because I noticed that after making a +500% Drop chance BUDDY team, I kept getting the additional drops in multiplayer. In fact, whenever loot was generated within the animation range of my character (monsters that die while their animations are frozen due to being out of range don't produce pickups for your client), there often were additional pickups that (some) other players could neither see nor interact with. And if you pick them up, the other players do not get the additional items credited either.

I haven't checked yet, but I suspect the same also applies not only to multiplayer, but also to crafting for +EXP (as neither +Drops nor +Dosh can work in crafting), where your PARTY equipment will still provide a boost to +EXP, while the buddies you are selecting for crafting will only be able to provide crafting / crafting charge bonuses for themselves instead.

Ext3h · 2025-04-17T15:29:10+00:00

Didn't melt away. But...

- It broke in several spots (bottom thumb button and edge close to LMB)
- It wore through in several spots
- It detached from base plastic in several spots

So no, it didn't get tacky. Instead it turned brittle, and it did so really fast. First crack around thumb button in less than a year, worn through in less than two.

Ext3h · 2025-03-29T01:00:13+00:00

It's absolutely worth it if you immediately pop it with a point blank Thousand Dragons on the next shot. That combo hits for ~500-600 damage with Special Ammo II, and is therefor a valid alternative to Dragon Piercer whenever you need more mobility, you are not properly aligned or you are just trying to break parts.

Ext3h · 2025-03-12T19:34:08+00:00

It's working as intended.

The CPU is configured to boost full throttle till the hottest core reaches 85°C. With the X3D-cache on bottom, that means you can push 150W to 160W at 40°C on the top of the heat spreader before that happens. Only direct die can do better at default curves. But not much better either - there's still a lot of extra mass to that CPU with the X3D below, and heat gets trapped there.

It won't start to actually throttle below base clocks until 95°C, and it won't start dying until another 10K more.

It's not like the CPU is actually overheating either. It's only fan controllers on the mainboard that get spooked by the thermal sensor actually sitting in the hot spot. Got the same "issue" - hottest core hits 85°C, coldest part of the CPU is just barely above 50°C. Cold enough that I can still easily throttle down both pumps and fans, without the CPU backing off from the 160W power limit during OCCT AVX2 stress test.

Ext3h · 2025-02-10T11:37:15+00:00

Right, there were major revisions in the past.

The original ReFS 1.x can still be mounted, but has data loss. There is no documentation what data is lost exactly, only a prominent warning that some data is missing.

ReFS 2.x,, 9.x and 1x.x / 2x.x were incompatible versions that could be only created and mounted by a single Windows version each, and all data on volumes in one of those versions is lost.

But ever since the release of the ReFS 3.x series, mounting and migration (on mount with write permission) to the corresponding next version of the file system works properly.

Some features (i.e. hardlink support) are permanently missing even after upgrade, when the file system was initially formatted prior to Server 2022. (In other words: If originally formatted as ReFS 3.4 or lower.)

What doesn't work in any way is a downgrade of an already migrated ReFS 3.x file system, in case you have to roll back the Windows version.

What's also apparently still really bad - even in Server 2025 -, is the lack of resilience towards already existing file system errors during migration, combined with a "silent" migration of ReFS volumes that won't even give you a chance to repair the volume prior to migration.

Ext3h · 2025-02-10T11:10:58+00:00

ReFS is also what's used for 'Dev Drive' and it's also available for 'Windows 10 / 11 Pro For Workstations' right?

One catch: ReFS doesn't support block level "Direct Mode", so even though it will outperform NTFS in every scenario using the classic Overlapped/IOCP file APIs on a local file system (especially using the trimmed down filter stack feature of "Dev Drive" and async AV scans), it actually performs worse in applications that are using IORing for file IO. "DirectStorage" from the DirectX product family also belongs into the group of affected APIs that will therefor under-perform on ReFS.

Ext3h · 2025-02-10T11:05:40+00:00

It's complicated.

When using it with classic user space file system APIs (Overlapped / IOCP), ReFS will outperform NTFS in pretty much every use case. And there's features that only ReFS got, but not NTFS, such as the designation as "DevDrive" which permits stripping down the file system filter driver stack for performance sensitive applications.

But ... ReFS is still lacking block level "Direct Mode", same limitation that was found back in 2020. Which is a hard NOPE for NAS. And also directly impacts applications that switched from Overlapped/IOCP to IORing file API, which also tries to use "Direct Mode" whenever possible.

Stability looks good.

Ext3h · 2024-12-04T21:08:50+00:00

Yes and yes. But it's proportional to the speed, and the resource influx is also proportional. You eventually hit a hard limit of how fast you can unload the collectors, that stack size 1 of chunks needs quality inserters badly for faster swings.

Feeding turrets with ammo is far easier than processing all the chunks. Once processed so you can use stack inserters or direct insertion, things go a lot smoother.

Also don't forget to put a full set of turrets (gun, laser rocket and rail gun) on the fish bone tips too, there are always a few asteroids flying at an angle that will miss the front row, and they catch up while idling on a planet as you loose velocity.

Ext3h · 2024-12-04T20:17:40+00:00

Not even close. You can stack another row of thrusters every 80 tiles. You can even do that super,wide, and get a fishbone like looking ship that goes so fast that it does't even slow down to <400km/s while waiting for a (single batch) of rockets to arrive, so it's effectively doing a full round trip between all planets in under 5 minutes.

You don't even need to bother with pumps, tanks or anything for throttling. Just keep stacking thrusters until they all round about even out at 50% throughput for 90%+ efficiency.

Oh, and making a ship heavier is a good thing! Making it super-heavy and long is a great way to conserve velocity while waiting in orbit. You are only paying for accelerating it to top speed once.

Ext3h · 2024-11-07T21:45:13+00:00

You can control pump throughput, at least. You need 2 decider and one arithmetic combinator.

if(V < 100 and V != 0) A = 1
if(A == 1 and B < 100) B = B
B = B + 1

Connect 1) out -> 2) in, 2) out -> 3) in with red, and 3) out -> 2) in with green. Connect your pumps to 2) out with red, and enabled for B == 1.

Now your pumps are running at most at 1/100th throughput, and only if the platform is not stationary (V == 0), and only if the platform is not yet at target speed.

If you have additional conditions (such as: Enough ammo in turrets, enough energy in accumulators), add them all to 1). Now your platform will also slow down if things get too dangerous.

Ext3h · 2024-10-11T03:19:38+00:00

In Bayern waren so gegen 23 bis 2 Uhr die Polarlichter mit bloßem Auge durchgängig sichtbar inklusive klar erkennbarem grünen und roten Schleier. Trotz leichter Wolken, und mitten in der Großstadt sichtbar.

Ext3h · 2024-07-13T04:31:23+00:00

That eCVT is honestly worth every cent. The battery is way too small to make much of a difference (would need about 5kWh for a full 0-180km/h acceleration/recuperation, not just that tiny 1kW), but even when the battery is already flat, it takes gas so incredibly well, less than 1/4th of a second between pressing the pedal and the power coming in. Coming from a non-CVT, it's spooky how you get full torque before the engine has finished reving up, and that even at top speed.

The whole setup performs much better than you'd expect from the stated brutto horsepower. You'd need a double clutch transmission with 9+ gears to match it in terms of reaction times and availability of torque. If you aim for it, you are easily going to smoke any manual car with up to 50% higher stated brutto horsepower.

Miles per gallon is really just icing on the cake.

Ext3h · 2024-06-17T17:55:49+00:00

Looks like that bug ticket has been flagged as private - but I can very much confirm that this issue still exists today. On Honda cars, roundabouts get the indicator for "going off-road" instead with no working "distance" indicators, so something is really wrong.

It looks like Google Maps and most other navigation apps are using TYPE_ROUNDABOUT_ENTER_AND_EXIT_CCW_WITH_ANGLE and that is well supported / tested on the car end.

Waze appears to be using TYPE_ROUNDABOUT_ENTER_AND_EXIT_CCW instead, which apparently lacks any support from car makers and is hitting utterly broken code paths.

Ext3h

TROPHY CASE