Script for automated testing of computer latency.

Trying to run the script, but I'm getting an error message:

(firefox:2062): dconf-CRITICAL unable to create file 'home/mill/.cache/dconf/user' :permission denied. Dconf will not work properly.

The script is running and reporting latency, but the error pops up when the Firefox/Vimeo test window opens. Video loads but does not start playing. Error message repeats almost continuously.

Complete and utter Linux novice, so I'm sure it's something I've done (or not done) regarding folder permissions. Did cut/paste the 'sudo ./lcnc-hw' command per instructions, so it isn't that.

Any suggestions?

Thanks,
Ralph

spumco wrote: Trying to run the script, but I'm getting an error message:

(firefox:2062): dconf-CRITICAL unable to create file 'home/mill/.cache/dconf/user' :permission denied. Dconf will not work properly.

The script is running and reporting latency, but the error pops up when the Firefox/Vimeo test window opens. Video loads but does not start playing. Error message repeats almost continuously.
...
Ralph

I had the same issue on Mint 19.3.
I used to change the ownership on the dbconf dir and anything in it
Then used to get the correct read/write permissions.

This allowed things to work. The video still does not auto play. I just kick that off with a mouse click by hand at the start. But the continual stream of errors has gone.

Cheers - J.

That did the trick. Testing in progress.

Cadmanxu wrote:

I have added the text from the .hw file to a text document. In the editor when making the answer it does not let me insert the file by the extension ...

Attachment not found

Attachment not found

 

Cadmanxu
I know, my answer is late. So, if obsolete, kindly disregard.
You get "Unexpected realtime delay on task 0 with period 25000". That means you need to increase base thread limit from 50000 to 100000.
Further, you have sound modules active. Block them.
When done, repeat running the script with latest version ( here ) and place results (.hw file) in this thread .
greez
chris

This change to the latency-histogram line 696 messes up the current script feeding off "secs" for reporting to the hw log file.

rdeeming wrote:

This change to the latency-histogram line 696 messes up the current script feeding off "secs" for reporting to the hw log file.
 

rdeeming
Actually the part for latency in the xyz.hw file is just the last two lines of the xyz.lat file that contain latency data. (like that, servo and base thread are covered).  I'll have to check if at all and if, how that change affects logging of latency data. Hope I can do it soon.
Greez
chris

Maybe it's useful to report my latency experience. I am sharing only some overall figures, not the entire logs, sorry for that ...

Hardware: Asus M2NPV-VM, Athlon X2 BE-2350, Matrox Millenium II, 4GB memory, SSD.
Software: Debian 10 with RTAI.

The latency (base thread ) observed by running the script for more than 12 hours was around 14us.

But the more interesting result was obtained by running over ssh and disabling graphical interface completely on the linuxcnc machine ( runlevel 3) : under 7us for 12 hours test. This time I have only used latency-histogram and I have generated relevant load for a "runlevel 3" situation.

Disabling graphical interface is definitely not a new thing.  I wonder if anybody is  successfully using such setup for real action.

msurmei wrote:

Maybe it's useful to report my latency experience. I am sharing only some overall figures, not the entire logs, sorry for that ...

Hardware: Asus M2NPV-VM, Athlon X2 BE-2350, Matrox Millenium II, 4GB memory, SSD.
Software: Debian 10 with RTAI.

The latency (base thread ) observed by running the script for more than 12 hours was around 14us.

But the more interesting result was obtained by running over ssh and disabling graphical interface completely on the linuxcnc machine ( runlevel 3) : under 7us for 12 hours test. This time I have only used latency-histogram and I have generated relevant load for a "runlevel 3" situation.

Disabling graphical interface is definitely not a new thing.  I wonder if anybody is  successfully using such setup for real action.
 

This is interesting! Could you kindly post the .hw file? That's a summary of hardware, actual test run log (I am particularly inerested in the no of glxgears and firefox) and just the latest two lines of the very latency data. How did you manage to see what's going on? remote X-server?
Greez
chris

seuchato wrote:

rdeeming wrote:

This change to the latency-histogram line 696 messes up the current script feeding off "secs" for reporting to the hw log file.

Actually the part for latency in the xyz.hw file is just the last two lines of the xyz.lat file that contain latency data. (like that, servo and base thread are covered). I'll have to check if at all and if, how that change affects logging of latency data. Hope I can do it soon.

If this turns out to be a problem, can I suggest grepping for both "secs" and e.g. "us sdev" to keep the script compatible with both old and new versions of latency-histogram? "secs" should get lines from the old version, and "us sdev" should get lines from the current version. 'grep -e' should do the trick?

a solution is a solution. As an engineer, I could not oppose to a solution :-]