Jump to content

Tasso

Building the ideal(ish) Music Server

Recommended Posts

1 hour ago, rmpfyf said:

My 2c, hope others chip in. 

That...my good man...

Is a BIG 2c worth...

THANK YOU...

Edited by Rob181

Share this post


Link to post
Share on other sites

@rmpfyf That is great stuff. Thanks for taking the time to write this stuff, hopefully it can help others also who want to jump down this rabbit hole.

 

Lots to try there and (encouragingly) lots to be done. 

 

Will report back my findings, might be a few days, busy weekend coming up.

Share this post


Link to post
Share on other sites
5 hours ago, rmpfyf said:

 

 

If I read correctly:

  • You run an Atom with very little cache. A core CPU can improve SQ a lot by virtue of the cache alone.
  • You could lock the CPU down a good bit yet by way of clock speeds and C-states
  • Your grub configuration is set to boot with the High Precision Even Timer (HPET) as your PC clocksource, though snakeoil changes this to the ACPI clocksource. 
  • HPET and TSC clocksource frequency is set low, if you can set this higher things should sound better. 
  • Is there a USB card of sorts in there connected to a DAC with an XMOS interface?
  • Why have a mouse/keyboard on the rendering PC? 
  • You've a few USB devices
  • Your PC is updating VM stats every second. Way too often, causes jitter.
  • uhubctl is installed and can be used to work out what you can and can't shut down for USB, assuming your USB interfaces are supported by uhubctl.
  • Looks like your audio USB interrupts are consigning themselves to one CPU core, which is good, but so are your other USB devices and Ethernet port.

With only two cores there's not a lot you can do about running separate processes on different cores. I'm one for big cache, low speed, at least 4 cores, low voltage parts. 

 

What I would do - which you are free to follow completely at your own risk; 

 

Lock down that CPU

If your BIOS allows it, limit it to minimum speed (prolly 800MHz) only. You can confirm success with lscpu at any time. If it allows C-states no less than C3, do that too. You are welcome to try a C0-only C-state, Atoms are low enough power for it to possibly work. 

 

Change the grub command line

First make a backup, i.e. sudo cp /etc/default/grub /etc/default/grub.backup

Then edit it - sudo nano /etc/default/grub - if there's no nano install, do so with sudo apt-get install nano

Change GRUB_CMDLINE_LINUX_DEFAULT="text clocksource=hpet 3 biosdevname=0 net.ifnames=0"

To GRUB_CMDLINE_LINUX_DEFAULT="text 3 biosdevname=0 net.ifnames=0 isolcpus=1 processor.max.cstate=3 nosoftlockup"

Write that, exit nano, then make it effective with sudo update-grub. This will do the following:

  • Run as much as possible on CPU 0, leaving CPU 1 'isolated' for things you explicitly want to run on it - with only two limited-performance cores this may be a negative effect, but worth a try, and you can always change back
  • Make your PC a little more unstable by not checking to see if a CPU is hung
  • Limit C-states to 3 (not really sure this makes much of a difference on an Atom)
  • Stop the PC booting with the HPET timer set

If you're unsure you can try one at a time and listen critically. "processor.max.cstate=0" would limit C-states altogether (the CPU would never shut down any part of itself, which cuts latency a lot, which decreases jitter a lot). 

 

Up the clocksource frequencies

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq
echo "4095" | sudo tee --append /sys/class/rtc/rtc0/max_user_freq

 

The numbers in quotations are what works for me, being the maximum I can input there. Maximums depend on hardware, yours may vary. You'll be able to verify these with commands in my last post, and you can do this whilst music is playing and hear the result (you'll need a high-fidelity rig). 

 

Switch the clocksource

