Use GNS3, CML, Eve-ng for those delay/jitter measurements
Even with emulation software that's running actual device binary code, actual timing will be different from real hardware and even relative timing will very likely be different. Different enough that stat analysis can be misleading from this alone.
Have you ever studied PC benchmark stats? Two different platforms, even with the same overall cumulative score may have very different individual benchmark test results. I.e. testing one specific app's performance on such equally overall scored PCs may have noticable different performance for a specific app. (Which is why various app tests are measured.)
So, how any one specific test case behaves, under an emulator, can be very different from actual hardware.
Actually, real processing time, for a performance test can vary much between different actual real network devices too. Although, usually not enough to impact real world service needs.
So, to summarize, an emulator should allow you to run whatever tests you want, but the actual results may not be truly representative.
BTW, so why am I "fussing" so? For two reasons.
First, I don't know exactly what the goals of the project are, but mention of jitter possibly implies need for highly accurate results.
Second, as I mentioned in a prior reply there are lots of variables involved with QoS and lots of information is often needed.
Possible example, a real world case when I first started working with QoS.
A couple of decades ago I was trying to improve perceived network performance to WAN connected branches. This was when a high speed WAN circuit was a full DS1 1.5Mbps (while users usually had 100Mbps).
So, I implemented a QoS policy, I thought would improve perceived performance.
There appeared to be little improvement, QoS showed its policy active.
I was quite befuddled that there was so little improvement. The QoS impact was barely noticable. So much so, it might be argued QoS was worthless.
However, I stumbled across a Cisco tech note explaining possible poor performance of VoIP (which at that time we weren't doing) on an ATM (also at that time we weren't using) due to the interface's physical FIFO queue. Basically, the QoS queues only applied to packets that overflowed the interface's physical queue. It was suggested to configure the physical queue depth, smaller, using the tx-ring parameters.
I did that, and now my QoS had the positive impact I had sought!
This particular configuration option, often, isn't much mentioned in much Cisco QoS documentation. But I found it could make a huge impact to the effectiveness of QoS.
So, without having a broad knowledge of QoS, it can be quite easy to obtain less than optimal results possibly leading to misappreciation of QoS effectiveness.
Laugh, the WAN lead engineer thought QoS was just worthless "voodoo" until the day he came in one morning, and as he described it, his phone was lit like a Xmas tree of branch sites asking what's wrong with the network? He found one of the two HQ WAN routers had dropped its QoS config. He reapplied it, and the phone calls stopped. He later remarked to me, that QoS, apparently, wasn't voodoo.
