On 2022-01-26 11:35 p.m., Pankaj Jangid wrote> I don’t want to file any
bug report till I have some concrete data. So
my question is - how do I diagnose such an issue and produce some data
for debugging. So that I can hand it over to maintainers.
This one line script will sleep for 0.01 seconds at a time and then
print the current time in milliseconds to a file.
while `true`; do sleep 0.01; date +"%T.%3N" ; done > time.txt
Run that and look at the output in time.txt afterwards to make sure the
system didn't actually stop. (even if it stopped it might still be a
graphics issue, but at least it's another data point).
Output will look like:
23:41:20.670
23:41:20.686
23:41:20.701
23:41:20.715
23:41:20.732
23:41:20.749
23:41:20.766
23:41:20.785
23:41:20.803
23:41:20.821
(due to the overhead of running sleep and date there's more than 0.01
seconds per iteration)
This script will give you the biggest time differences:
perl -e 'while(<>){chomp; $old_time = $time; $time = $_; $old_ms =
$cur_ms ; $_ =~ s/.*[.]//; $cur_ms = $_; $delta = $cur_ms - $old_ms;
$delta = $delta % 1000; if (defined($old_ms)){print "$delta: $old_time
$time\n";}}' < time.txt | sort -n | tail
The output is:
20: 23:50:50.384 23:50:50.404
20: 23:50:51.036 23:50:51.056
20: 23:51:06.262 23:51:06.282
20: 23:51:46.577 23:51:46.597
21: 23:50:42.553 23:50:42.574
21: 23:50:43.999 23:50:44.020
24: 23:50:59.126 23:50:59.150
25: 23:50:41.680 23:50:41.705
25: 23:50:50.192 23:50:50.217
25: 23:50:53.255 23:50:53.280
So in my case the biggest delay was 25ms (at time 23:50:53). If you see
anything longer than 100ms you'll know the system has gotten stuck
during the blank interval.
Bijan