Try echo "tsc" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource. You can change that with hpet or acpi_pm, again whilst music is playing, though you will need to set higher resolutions first. (I'm sure you can do both in Snakeoil, though verify from the command line that it works). tsc is about as low-latency as it gets but latency isn't the only thing going. 

 

Drop the VM updating

sudo sysctl -w vm.stat_interval=3600 should shut it up. 

 

Pin the USB audio interrupt to your spare CPU

Assuming it's IRQ 17 your audio interface sits on, it'd be echo "1" | sudo tee --append /proc/irq/17/smp_affinity_list. If you've nailed it and your rig is jitter-sensitive and of sufficient fidelity you should hear an audible difference on executing that command, do it whilst you play music. 

 

Limit what your USB has to do

Pull out the Microsoft interface and access it over web interface (also - a Bluetooth radio next to an audio PC is no good). Then yes, move to the SSD (powered externally) to run your OS. 

 

Power down USB not in use

It'd be sudo uhubctl that'll show you a list of your ports and what's powered. The hubs will be listed as 1-1, 2-1, etc, with their ports as 1, 2, 3, 4... and so on. To try to power things down you'll run something like (e.g. to power down ports 1, 2 and 4 on hub 1-1 you'd type):


sudo uhubctl -a 0 -p 124 -l 1-1

Repeat for as many hubs and ports as you have. If it can't find the file, try sudo /usr/local/bin/uhubctl -a 0 -p 124 -l 1-1

 

Ideally you would try to move the music player to a spare CPU core, though I have the player and the USB interrupt on separate cores. It's difficult to do this with two cores only. 

 

If you like any of these changes it's possible to write them up into a nice little script your PC runs whenever it boots (the grub changes are persistent, though). 

 

BTW on Ethernet you'd run a separate subnet (can be point-to-point or through a router) with as high an MTU as your network can manage. Between two PCs you can probably get jumbo frames (MTU >= 9000) with ease - just means less packets, which means less interrupt requests, which means Ethernet distracts your CPU less, which means less jitter. Again, think you can set this in SnakeOil (like a lot here) though I would always suggest validating your intended changes stuck from the terminal. If you wanted to be super trick you'd isolate these by running a fibre connection linking two PCs (with s/h parts it's probably cheaper than isolators, and better). 

 

My 2c, hope others chip in. 

Is there a USB card of sorts in there connected to a DAC with an XMOS interface?

yep that is the Vitus dac

 

Why have a mouse/keyboard on the rendering PC? 

Oops ,Forgot to pull the dongle for the bluetooth keyboard /mouse I was using to mod the bios

 

Early speedhump!

so@so-desktop:~$ sudo cp /etc/default/grub /etc/default/grub.backup
sudo cp: command not found

 

Tried to limit cpu freq but couldnt find an option on the bios

 

Was able to freq change but not able to listen at the moment so something to look forward to trying. How does one find the max freq possible?

 

In snakeoil it also allows some boot options as below, 

Boot options

These are additional command line options for the kernel. Please note these options while well tested in Linux may not be compatible with your hardware configuration. If the kernel fails to boot you'd need to manually modify the boot up options from the console to recover.

Options Description
none No special boot parameters
acpi=noirq  Do not use ACPI for IRQ routing or for PCI scanning
acpi=ht Disable all ACPI functions, except what is required for hyper threading
noapic Tells the kernel to not make use of any IOAPICs that may be present in the system.
pnpacpi Not sure what this does - does it turns on Plug N Play ACPI, or off? 
nolapic Do not enable or use the local APIC.

Share this post


Link to post
Share on other sites

Happy to help, all - would stress the real genius here is Kith.

 

@frednork if you just type in cp does it give you 'command not found' or 'missing operand'? If you type in ls /bin can you see cp listed? You can edit the grub config file without making a backup, I'd just be very very careful (and we can get cp installed if not there). 

 

List me your motherboard model, I'll see if there's a speed limit option. It's possible to do it in software (same as how it's done in XXHighEndXX). Try:

 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

 

(You can change min for max to get max freqs possible, but audiophile freaks care more about the minimum). To give an idea of what your current Linux kernel thinks it can play with. You might be super lucky here, some Atoms can get down very low on frequency.

 

There are hundreds of grub boot options you can use beyond those listed. 

Share this post


Link to post
Share on other sites


Thanks for all of the details @rmpfyf - amazing stuff. We could complie this into a proper 'how to' guide and even use it as a wish request for Mr Kith, so that it becomes part of Sankeoil moving forwards.

 

 

Lock down that CPU

If your BIOS allows it, limit it to minimum speed (prolly 800MHz) only. You can confirm success with lscpu at any time. If it allows C-states no less than C3, do that too. You are welcome to try a C0-only C-state, Atoms are low enough power for it to possibly work. 

 

I've tried this before (800mhz, 1.2 mhz etc, all sorts of speeds) and it works okay for everything excpet 24/192 and DSD  where I'm guaranteed occasional dropouts, which ruins the music. Give I'm using an I7, I would have thought it had more than enough muscle to handle these tasks. Do you have any idea what may be causing this? I've tried leaving the RAM at full speed and slowing it down, neither helps.

 

Up the clocksource frequencies

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq
echo "4095" | sudo tee --append /sys/class/rtc/rtc0/max_user_freq

 

The numbers in quotations are what works for me, being the maximum I can input there. Maximums depend on hardware, yours may vary. You'll be able to verify these with commands in my last post, and you can do this whilst music is playing and hear the result (you'll need a high-fidelity rig).

 

Is the aim of the game to try and find the highest  number that works here? Is there anyway to findout the theoretical max for ones hardware?

 

Switch the clocksource

Try echo "tsc" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource. You can change that with hpet or acpi_pm, again whilst music is playing, though you will need to set higher resolutions first. (I'm sure you can do both in Snakeoil, though verify from the command line that it works). tsc is about as low-latency as it gets but latency isn't the only thing going. 

 

I've got an anftermarket clock fitted to my motherboard (SOtM), does this still apply for me? I ask because if I've upgraded one clock, then surely I should stick with that one rather than the other choices? Or does upgrading the 24mhz clock on the motherboard imapct all clocks I can choose from? I don't really know what I'm talking about here so am happy to be corrected and learn something.

 

Share this post


Link to post
Share on other sites
On 30/08/2018 at 2:27 PM, JDWest said:

When activating CPUset in Snakeoil, if you get the error message say no processes running in user, firstly refresh the page and they might appear. That said, I also get zero processes for Roon Bridge but one for Roon Server. Don't have JRiver to test. Works fine for LMS/Squeezelite and as I recall also for MPD.

Good shout - this worked; I'll let him know.

 

The CPU set feature definitely works now, I can easily tell this because I get loads of dropouts when I assign it to the fourth core (core 'three').

Edited by realysm42

Share this post


Link to post
Share on other sites
3 hours ago, realysm42 said:

Thanks for all of the details @rmpfyf - amazing stuff. We could complie this into a proper 'how to' guide and even use it as a wish request for Mr Kith, so that it becomes part of Sankeoil moving forwards.

Well... let's see that there's some consensus around how this works for others enough to warrant stickiness. What works for me mightn't work for others. I rock an i5 4th-gen T-spec CPU, I'm betting I'm one in a population of approximately one here :P 

 

3 hours ago, realysm42 said:

I've tried this before (800mhz, 1.2 mhz etc, all sorts of speeds) and it works okay for everything excpet 24/192 and DSD  where I'm guaranteed occasional dropouts, which ruins the music. Give I'm using an I7, I would have thought it had more than enough muscle to handle these tasks. Do you have any idea what may be causing this? I've tried leaving the RAM at full speed and slowing it down, neither helps.

You'd have to be doing something else at the same time to get that sort of performance; I can play back 192kHz no problems running a full GUI (Kodi) at under 10% CPU load at 800MHz with the OS, Kodi and playback all running on the same core and only a few hundred MB RAM consumed. You could see if it's the player you're using that's particularly heavyweight by playing back a file from the command line using the aplay utility. Alternately it'd be easy enough to run top or htop (you might need to install the latter, sudo apt-get install htop) to see if CPU usage is the holdup here.

 

Unless you're doing some hardcore processing as you play back, it's more likely that you've some poor interrupt assignments or over-aggressive interrupt priorities - in short, that your OS is making some poor decisions around how to prioritise what it does next. Your CPU should do the rest in its sleep. 

 

3 hours ago, realysm42 said:

Is the aim of the game to try and find the highest  number that works here? Is there anyway to findout the theoretical max for ones hardware?

 

Absolutely, that's the game - up the max interrupt frequency on both timers. No idea how to find out the theoretical max, just try set it and read it back to see what stuck. You might find this improves some of your playback performance. 

 

There are some cases I imagine, depending on how your kernel and applications work relative to your hardware, where too high an interrupt freq for either could lead to worse performance, though my mileage suggests more the better. 

 

4 hours ago, realysm42 said:

I've got an anftermarket clock fitted to my motherboard (SOtM), does this still apply for me? I ask because if I've upgraded one clock, then surely I should stick with that one rather than the other choices? Or does upgrading the 24mhz clock on the motherboard imapct all clocks I can choose from? I don't really know what I'm talking about here so am happy to be corrected and learn something.

***(Disclaimer) as I understand it***

 

This really depends on how your motherboard implements timers. Typically the HPET is a circuit lives in the southbridge (older PCs) or PCH chip (more modern PCs), same as the real-time clock (RTC), and both are driven by an external 'master' oscillator - 24MHz since the 5th generation Intel Core chips, 25MHz before that. I don't do much with Atom boards though I've seen a few that have a separate RTC oscillator. 


Your Linux PC can pull a master clock source from a few places - TSC, HPET, ACPI_PM, whatever. Generally, each offers more latency in getting a response out than the next (to be fair the kind of responses they give differ - each has a different purpose). As for jitter that's intrinsic beyond latency, think of it this way - unless there are separate crystals of different frequencies providing sources for each, the jitter inherent is the function of 'how good the crystals are' + 'how jittery the circuit is' + 'how your OS and programs need a timer response'. A lot of this is software, a good amount of this is hardware - both the clocks and the PCH/north/southbridge (as and if fitted) implementation. Better oscillators help, though the degree to which I can't quantify. There are too many variables - you just have to try. I would imagine in your case the 24MHz clock impacts each of them, and TSC is certainly the lowest latency implementation, though whether it's got a silly amount of jitter or not relative to HPET is something you'd need to try. Flip them whilst listening - it'll be audible. Your SOtM clock will work on each as long as it's connected to the circuits affecting each, which (if I remember your asking where to wire it up previously) you should have right. If separate crystals drive everything that matters then no, one clock won't help. What you're configuring here are the usage of circuits that get that nicer clock signal you've invested in.

 

I rock a fairly cheap Gigabyte board that has a decent oscillator on it, I tried a mega-expensive Asus that sounded far worse which had poorer-quality oscillators on it but sounded a great deal better when I swapped the oscillators from the Gigabyte board onto it for kicks. TSC sounds best here, your mileage may differ. For anyone with older Core boards (4th gen or earlier) I have some 25MHz OCXO's that are better than SOtM's or PPA's, they'll need a PSU which I could suggest if you want a bit of a science experiment. I have 10 and can let a few go cheap (PM if interested).

 

I'm happy to be corrected and learn something here too. If I've got something wrong or anyone has anything to add please do so constructively. We're all learning here. The last time I mucked up here on an assertion around timing layout I got a fairly snarky and altogether useless response from a font of knowledge. You know who you are. 

Share this post


Link to post
Share on other sites


@rmpfyf thanks kindly for the input.  So many questions 😉 but I'll start with clocksource fequencies and these commands:

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq
echo "4095" | sudo tee --append /sys/class/rtc/rtc0/max_user_freq

 

Within Snakeoil I found tsc sounded best for me. It also gave the best cyclictest results. In BIOS if I disabled HPET timer it sounded worse and cyclictest results were shocking. I don't know how this all relates; maybe it makes no sense and I did do different tests on different motherboards at different times.

 

Anyway, I see hpet in one of the above commands and wanted to know if these commands need to change if I'm selecting tsc?

For the numbers (8192 and 4095 seemed to work for me) is there any rule like needing to be a multiple of x or can I enter any number?

 

Cheers

Share this post


Link to post
Share on other sites

@rmpfyf Have stolen another bit of time to continue

 

Lock down that CPU

So far not able to do it in bios as mentioned

motherboard here http://www.jetwaycomputer.com/NF9C.html

 

tried to change manually as below and then looked to see what was there

 

so@so-desktop:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq: No such file or directory
so@so-desktop:~$ ls /sys/devices/system/cpu/cpu0/
cache  firmware_node  microcode  subsystem  topology  uevent
so@so-desktop:~$
 

 

Change the grub command line

This worked today for some reason so all good

 

Up the clocksource frequencies

ALso worked but seemingly no upper limit

so@so-desktop:~$ echo "1198192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq
1198192
so@so-desktop:~$ cat /proc/sys/dev/hpet/max-user-freq                           1198192

doesnt sound quite right not sure what that means


Switch the clocksource

Try echo "tsc" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource. 

this didnt work

so@so-desktop:~$ echo "tsc" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource
tee: /sys/devices/system/clocksource/clocksource0/current_clocksource: Permission denied
tsc

 

Drop the VM updating

sudo sysctl -w vm.stat_interval=3600 should shut it up. 

worked

 

Pin the USB audio interrupt to your spare CPU

Assuming it's IRQ 17 your audio interface sits on, it'd be echo "1" | sudo tee --append /proc/irq/17/smp_affinity_list. 

didnt work, is it a diff IRQ? how do I find out

 

so@so-desktop:~$ echo "1" | sudo tee --append /proc/irq/17/smp_affinity_list
tee: /proc/irq/17/smp_affinity_list: Invalid argument
1

 

Limit what your USB has to do

Pull out the Microsoft interface and access it over web interface (also - a Bluetooth radio next to an audio PC is no good). Then yes, move to the SSD (powered externally) to run your OS. 

Bluetooth gone SSD when I get a bit more time, still intersted in where best to put music as I could just use a small drive here and have a big one elsewhere?

 

Power down USB not in use

It'd be sudo uhubctl that'll show you a list of your ports and what's powered. The hubs will be listed as 1-1, 2-1, etc, with their ports as 1, 2, 3, 4... and so on. To try to power things down you'll run something like (e.g. to power down ports 1, 2 and 4 on hub 1-1 you'd type):


sudo uhubctl -a 0 -p 124 -l 1-1

Repeat for as many hubs and ports as you have. If it can't find the file, try sudo /usr/local/bin/uhubctl -a 0 -p 124 -l 1-1

 

Ideally you would try to move the music player to a spare CPU core, though I have the player and the USB interrupt on separate cores. It's difficult to do this with two cores only. 

 

This seems to work, There is also the option to switch off power via the motherboard via bios or via jumpers on the board itself. What is best?

 

If you like any of these changes it's possible to write them up into a nice little script your PC runs whenever it boots (the grub changes are persistent, though). 

 

Yes that would be great, if you can point to a good how to.

 

Share this post


Link to post
Share on other sites

@frednork

 

Motherboard manual suggests there are some options that might play nice (https://www.jetwaycomputer.com/download/Manual/NF9C/NF9C-V2.0.pdf) - I reckon you'd be across these and/or not all options would exist on your motherboard, but for what it's worth and from the manual:

  • Page 35 - Disable hyperthreading
  • Page 37 - Disable parallel and serial ports
  • Page 38 - Disable more COM ports
  • Page 39 - (PPM configuration) Disable EIST (might bring up more options), you also have two C-state options at least (hard to make out what they are without seeing the BIOS first hand)
  • Page 41 - Disable the Azalia controller

See what exists in  /sys/devices/system/cpu/ or  /sys/devices/system/cpu/cpu0 by listing what's there, as in 

 

ls  /sys/devices/system/cpu

ls  /sys/devices/system/cpu/cpu0

 

Report back. If EIST is already disabled you may have a situation where the OS sees no CPU scaling, as the BIOS is not reporting it as a capability (it also needs to be supported in the kernel, which depends on how it's built).

 

I'd set your HPET frequency to something reasonable, even 2048 is going to be an improvement on what you have. Remember this is a maximum interrupt frequency you're spec'ing so setting it beyond what the PC can do will only bog things down... try this: play music, change it, keep listening for a change. Stop when it makes no difference. Go up in increments of 2 from 64. You may have to set your clocksource to HPET to make a difference. 

 

Let's see what you've got to play with for clocksources with cat /sys/devices/system/clocksource/clocksource0/available_clocksource first - you can echo any of the choices you see into the previous statement. 

 

The IRQ SMP affinity depends on a few things, first there being an IRQ to play with and then that the kernel is built supporting SMP. Try this: type in cat /proc/irq/ then don't hit enter, hit tab instead. This shows you the autocomplete possibilities - these will be the IRQs your system runs at the moment. Check that 17 is there. If it's not, we need to go hunting for which IRQ it is. Then - for any IRQ you want to play with -  cat /proc/irq/17/ and again hit tab not enter. A list of files should come up, see that smp_affinity_list is an option. Let me know if it's not.

 

If you power off USB using jumpers then you might not see them on the uhubctl list - as long as it's powered off you're golden - can check by plugging something in and seeing if it reacts. 

 

Easy enough to put the music on a network drive unless you're super anorak-ish and want to configure a kernel with zero network support. I don't think Snakeoil is configured as such, though some lighter players like wtfplayer might be. Remember that Ethernet hits the CPU with some regularity; it's easier with a few more cores.

Edited by rmpfyf

Share this post


Link to post
Share on other sites
1 hour ago, frednork said:

Yes that would be great, if you can point to a good how to. 

It's built on Ubuntu 16.04 or later, right?

Share this post


Link to post
Share on other sites


@rmpfyf Thanks for the quick reply. Am trying to keep up.

 

Bios tweaks are done

 

so@so-desktop:~$ ls  /sys/devices/system/cpu/cpu0
ls: cannot access '/sys/devices/system/cpu/cpu0': No such file or directory
so@so-desktop:~$ ls  /sys/devices/system/cpu
cpu0  isolated    microcode  offline  possible  uevent
cpu1  kernel_max  modalias   online   present

 

I get the above whether EIST is enabled or not so even though cpu0 is there it wont access it 

 

I tried disabling enhanced c3 state and got

 

so@so-desktop:~$ ls  /sys/devices/system/cpu
ls: cannot access ' /sys/devices/system/cpu': No such file or directory

 

so I tried poking around


so@so-desktop:~$ ls /sys
block  bus  class  dev  devices  firmware  fs  kernel  module
so@so-desktop:~$ ls /sys/devices/
breakpoint  intel_bts    msr         platform  software  virtual
cpu         LNXSYSTM:00  pci0000:00  pnp0      system
so@so-desktop:~$ ls /sys/devices/cpu
events  format  perf_event_mux_interval_ms  rdpmc  subsystem  type  uevent
so@so-desktop:~$ ls /sys/devices/cpu/subsystem
devices  drivers  drivers_autoprobe  drivers_probe  uevent
so@so-desktop:~$ ls /sys/devices/cpu/subsystem/devices
breakpoint  cpu  intel_bts  msr  software
so@so-desktop:~$ ls /sys/devices/cpu/subsystem/devices/cpu
events  format  perf_event_mux_interval_ms  rdpmc  subsystem  type  uevent

 


I'd set your HPET frequency to something reasonable, even 2048 is going to be an improvement on what you have. Remember this is a maximum interrupt frequency you're spec'ing so setting it beyond what the PC can do will only bog things down... try this: play music, change it, keep listening for a change. Stop when it makes no difference. Go up in increments of 2 from 64. You may have to set your clocksource to HPET to make a difference. 

 

Will do this when I get a chance

 

Let's see what you've got to play with for clocksources with cat /sys/devices/system/clocksource/clocksource0/available_clocksource first - you can echo any of the choices you see into the previous statement. 

 

so@so-desktop:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
only hpet and acpi so assume hpet is better?

 

The IRQ SMP affinity depends on a few things, first there being an IRQ to play with and then that the kernel is built supporting SMP. Try this: type in cat /proc/irq/ then don't hit enter, hit tab instead. This shows you the autocomplete possibilities - these will be the IRQs your system runs at the moment. Check that 17 is there. If it's not, we need to go hunting for which IRQ it is. Then - for any IRQ you want to play with -  cat /proc/irq/17/ and again hit tab not enter. A list of files should come up, see that smp_affinity_list is an option. Let me know if it's not.\

 

IRQ17 and smp_affinity_list there but

so@so-desktop:~$ echo "1" | sudo tee --append /proc/irq/17/smp_affinity_list
tee: /proc/irq/17/smp_affinity_list: Invalid argument
1

 

It's built on Ubuntu 16.04 or later, right?

yep

Ubuntu 16.04.2 LTS

 

Share this post


Link to post
Share on other sites
4 hours ago, JDWest said:

@rmpfyf thanks kindly for the input.  So many questions 😉 but I'll start with clocksource fequencies and these commands:

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq
echo "4095" | sudo tee --append /sys/class/rtc/rtc0/max_user_freq

 

Within Snakeoil I found tsc sounded best for me. It also gave the best cyclictest results. In BIOS if I disabled HPET timer it sounded worse and cyclictest results were shocking. I don't know how this all relates; maybe it makes no sense and I did do different tests on different motherboards at different times.

 

Anyway, I see hpet in one of the above commands and wanted to know if these commands need to change if I'm selecting tsc?

For the numbers (8192 and 4095 seemed to work for me) is there any rule like needing to be a multiple of x or can I enter any number?

 

Cheers

 

You'll want the HPET enabled for audio work, too much uses it - you can use it as the system clocksource too in Linux, if you've tsc available it's usefully lower latency. 

 

The two commands above just set the interrupt freq for two different clocksources (the RTC I'd think is less important). From what clocksources you have available,  echo "CLOCKSOURCE" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource should change the clocksource. 

Share this post


Link to post
Share on other sites
13 minutes ago, rmpfyf said:

 

You'll want the HPET enabled for audio work, too much uses it - you can use it as the system clocksource too in Linux, if you've tsc available it's usefully lower latency. 

 

The two commands above just set the interrupt freq for two different clocksources (the RTC I'd think is less important). From what clocksources you have available,  echo "CLOCKSOURCE" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource should change the clocksource. 

I'm a bit confused.

So in BIOS I do always enable HPET timer. You agree I think?

Within Snakeoil web interface, I can select tsc, hpet or acpi_pm. I always select tsc (don't need an ssh command to do so). I think you find that a reasonable choice.

 

Now, with HPET enabled in BIOS and tsc selected in Snakeoil, would the following command change anything?:

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq

 

OK, the number adjusts interrupt freq, so does the higher number mean that interrupts can happen faster?...or something like that.

Share this post


Link to post
Share on other sites

@frednork if I have some time I might have to install a latest SO on a USB stick and play!

 

See what cpu0 brings up - cat /sys/devices/system/cpu/cpu0. Should tell you whether a file (you'll see contents) or a directory. Or just use ls /sys/devices/system/cpu -l to give you an annotated list of what's what, along with permissions. If it's sh***y on permissions try again with sudo in front (that's a guess). You seem to have nothing in there for throttling the CPU, which suggests it's probably not been compiled in the version of the kernel you have. From memory (mine can be sketchy here) I think there was a guide on how to use or otherwise compile a kernel for SO, or I can put together some instructions on how to hack that way. Whilst you can end up in a place where your system needs some love to boot at all (and in some corner cases it's possible to ruin good hardware too - though unlikely) it's the start of the rabbit home and a lot of fun from there. 

 

Depending how the kernel is built you may be able to load the support your CPU needs as a module - something like https://forums.fedoraforum.org/showthread.php?301748-Atom-CPU-automatic-frequency-scaling-without-speedstep

 

I would bear in mind that Atom and Core CPUs have vastly different power/frequency control, and will report differently to the OS through the BIOS. It'd be interesting to hear what Core CPU SO users report. 

 

As to not seeing tsc as a clocksource, first let's check your CPU supports this (grep tsc /proc/cpuinfo will tell you as much - should show up there for every CPU core, or it won't). Maybe the OS is blacklisting it on boot? Check your boot messages for anything interesting - report back on dmesg | grep -i tsc. It should be there unless it's blacklisted - the only Atom I have running at home (in my NAS) reports tsc, hpet and acpi_pm. I'd suggest hpet to be better in your current instance but really... you want a working tsc. 

 

As for not being able to set affinity, it's possible that whomever built your kernel doesn't want you to change that - it's certainly possible to build a kernel that limits your ability to set affinity manually (I think the kernel flag is PF_NO_SETAFFINITY). It's also possible that your kernel's author hasn't listed their build parameters either, because it's their work and they're keen to keep it that way. In which case the only way to get that happening is to submit a feature request - which I'd think would be a worthy thing, and likely something on Kith's radar - latest version seems to have cgroupset for some application CPU affinity in the paid version, I'd think a next step would be being able to set affinities for interrupts etc. Would you believe on my four-core CPU there's an audible difference as to which cores the playback application and the USB interrupt run on? True story.

 

Of course, if you want to roll your own kernel then you start afresh and build what you want :)  It's fun, and it'd be completely possible to have a PC that boots with a menu for what SO intended and your own kernel as a second option. I have a few going at any one time, and some forum members are pretty exotic here, netbooting kernels and the like. 

 

Hopefully someone else chimes in at this point :D 

Share this post


Link to post
Share on other sites


28 minutes ago, JDWest said:

I'm a bit confused.

So in BIOS I do always enable HPET timer. You agree I think?

Within Snakeoil web interface, I can select tsc, hpet or acpi_pm. I always select tsc (don't need an ssh command to do so). I think you find that a reasonable choice.

 

Now, with HPET enabled in BIOS and tsc selected in Snakeoil, would the following command change anything?:

echo "8192" | sudo tee --append /proc/sys/dev/hpet/max-user-freq

 

OK, the number adjusts interrupt freq, so does the higher number mean that interrupts can happen faster?...or something like that.

 

In BIOS you enable it, this lets your PC access it. 

 

What you're changing in Snakeoil is only what your operating system uses for a clock reference. Any application can use any clocksource (or multiples) at any time. Naturally the OS touches a lot, so there's an audible difference. 

 

The command changes how accurately the HPET timer can be accessed, the standard being 1/64th of a second. That's plenty fine for word processing, you probably want something more resolute for audiophile work - a few thousand Hz will do. Of course it also means if there are more HPET requests than there is frequency to handle them at the standard frequency, upping the frequency can resolve this (if it doesn't come at the expense of other resources).

Edited by rmpfyf

Share this post


Link to post
Share on other sites

@rmpfyf  Do you know another ssh method to shut down mobo USB hubs/ports?

...other than via uhubctl?

 

I use a SOtM PCIe-USB card to DAC and don't use any mobo USB ports on my Gigabyte GA-B250M-HD3.  Unfortunately, uhubctl doesn't detect my mobo's USB hubs; it only detects the ones connecting to my DAC (I can switch those off in Snakeoil). lsusb shows all the hubs.

 

 

Cheers

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

@rmpfyf apologies for the unwieldy post, just didnt know what to leave out

 

See what cpu0 brings up - cat /sys/devices/system/cpu/cpu0. 

so@so-desktop:~$ cat /sys/devices/system/cpu/cpu0
cat: /sys/devices/system/cpu/cpu0: No such file or directory

 

. Or just use ls /sys/devices/system/cpu -l to give you an annotated list of what's what, along with permissions.

so@so-desktop:~$  ls /sys/devices/system/cpu -l
total 0
drwxr-xr-x 5 root root    0 Sep  1 17:59 cpu0
drwxr-xr-x 5 root root    0 Sep  1 17:59 cpu1
-r--r--r-- 1 root root 4096 Sep  1 17:59 isolated
-r--r--r-- 1 root root 4096 Sep  1 18:14 kernel_max
drwxr-xr-x 2 root root    0 Sep  1 21:46 microcode
-r--r--r-- 1 root root 4096 Sep  1 21:46 modalias
-r--r--r-- 1 root root 4096 Sep  1 21:46 offline
-r--r--r-- 1 root root 4096 Sep  1 17:59 online
-r--r--r-- 1 root root 4096 Sep  1 18:14 possible
-r--r--r-- 1 root root 4096 Sep  1 18:14 present
-rw-r--r-- 1 root root 4096 Sep  1 17:59 uevent

 

If it's sh***y on permissions try again with sudo in front (that's a guess).

so@so-desktop:~$ sudo cat /sys/devices/system/cpu/cpu0
[sudo] password for so:
cat: /sys/devices/system/cpu/cpu0: No such file or directory

 

Depending how the kernel is built you may be able to load the support your CPU needs as a module - something like https://forums.fedoraforum.org/showthread.php?301748-Atom-CPU-automatic-frequency-scaling-without-speedstep

 

Followed the thread and got

 

so@so-desktop:~$ cat /proc/cpuinfo|grep "model name"|head -n 1
model name      : Intel(R) Atom(TM) CPU N2800   @ 1.86GHz
so@so-desktop:~$ cpupower frequency-info
The program 'cpupower' is currently not installed. You can install it by typing:
sudo apt install linux-tools-common
so@so-desktop:~$ sudo modprobe p4-clockmod
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.9-rt17-snakeoil-x64/modules.dep.bin'
modprobe: FATAL: Module p4-clockmod not found in directory /lib/modules/4.4.9-rt17-snakeoil-x64

so@so-desktop:~$ sudo apt install linux-tools-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  dmeventd dmraid faad freepats gir1.2-javascriptcoregtk-4.0 gir1.2-soup-2.4
  gir1.2-vte-2.91 gir1.2-webkit2-4.0 kpartx kpartx-boot lame laptop-detect
  libao-common libao4 libaudio2 libcaca0 libdevmapper-event1.02.1
  libdmraid1.0.0.rc16 libfaad2 libiw30 liblilv-0-0 liblo7 liblvm2cmd2.02
  libmikmod3 libmp3lame0 libmpg123-0 libopenal-data libopenal1
  libparted-fs-resize0 libportaudio2 libreadline5 libsdl1.2debian libserd-0-0
  libsord-0-0 libspeex1 libsratom-0-0 libtimezonemap-data libvte-2.91-0
  libvte-2.91-common lzma mikmod mpg123 osspd osspd-pulseaudio sbsigntool
  timidity timidity-daemon vorbis-tools
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  linux-tools-common
0 upgraded, 1 newly installed, 0 to remove and 278 not upgraded.
Need to get 142 kB of archives.
After this operation, 527 kB of additional disk space will be used.
Get:1 http://au.archive.ubuntu.com/ubuntu xenial-updates/main amd64 linux-tools-common all 4.4.0-134.160 [142 kB]
Fetched 142 kB in 2s (68.7 kB/s)
Selecting previously unselected package linux-tools-common.
(Reading database ... 49975 files and directories currently installed.)
Preparing to unpack .../linux-tools-common_4.4.0-134.160_all.deb ...
Unpacking linux-tools-common (4.4.0-134.160) ...
Processing triggers for man-db (2.7.5-1) ...
/usr/bin/mandb: fopen /var/cache/man/it/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/tr/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/fi/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ja/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pt_BR/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/fr/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/zh_TW/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ru/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pt/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ko/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/nl/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/id/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pl/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/sl/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/hu/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/zh_CN/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/da/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/sv/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/cs/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/de/9160: Permission denied
/usr/bin/mandb: fopen /var/cache/man/es/9160: Permission denied
Setting up linux-tools-common (4.4.0-134.160) ...
so@so-desktop:~$ cpupower frequency-info
WARNING: cpupower not found for kernel 4.4.9-rt17

  You may need to install the following packages for this specific kernel:
    linux-tools-4.4.9-rt17-snakeoil-x64
    linux-cloud-tools-4.4.9-rt17-snakeoil-x64

  You may also want to install one of the following packages to keep up to date:
    linux-tools-snakeoil-x64
    linux-cloud-tools-snakeoil-x64

so@so-desktop:~$ sudo apt instal linux-tools-4.4.9-rt17-snakeoil-x64
E: Invalid operation instal
so@so-desktop:~$ sudo apt install linux-tools-4.4.9-rt17-snakeoil-x64
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-tools-4.4.9-rt17-snakeoil-x64
E: Couldn't find any package by glob 'linux-tools-4.4.9-rt17-snakeoil-x64'
E: Couldn't find any package by regex 'linux-tools-4.4.9-rt17-snakeoil-x64'

so@so-desktop:~$ sudo apt install linux-cloud-tools-4.4.9-rt17-snakeoil-x64
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-cloud-tools-4.4.9-rt17-snakeoil-x64
E: Couldn't find any package by glob 'linux-cloud-tools-4.4.9-rt17-snakeoil-x64'
E: Couldn't find any package by regex 'linux-cloud-tools-4.4.9-rt17-snakeoil-x64'

 

As to not seeing tsc as a clocksource, first let's check your CPU supports this (grep tsc /proc/cpuinfo will tell you as much - should show up there for every CPU core, or it won't).

Maybe the OS is blacklisting it on boot? Check your boot messages for anything interesting - report back on dmesg | grep -i tsc. It should be there unless it's blacklisted - the only Atom I have running at home (in my NAS) reports tsc, hpet and acpi_pm. I'd suggest hpet to be better in your current instance but really... you want a working tsc. 

 

Maybe the TSC is broken

 grep tsc /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dtherm
so@so-desktop:~$ dmesg | grep -i tsc
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 1862.228 MHz processor
[    0.355395] TSC synchronization [CPU#0 -> CPU#1]:
[    0.355397] Measured 64869 cycles TSC warp between CPUs, turning off TSC clock.
[    0.355403] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[    0.654091] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x35af94fd872, max_idle_ns: 881590752918 ns

 

 

As for not being able to set affinity, it's possible that whomever built your kernel doesn't want you to change that - it's certainly possible to build a kernel that limits your ability to set affinity manually (I think the kernel flag is PF_NO_SETAFFINITY). It's also possible that your kernel's author hasn't listed their build parameters either, because it's their work and they're keen to keep it that way. In which case the only way to get that happening is to submit a feature request - which I'd think would be a worthy thing, and likely something on Kith's radar - latest version seems to have cgroupset for some application CPU affinity in the paid version, I'd think a next step would be being able to set affinities for interrupts etc. Would you believe on my four-core CPU there's an audible difference as to which cores the playback application and the USB interrupt run on? True story.

 

Seems like you can set IRQ priority in snakeoil

Process Priority

How various programs are executed in Linux to give you that multi-tasking ability is determined by something call a process scheduler. How it all works is beyond the scope of this manual, because it largely dependent on the technique (plus other stuffs). Suffice to say if you are using a cooperative scheduler then you can use this option to fine-tune how often a process gets "looked at" in the queue. Snakeoil kernels with RT patches are all preemptive so this option is probably useless.

Snakeoil

Click on the "Add Process" button to add a new process. In the process name field, enter the name (or part of) of the process you wish to reassign a new priority. The prio field is the new priority level you want this process to be set to (this field is numeric only, with 1 being lowest priority, and 99 being real-time). Note that we only adjust the priority level here and not the scheduler policy. The later is really reserved for advanced users and not for general use. 

 

So I did this

image.thumb.png.29300f068c071f78d7c13ae052fe8a64.png@rmpfyf

image.thumb.png.29300f068c071f78d7c13ae052fe8a64.png

 

 

Of course, if you want to roll your own kernel then you start afresh and build what you want :)  It's fun, and it'd be completely possible to have a PC that boots with a menu for what SO intended and your own kernel as a second option. I have a few going at any one time, and some forum members are pretty exotic here, netbooting kernels and the like. 

 

It seems you can load your own Kernel into snakeoil, not sure how custom it can be

Firmware

You can update your Snakeoil OS by installing a new firmware. It's always a good idea to install the latest firmware because:

  • Includes bug fixes
  • Contains additional features and functions not available in your older edition
  • Better stability improved user experience. 

System

Simply drag the file and drop it in the marked rectangle to begin installation.

Linux Kernel

The Linux kernel can be interpreted as the heart (or brains) of the computer. The kernel controls everything. It is the bit of code that bridges the hardware and other software, balancing the needs of computer processing, hardware access, user responsiveness and more. You can replace the kernel of your Snakeoil OS by dropping a new kernel file into the marked rectangle. Some common examples of why you need to use a different kernel are:

  1. The stock kernel that comes with the LiveCD includes features that are no longer necessary after you have installed Snakeoil OS. A kernel without these additional features are smaller in size, meaning you will experience a slightly faster boot up time, and perhaps even a small sonic improvement.
  2. Support new features (e.g. native DSD) or DACs (e.g. MyTek)
  3. Different settings in the kernel configuration may influence the sound signature. e.g. use of a real time scheduler will change how applications behave, and that may be a positive (or negative) in terms of sonic quality. Refer to the custom kernel section on how to create your own kernel and package your built files into a format Snakeoil understands. This usually requires another Linux machine, or you can built it directly on your Snakeoil computer (bypassing the web interface completely).

You can check the kernel you are using from the Snakeoil OS Web App Dashboard. One of the first tweaks you can do to your Snakeoil OS is to use a more streamlined kernel. Download pre-built kernel files from the Snakeoil Resource, or compile your own.Updating the kernel is the same as upgrading firmware. Simply drag the downloaded file and drop it into the marked box as above.

Once the kernel is uploaded, you need to reboot the machine for the new kernel to take effect.

WARNING: Using a different kernel can be risky - it is the heart and soul of a computer after all and you can never truely know if the new kernel you uploaded will boot the computer up, or not. If things go wrong, refer to the Failed Kernel section to how to recover your computer back to a usable state.

Refer to the custom kernel article for details.

 

Of course, if you want to roll your own kernel then you start afresh and build what you want :)  It's fun, and it'd be completely possible to have a PC that boots with a menu for what SO intended and your own kernel as a second option. I have a few going at any one time, and some forum members are pretty exotic here, netbooting kernels and the like. 

 

It seems you can load your own Kernel into snakeoil, not sure how custom it can be

Firmware

You can update your Snakeoil OS by installing a new firmware. It's always a good idea to install the latest firmware because:

  • Includes bug fixes
  • Contains additional features and functions not available in your older edition
  • Better stability improved user experience. 

System

Simply drag the file and drop it in the marked rectangle to begin installation.

Linux Kernel

The Linux kernel can be interpreted as the heart (or brains) of the computer. The kernel controls everything. It is the bit of code that bridges the hardware and other software, balancing the needs of computer processing, hardware access, user responsiveness and more. You can replace the kernel of your Snakeoil OS by dropping a new kernel file into the marked rectangle. Some common examples of why you need to use a different kernel are:

  1. The stock kernel that comes with the LiveCD includes features that are no longer necessary after you have installed Snakeoil OS. A kernel without these additional features are smaller in size, meaning you will experience a slightly faster boot up time, and perhaps even a small sonic improvement.
  2. Support new features (e.g. native DSD) or DACs (e.g. MyTek)
  3. Different settings in the kernel configuration may influence the sound signature. e.g. use of a real time scheduler will change how applications behave, and that may be a positive (or negative) in terms of sonic quality. Refer to the custom kernel section on how to create your own kernel and package your built files into a format Snakeoil understands. This usually requires another Linux machine, or you can built it directly on your Snakeoil computer (bypassing the web interface completely).

You can check the kernel you are using from the Snakeoil OS Web App Dashboard. One of the first tweaks you can do to your Snakeoil OS is to use a more streamlined kernel. Download pre-built kernel files from the Snakeoil Resource, or compile your own.Updating the kernel is the same as upgrading firmware. Simply drag the downloaded file and drop it into the marked box as above.

Once the kernel is uploaded, you need to reboot the machine for the new kernel to take effect.

WARNING: Using a different kernel can be risky - it is the heart and soul of a computer after all and you can never truely know if the new kernel you uploaded will boot the computer up, or not. If things go wrong, refer to the Failed Kernel section to how to recover your computer back to a usable state.

Refer to the custom kernel article for details.

Edited by frednork

Share this post


Link to post
Share on other sites

@JDWest sorry, I know of no other ways to legitimately power the USB ports down. The USB controller has to be something that supports this sort of functionality and if it doesn't, you can't shut it down. It's not something a lot of recent chips do and I get a bit of a free kick here for using something a bit antiquated. Honestly in your case I'd just pull any devices from the non-used USB ports and idle the ports in BIOS if you can, whilst +5VDC across your board to your USB routes isn't ideal you can at least not have anything connected to them. If your USB card only uses one port and has e.g. two then you can get smart there. 

 

@frednork no problem. 

 

Seems the kernel is built without frequency scaling control support, which you won't be able to change. You can build the tools for that particular kernel if you go the long way and download everything you need to build stuff, but seriously... I would just submit it as a feature request - ask specifically for the ability to use an ondemand governor (or anything that lets you control speed) and then the ability to lower CPU speed during playback. Results can be quite eye-opening.

 

As suspected your OS is blacklisting tsc. Which is s**t, because you're missing out on the lowest-latency clock your hardware has. tsc does it's thing on each core on your CPU (both) and they're out of sync. You can try a newer BIOS for your motherboard to see if it fixes it. You could force your PC to boot as a single-core only machine, which would effectively fix the tsc issue by ignoring the second core and never needing to sync more than one tsc source. You'd do this by adding nosmp to your GRUB_CMDLINE_LINUX_DEFAULT line (the usual sudo nano /etc/default/grub to get in and edit - as in GRUB_CMDLINE_LINUX_DEFAULT="text 3 biosdevname=0 net.ifnames=0 isolcpus=1 processor.max.cstate=3 nosoftlockup nosmp" - then sudo update-grub to make it stick, then reboot). 

 

This should restore tsc but beware, it'll be a one-core machine only. You will not be able to set anything to the second core. 

 

Pros:

  • The system will drop latency everywhere as it won't use the SMP scheduler - it'll never pause and think about where it should execute anything
  • You'll have tsc back, which is the highest-accuracy, lowest-latency, lowest-overhead-to-read clock the OS has at its disposal

Cons:

  • One Atom core is not a lot - fine for me but I don't do DSD
  • That one core will be doing everything, so there's no chance of splitting off audio duties elsewhere

 

I would hope there's an updated BIOS that addresses your issues. I'd try it, start with Redbook audio and see if you like the result, then go higher and harder in frequency to find a limit. It's possible to have it boot either way off a menu. I'd suggest a second feature request to let SO users know if the system can't find tsc on a sync or other error, I'd imagine very few users ssh in and snoop around.

 

IRQ priority and affinity are different things. I would set priority for IRQ 17 at 99, the other two at 80 or so to start with. Your PC cannot do everything at the same time, though there's a chance the 'straight 99's' approach works (again, depends on resources). If p4p1 is your network device I wouldn't worry about it getting a sky-high priority, just play from RAM for a best experience, and at least find out your maximum MTU your router will support (then set that in SO). You'll get less interrupts. 

 

SO can take a different kernel just like any other Linux OS. The best thread I've found is this one https://ubuntuforums.org/showthread.php?t=2273355 though again, at your own risk! If you're getting started I'd get a spare SSD or whatever to try and tinker with until you've some confidence that you won't nuke your OS installation in a way that isn't too unrecoverable. At your own risk though happy to help you start though :)

 

Get a few minutes into it and there's a massive appreciation for the sheer amount of work that's gone into SO. Quite incredible.

 

Share this post


Link to post
Share on other sites

@rmpfyf the saga continues!!

Ok grub is now

 

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="text 3 biosdevname=0 net.ifnames=0 isolcpus=1 processor.max.cstate=0 nosoftlockup nosmp"
GRUB_CMDLINE_LINUX="text"

 

setting tsc seemed to work

 echo "tsc" | sudo tee --append /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
but

so@so-desktop:~$ dmesg | grep -i tsc
[    0.000000] tsc: Fast TSC calibration failed
[    0.000000] tsc: PIT calibration matches HPET. 1 loops
[    0.000000] tsc: Detected 1862.209 MHz processor
[    0.348964] TSC synchronization [CPU#0 -> CPU#1]:
[    0.348966] Measured 65058 cycles TSC warp between CPUs, turning off TSC clock.
[    0.348972] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[    0.654063] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x35af711ab28, max_idle_ns: 881590776687 ns
[ 1107.616943] clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode

 

what does this bottom line mean?

 

Previously I had this

so@so-desktop:~$ diff Snap1.txt Snap2.txt
9c9
<  17:        155    3454727   IO-APIC  17-fasteoi   ehci_hcd:usb2, ohci_hcd:usb                               3
---
>  17:        155    3562641   IO-APIC  17-fasteoi   ehci_hcd:usb2, ohci_hcd:usb                               3
11,12c11,12
<  23:       8313      31228   IO-APIC  23-fasteoi   ehci_hcd:usb1, uhci_hcd:usb                               4
<  24:         49     397723   PCI-MSI 1048576-edge      eth0
---
>  23:       8313      31277   IO-APIC  23-fasteoi   ehci_hcd:usb1, uhci_hcd:usb                               4
>  24:         49     409826   PCI-MSI 1048576-edge      eth0
14c14
< LOC:     214164     207368   Local timer interrupts
---
> LOC:     219827     212896   Local timer interrupts
19c19
< RES:      27803      20539   Rescheduling interrupts
---
> RES:      27839      20539   Rescheduling interrupts

 

 

Now I have this 

so@so-desktop:~$ diff Snap1.txt Snap2.txt
9c9
<  17:    5228440          0   IO-APIC  17-fasteoi   ehci_hcd:usb2, ohci_hcd:usb3
---
>  17:    5308775          0   IO-APIC  17-fasteoi   ehci_hcd:usb2, ohci_hcd:usb3
11,12c11,12
<  23:      16168          0   IO-APIC  23-fasteoi   ehci_hcd:usb1, uhci_hcd:usb4
<  24:     777417          0   PCI-MSI 1048576-edge      eth0
---
>  23:      16208          0   IO-APIC  23-fasteoi   ehci_hcd:usb1, uhci_hcd:usb4
>  24:     787235          0   PCI-MSI 1048576-edge      eth0
14c14
< LOC:     347678     282088   Local timer interrupts
---
> LOC:     352326     285866   Local timer interrupts

 

This is still unintelligble for me .Is it better?

 

I was also interested in how hard the cpu is working s and while there is some average figures in snakeoil I pulled my finger out and went searching for the linux command , htop didnt work but top did

previously the averages showing on snakeoil were around 0.05

 

playing a 44.1khz flac

 

Tasks: 119 total,   1 running, 118 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  0.3 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2037192 total,  1726716 free,   114920 used,   195556 buff/cache
KiB Swap:  2083836 total,  2083836 free,        0 used.  1877516 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   92   root        -51   0       0         0         0      S     3.3      0.0      1:46.36    irq/17-ehci_hcd
   93 root           -51   0       0        0         0      S     1.0      0.0      0:31.35     irq/17-ohci_hcd
 1117 root       -51   0  819516 38868 19068 S   1.0     1.9      0:40.92      mono-sgen
  576 root        -51    0       0      0            0         S   0.7      0.0     0:21.07     irq/24-eth0
    4 root      -2   0       0      0      0 S   0.3  0.0   0:02.22 ktimersoftd/0
    8 root      20   0       0      0      0 S   0.3  0.0   0:00.17 rcu_preempt
 3282 so        20   0   40500   3776   3208 R   0.3  0.2   0:01.19 top
    1 root      20   0  119612   5736   4008 S   0.0  0.3   0:01.99 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:01.06 ksoftirqd/0
    6 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_sched
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.30 rcuc/0
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kclksetdelayd
   12 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 posixcputmr/0
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kcmosdelayd
   14 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/0

 

for dsd256

 

top - 13:34:55 up  1:38,  1 user,  load average: 0.57, 0.31, 0.26
Tasks: 119 total,   2 running, 117 sleeping,   0 stopped,   0 zombie
%Cpu(s): 21.6 us,  0.0 sy,  0.0 ni, 77.7 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem :  2037192 total,  1699952 free,   140876 used,   196364 buff/cache
KiB Swap:  2083836 total,  2083836 free,        0 used.  1851512 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1117 root     -51   0  950620  59896 9068 S   4.6       2.9         1:35.35 mono-sgen
   92    root     -51   0       0          0            0   S    3.6       0.0        2:55.47 irq/17-ehci_hcd
  576   root       -51   0       0          0           0     S   3.6         0.0      1:01.35 irq/24-eth0
   93    root     -51   0         0        0           0      S    1.0       0.0        0:51.10 irq/17-ohci_hcd
    3 root          20   0          0      0             0      R   0.3         0.0   0:01.78 ksoftirqd/0
 1106 root     -51   0  978292  50592  20104 S   0.3       2.5   0:11.20 mono-sgen
 4499 so        20   0   40504   3756      3180   R   0.3        0.2   0:01.80 top
    1 root         20   0  119612   5736   4008 S   0.0  0.3   0:02.00 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    4 root      -2   0       0      0      0 S   0.0  0.0   0:03.81 ktimersoftd/0
    6 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.27 rcu_preempt
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_sched
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.52 rcuc/0
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kclksetdelayd
   12 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 posixcputmr/0
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kcmosdelayd
so@so-desktop:~$
 

for dsd 128

top - 13:42:37 up  1:46,  1 user,  load average: 0.33, 0.48, 0.40
Tasks: 119 total,   1 running, 118 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.0 us,  0.9 sy,  0.0 ni, 97.6 id,  0.0 wa,  0.0 hi,  0.5 si,  0.0 st
KiB Mem :  2037192 total,  1705584 free,   135320 used,   196288 buff/cache
KiB Swap:  2083836 total,  2083836 free,        0 used.  1857312 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   92 root     -51   0       0      0      0 S   3.3  0.0   3:11.32 irq/17-ehci_hcd
 1117 root     -51   0  950620  53700  19064 S   2.3  2.6   1:50.82 mono-sgen
  576 root     -51   0       0      0      0 S   2.0  0.0   1:13.62 irq/24-eth0
   93 root     -51   0       0      0      0 S   0.7  0.0   0:55.56 irq/17-ohci_hcd
 5004 so        20   0   40500   3728   3160 R   0.3  0.2   0:00.45 top
    1 root      20   0  119612   5736   4008 S   0.0  0.3   0:02.00 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:01.95 ksoftirqd/0
    4 root      -2   0       0      0      0 S   0.0  0.0   0:04.16 ktimersoftd/0
    6 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.30 rcu_preempt
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_sched
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.56 rcuc/0
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kclksetdelayd
   12 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 posixcputmr/0
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kcmosdelayd
   14 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/0
 

Although things do seem to vary a bit with it coming down to .2 load average even on 256 at times


 

Share this post


Link to post
Share on other sites

@frednork  An easier way to access TOP is via the Snakeoil interface. Go to the System tab and click the button labelled TOP.

 

Also, when you want to add a process priority in the Snakeoil tab, go to TOP first and note the exact spelling of the command. The commands that pop up near the top of the list are the ones of more interest. Use the same spelling when you enter them in Process Priority in the Snakeoil tab. If you set them at 99, then when you go back to TOP, you should see "rt" for that command in the PR column. Otherwise you'll see the number you entered.

 

Note that TOP within Snakeoil may abbreviate the command name with a "+" at the end. It will still work typing that or you can use the full name as you see when ssh-ing into TOP.  I can see that it didn't work in your last attempt because you only entered part of the command name.

 

Here's an example from my system:

 

 

Screen Shot 2018-09-02 at 1.10.40 pm.png

Screen Shot 2018-09-02 at 1.13.47 pm.png

Share this post


Link to post
Share on other sites
1 hour ago, frednork said:

Also forgot to mention, Bios seems to be latest so not much joy there

Try turning off speedstep, and any C-states you can access in the BIOS.

If in the rare case you BIOS let's you disable CPU cores, try disabling one of them, and seeing if it makes any difference to TSC syncing.

Share this post


Link to post
Share on other sites

@frednork damn, she runs a lot of processes for an audiophile OS...

 

That you have straight zeros on core 1 for interrupt usage suggests you’re currently in no-SMP (single-core) mode. It would also seem you can reliably set tsc for a clock source - if you cat the current clocsource file you should be able to validate this.

 

Your OS is ill still check for warp across different tsc signals, and it will still throw up a note here, though I’d doubt its super important to single core operation.

 

Seems to run a tickless or dynticks kernel (no surprises) and a swap file (surprising, maybe I have that wrong).

 

Most importantly - what are you hearing?

 

I’d use different hardware - tsc is important. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...