I would suggest you go ahead and use what IP SLA offers. If there are gross differences, IP SLA testing is likely to be "good enough" for "seeing" gross differences and/or differences from what should be expected from the technology being used.
The level of testing and/or detail you appear to be after, often is only needed when you're running down an issue why your overall performance isn't as expected, and even in such cases, what's unexpected often stems from not understanding the technology.
Perhaps a real case example, why I'm of such opinion, a couple of decades ago, a large Enterprise was offered "like" ATM circuits to replace frame-relay circuits, i.e. "like" in same bandwidth for about 15% less cost.
Well, that Enterprise jumped at reducing their data line costs by 15%. So, they started to move to ATM and noticed WAN throughput performance dropped through the floor for the same "spec" circuits. So, they asked me to investigate.
Many of the frame-relay links were DS1s with a "CIR" being some fraction of the full link bandwidth, e.g. CIR of 512 Kbps on a 1.5 Mbps link. With frame-relay, you can "burst" over CIR, to max link bandwidth.
The replacement ATM links would be "like", e.g. SCR of 512 Kbps, PCR of 1.5 Mbps on a 1.5 Mbps DS1.
As in turned out, when ATM links were configured for SCR of 512 Kbps and PCR of 1.5 Mbps, the PCR is only good for a very short duration, like enough for one or two max size Ethernet frames, then the ATM interface maintains SCR.
FR, though, would run at full link rate unless you explicitly shaped your interface.
So, effectively, FR could run all the time at 1.5 Mbps, while ATM would average a max of 512 Mbps. This is why such an impact was noticed.
First step was to "lie" to ATM interface, and set SCR to 1.5 Mbps. Then FR and ATM DS1 should (?) perform the same. However, ATM still averaged about 15% less (enough, still, to be quite noticeable) throughput. (Hmm, what was the price difference, again?)
The reason ATM still had less throughput, a packet had to be split into ATM cells, each 53 bytes, with 48 bytes for payload. I.e. you lose 9.5% bandwidth for "cell tax". Then as every cell had to be exactly 53 bytes, you would need to pad out the last cell. E.g. a 64 byte packet, like an ACK, would require two 53 bytes cells, i.e. you now lose about 40% of your bandwidth for overhead. Lastly, if even one cell in a transmitted packet was lost, the whole packet would have to be retransmitted.
So, if someone had studied the technology or tried even the simplest of performance tests, on one ATM link, these gross differences, should not have gone unnoticed before the Enterprise committed to making a mass conversion to ATM.
Oh, BTW, ATM required new interface modules for the routers, and those ATM modules required an IOS feature upgrade (from IPBase to IPServices) which also increased contract maintenance costs. It surely "saved" money.
Lastly, there's nothing wrong with using ATM, and it does offer some features that FR doesn't. One useful feature, was the ATM modules were IMUX capable, i.e. you could connect multiple DS1s and the bundle would act as a single link with the aggregate bandwidth of bundle (in principle, much like MLPPP, but wire-rate). Very handy to replace one FR DS1 with two ATM DS1s, which more than replaced the lost bandwidth for a single FR DS1 vs. ATM DS1. ; )
