replayed startup times do not always correlate with the X applications startup times

[dev-jam]

I found an effect that I cannot explain. As I read the documentation, replayed startup times should correlate with the startup times of the X applications:

"The startup benchmark exercises X applications, which must therefore
be installed and properly working. If this is a problem, run
replayed-startup instead (see the simple invocation examples
below). The latter usually provides accurate results, without
executing any X application."

On one NVMe SSD and one SATA SSD, both Samsung, I found lowered startup times (compared to the rest) for bfq in the replayed condition (for all three classes of applications) but not in the X application startup times. Is this a bug or could it have something to do with the SSD brand? I don't see it with a WD NVMe SSD.

My data from the NVMe Samsung SSD:

replayed_gnome_terminal_startup-time-table.txt (lowriter and xterm have the similar values):

Workload none bfq kyber 0r-seq 0.12725 0.13025 0.12925 10r-seq 2.2725 0.14875 2.22725 5r5w-seq 3.206 0.13975 3.0605

gnome_terminal_startup-time-table.txt (lowriter and xterm have the similar values):

Workload none mq-deadline kyber bfq 0r-seq 0.29275 0.292 0.29425 0.28575 10r-seq 0.29825 0.32775 0.33325 0.3475 5r5w-seq 0.31475 0.31025 0.304 0.316

On the WD NVMe SSD, the replayed condition does show a good correlation with the X application startup times but here I see that bfq does much better than average on 10r-seq but much worse than average on the 5r5w-seq.

replayed_gnome_terminal_startup-time-table.txt

Workload none bfq kyber mq-deadline 0r-seq 0.13875 0.174 0.164 0.16925 10r-seq 0.926 0.245 0.99825 0.982 5r5w-seq 0.9885 2.98925 0.9625 0.97775

gnome_terminal_startup-time-table.txt

Workload none mq-deadline kyber bfq 0r-seq 0.277 0.2845 0.29825 0.313 10r-seq 0.9695 0.953 0.975 0.389 5r5w-seq 0.9285 0.95275 1.05025 1.60125

Best, Bob