Videos for April 25th - May 1st

Alright I'll check it out, downloading now.

possibly even more up to date in terms of support. Ubuntu 22.04 comes with kernel 5.15 and my Gentoo install has kernel 5.17.

Biking With Panda

I guess part of the issue is I need to use stuff that's quite up to date in order to work on bleeding edge / the latest laptop hardware, haven't used Gentoo in over a decade, but is the live CD as up to date as say Ubuntu in regards of kernel / component support?

there's a distribution called Gentoo that produces probably the best Live DVD as it has the most options for things to run. if you could, i'd also suggest factorio and geekbench5 be added to the mix as the numbers across platforms are highly comparable and reliably so.

Biking With Panda

it works on Intel and Ryzen, and.. https://www.reddit.com/r/programming/comments/nyus01/if_youre_measuring_time_using_rdtsc_in_the/ on mac you can see some really crazy stuff on the M1 platform. the commands for available_clocksource and current_clocksource will work on any system running Linux, even the more exotic stuff.

Biking With Panda

That's interesting, thanks. Will this work on both Intel/Ryzen systems? Does the OS matter? I'm currently in between choosing what I want to test with. I tried to move to PopOS but it doesn't boot on some laptops, can't work out why, so might just try Ubuntu 22.04 going forward, though I still found that didn't work with Wi-Fi in the new Razer Blade 2022 out of the box. I don't have a whole lot of time to do this testing, so just use a live CD without fully installing/updating. If I can just run these commands in what ever OS I'm using on any platform then I could give it a mention.

another issue with the XPG Xenia 15 KC system that I'd picked up last month, in Linux the display is limited to 40Hz due to the Intel GPU drivers (i915) being bad. detectable by running 'glxgears' and seeing only 40fps, or, trying to play Factorio and having framerate issues (in .... Factorio... seriously, lol)

Biking With Panda

hey jarrod, i joined here so i could write a comment about your Linux compatibility testing that you do with the laptops i have been using Linux as a desktop since 2005 and had done some kernel development for 5 years, as well, I just think it's a pretty cool environment that has a lot to offer. that said, i certainly don't blame you for your approach. it's pretty cool that you even consider Linux support as a mention at all, and most of your audience will really only care about whether the main bits work at all, and not any of the more esoteric underlying issues that may exist. there's a few "gamer-centric" issues on Linux that I've encountered, and the first one would be, the kernel clock source. you can get an explanation of what "RDTSC" CPU instruction set is for, but the bottom line is, some configurations of notebooks have an "unstable TSC" which causes a fallback to the HPET (High Precision Event Timer) which has about a 30x slowdown when a task has a lot of calls to gettimeofday() I discovered this on my Lenovo Legion 5 Pro, and when watching your video on a laptop, I was thinking it'd be a pretty good thing to note, if you detect clocksource instability on a certain notebook. For one, this would help anyone who wants to avoid ANY potential instability and just wants the BEST experience out of the box. For manufactures, I don't know that they're all AWARE of this issue, and maybe you mentioning it will bring it to the top of more people's minds. Anyway, to detect an instable TSC, run the following command: sudo dmesg | grep -i -e clocksource -e tsc which, on a patched kernel for Ryzen systems, shows: [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 3193.773 MHz processor [ 0.075722] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.076095] Kernel command line: BOOT_IMAGE=/BOOT/funtoo_034c758a@/kernel dozfs root=ZFS=rpool/ROOT/funtoo_034c758a ro quiet splash amdgpu.backlight=0 nvidia-drm.modeset=1 nvidia.NVreg_RegistryDwords=EnableBrightnessControl=1 vt.handoff=1 zfs_force=1 tsc=directsync [ 0.178984] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns [ 0.229012] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2e094f9e584, max_idle_ns: 440795239499 ns [ 0.510867] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.592184] clocksource: Switched to clocksource tsc-early [ 0.602976] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns [ 1.447411] tsc: tsc_khz exported in sysfs [ 1.939068] tsc: Refined TSC clocksource calibration: 3218.746 MHz [ 1.939090] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2e6577347f3, max_idle_ns: 440795364772 ns [ 1.939151] clocksource: Switched to clocksource tsc note the last line, "Switched to clocksource tsc". another way to check, # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm tsc should be listed here, and: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc should be the output here! this seems like "oh, who cares", right? wrong. turns out this is an issue common on Windows too, but detecting it there requires writing/compiling a small C application, which, to be fair, I have no idea how to do there. and on both OS where this occurs, it results in up to 30% wasted CPU, which impacts battery life and responsivity. in fact, here's a geekbench run between the two: https://browser.geekbench.com/v5/cpu/compare/14624127?baseline=14467230

Biking With Panda