[SOLVED] TSC on Atom CPU and downscaling CPU frequency

[agent_kith]

@"frednork" ,

two quick comments.

Cyclic Test
What's your cyclictest latency numbers? Bear in mind Snakeoil uses nanoseconds (almost everybody else uses microseconds). So while it seem like your values look skyhigh, you need to divide by 1000. The reason to use nanoseconds is it's not difficult to get the latency down to 1 us with the right hardware when using Snakeoil OS. I did this with my Core2Duo a while back, and I still prefer my atom board, despite the worse latency numbers. For all intents and purposes 1 us latency vs 100 us isn't much in my point of view.

More information here. Also not sure if it's mentioned in this thread or somewhere else, the way cyclictest is running at the moment can be a bit deceptive. It is not showing you everything.

cyclicscope is a better presentation and more informative. This is something I intend to work on and hopefully get it out soon. In case you are unaware what that is, it looks something like this:
[Image: test.png]

Now the histogram is an important feature, in the above example it is telling you the latency is less than or equal to 50 us since time of measurement (2017 measurements so far). You then look at the statistics and see the latency so far is spread across 1 us to 8 us, and over 2017 measurements, the average is 2.532 us.

Now if you have a problematic hardware somewhere, you'd see spikes (in the other rows under the histogram. Each row is called a bin). And you can identify the interval of the spikes by looking at the time history box (green box). That box will tell you if the spike is regular, or random.



Timer Frequency
It's actually the other way round, lower is better.

Code:

100 Hz is a typical choice for servers, SMP and NUMA systems
with lots of processors that may show reduced performance if
too many timer interrupts are occurring.
---
250 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems. If you are going to be using NTSC video
or multimedia, selected 300Hz instead.
---
300 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems and exactly dividing by both PAL and
NTSC frame rates for video and multimedia work.
---
1000 Hz is the preferred choice for desktop systems and other
systems requiring fast interactive responses to events.

Long story short, 1000 Hz kernel is really needed when you are using the computer directly. e.g. if you are using a keyboard/mouse, using a 1000 Hz kernel will make the system appear responsive.

If you are using a kernel that's on a 100 Hz timer... If you are a fast typer, or when you use a mouse, you may notice a degree of lag on the screen. E.g. keys show up slower, mouse don't quite move the way you want it to be.

The lag is not going to be an issue in Snakeoil because it is designed to run as headless. Graphical envrionments are VNC'ed in, the computer only designed to play audio and run server like applications. As such there is no user interaction, and it doesn't need that high frequency. Why? Because audio is buffered.

So what is this 100/250/300/1000 Hz anyway? It's the number of the times the OS will 'ask around' and see if any thing require attention. e.g. with keyboards, the OS will poll the keyboard driver 1000 times a second to see if a key is pressed. If you type at over 100 words per minute, that's like 500 too 800 characters a minute, and that's can be more than 5-10 keys a second. Believe it or not, if you use a kernel that's 100 Hz, the keys will appear on the screen slower (time taken to read keyboard input, time taken to render it on screen, etc).

For audio playback, audio is buffered (placed in memory), e.g. MPD has half a second of audio buffer, and the operating system will check this half second buffer 300 times a second to see if there's any data ready to be sent to the hardware. Checking this 1000 times a second if it's ready to be sent is not going to be an improvement. If you are using a player with absolutely no buffer, then a 1000 Hz kernel is necessary.

There's also this weird issue. If your audio system has a ground loop, using a 1000 Hz kernel actually generates some weird high frequency white noise..

And that timer is just one part of the story. Snakeoil is running a Real Time kernel. That means everything is preemptable. If you set your players to run at real time, that is going to cause unnecessary issues.

Question is if tickless is better than 100 Hz? I actually did this experiment a while back. Unfortunately I cannot remember the results now as I spent too much time on coding up Snakeoil OS, and not enough time listening..