I have been trying a setup consisting of an I3 laptop as a roon server and a Jetway NF9C atom board as a renderer running roonbridge. more detail is available here
https://www.stereo.net.au/forums/topic/8.../?page=124
Some suggestions on the thread have been to use tsc as the timer and this is possible on the I3 but not on the Atom board
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
I tried another atom board with similar result. Is this an atom issue or SO?
Another suggestion was to underclock the CPU, this didnt seem possible within SO. Is it or will it be possibe?
(16-Sep-2018, 10:35 PM)frednork Wrote: [ -> ]I have been trying a setup consisting of an I3 laptop as a roon server and a Jetway NF9C atom board as a renderer running roonbridge. more detail is available here https://www.stereo.net.au/forums/topic/8.../?page=124
Some suggestions on the thread have been to use tsc as the timer and this is possible on the I3 but not on the Atom board
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
I tried another atom board with similar result. Is this an atom issue or SO?
Another suggestion was to underclock the CPU, this didnt seem possible within SO. Is it or will it be possibe?
Did you disable hyper-threading in your NF9C?
This message "Measured 64869 cycles TSC warp between CPUs, turning off TSC clock." means the time isn't sync'ed across the CPUs. i.e. CPU A is reporting the time as X, CPU B is reporting time at that moment is 64869 cycles after X.
My stereo is out of commision at the moment as my PSAudio P5 can't power up so can't test this out atm. It could be a linux kernel issue or a system one, can't be sure at the moment.
But for now, try the following:
- Disable all power saving options in the BIOS
- Look for HyperThreading and turn it off.
- Make sure HPET is turned on in the BIOS (You can still tell Linux to use TSC even with this on).
If you can, generate a diagnostic file with all the options set above and send it to me to have a look.
(17-Sep-2018, 08:41 AM)agent_kith Wrote: [ -> ] (16-Sep-2018, 10:35 PM)frednork Wrote: [ -> ]I have been trying a setup consisting of an I3 laptop as a roon server and a Jetway NF9C atom board as a renderer running roonbridge. more detail is available here https://www.stereo.net.au/forums/topic/8.../?page=124
Some suggestions on the thread have been to use tsc as the timer and this is possible on the I3 but not on the Atom board
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
I tried another atom board with similar result. Is this an atom issue or SO?
Another suggestion was to underclock the CPU, this didnt seem possible within SO. Is it or will it be possibe?
Did you disable hyper-threading in your NF9C?
This message "Measured 64869 cycles TSC warp between CPUs, turning off TSC clock." means the time isn't sync'ed across the CPUs. i.e. CPU A is reporting the time as X, CPU B is reporting time at that moment is 64869 cycles after X.
My stereo is out of commision at the moment as my PSAudio P5 can't power up so can't test this out atm. It could be a linux kernel issue or a system one, can't be sure at the moment.
But for now, try the following:
- Disable all power saving options in the BIOS
- Look for HyperThreading and turn it off.
- Make sure HPET is turned on in the BIOS (You can still tell Linux to use TSC even with this on).
If you can, generate a diagnostic file with all the options set above and send it to me to have a look.
Thanks for your reply,
1, 2 and 3 were already done.
Have sent the diagnostics file
Can confirm the same behaviour in my own setup. Pretty sure this is the cause:
Code:
clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode
Snakeoil is using what is called a 'TICKLESS' kernel. Probably this is the cause.. Give me a few days to experiment and work out a solution. This will likely use another kernel..
Apologies.. Went out today to listen to a great HT setup. And then went out with the Mrs and only just got back home. So unfortunately can't do the kernel thing, but will try and test this tomorrow if not the day after.
@
frednork
Download the
300 Hz kernel, install it and reboot your PC. Now see if TSC is working. If you don't see this in the list, generate a diagnostics file and send it over. thanks.
(25-Sep-2018, 08:08 PM)agent_kith Wrote: [ -> ]@frednork
Download the 300 Hz kernel, install it and reboot your PC. Now see if TSC is working. If you don't see this in the list, generate a diagnostics file and send it over. thanks.
Thanks for that
Still not in list
might be a mixup with the kernel names. I couldnt load the i86 but could the amd
get
dmesg | grep -i tsc
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2133.441 MHz processor
[ 0.205515] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.205516] Measured 13912360 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.205522] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 0.336518] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1ec0970ffc0, max_idle_ns: 440795262269 ns
Will send the diagnostic over
Cheers
(26-Sep-2018, 09:05 AM)frednork Wrote: [ -> ]Thanks for that
Still not in list
might be a mixup with the kernel names. I couldnt load the i86 but could the amd
That's normal. Snakeoil comes in 32 bit and 64 bit variants. Since you're running the 64 bit edition, the AMD file will work, but the i686 one will not. (It's a convention I guess, folks called it amd because this is company releases the first 64 bit chip, and the name stuck).
(26-Sep-2018, 09:05 AM)frednork Wrote: [ -> ]get
dmesg | grep -i tsc
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2133.441 MHz processor
[ 0.205515] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.205516] Measured 13912360 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.205522] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 0.336518] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1ec0970ffc0, max_idle_ns: 440795262269 ns
Will send the diagnostic over
Got that. So it seems the TSC just can't be sync'ed properly across the 2 CPUs. I'd play with the code abit and get back to you on another test. In the meantime, try this 300 Hz kernel and report back on the SQ. Let me know if it subjectively if it sounds better, worse or no difference.
@
frednork Re-download and upload the amd64 version of the 300 Hz kernel and reboot. Let me know how it goes..
(26-Sep-2018, 05:20 PM)agent_kith Wrote: [ -> ]@frednork Re-download and upload the amd64 version of the 300 Hz kernel and reboot. Let me know how it goes..
Thanks again!
Unfortunately it doesnt load
Expanding kernel file...
*** ERROR *** Invalid Snakeoil OS kernel