How to find the source of increased latency

Bell is telling you the truth. When you try to push 5Mbps (or more) into a 5Mbps connection, everything files into a neat little order (read: queue.) Your ping goes out without delay because there's no backlog. The reply, however, is now at the end of the queue. TCP is doing exactly what it's supposed to here -- the sender is filling the allowed receive window.

There are things you can do on your side of the line (QoS, WRED, etc.) to help reduce the effects, but this is the sort of thing you're going to see when there's a large difference between sender and receiver bandwidth. I've lived with it for years (T1, 6Mbps DS3, even 10Mbps cablemodem) You could ask the ISP to reduce the queue size on their side, but they're not likely to do it, as it'll result in packet drops.

I don't know your full circumstances, but if an accurate figure for device latency really mattered to me then I would hire specialised equipment for this task. I'm in the UK and there are specialist suppliers who hire out network analysis equipment like this. You will need a device that can take your payload and generate TCP sessions. I haven't done this for a while so I don't know who sells what any more. I used to use Wandel and Goltermann and Smartbits but it was a long time ago. I also never needed to use real payload myself, but you obviously do.

An alternative would be to use a couple of network taps and a packet broker that can apply hardware time-stamps before handing to a simple Wireshark PC. If the required accuracy is no better than about 100 microseconds, you could even just use two taps and a properly-configured PC with Wireshark. You will have to ensure that NIC interrupts are not coalesced and there may be other settings to optimise. Using Wireshark you just match packets across the two captures, and take the time difference. You can export the capture files to a spreadsheet to match them. You will need to try to assess what the precision you acheive.