I've found that TBBs readings - over the years - have often been slower than other testers: no idea why.
It will depend on exactly how the meter reads the speed - which is a more complicated area than one may first assume.
Part of TCP's flow control heuristics is "slow start" where by the window size (essentially how much data is "in flight" at any given time) of any given stream starts low and expands as it becomes clear that the path between hosts can cope with more (and needs a larger window to not lose speed due to acknowledgement latency). Some speed testers ignore the first portion of the data received, those that don't will show a lower rate as the include the "warm up" period as well as the full-speed period in their average. Even a tester that tries to account for slow-start might not wait long enough before starting to take readings, on connections as fast as we have today. This is particularly apparent with short tests. A test that transfers a fixed amount (say 50Mbyte) would be fine for testing old 512kbit links, probably not long enough to get a great reading from a 2Mbit link, and anything much faster would most likely not be up to full speed by the end of the test. 50mbyte is a exaggerated example today, but testers implemented with speeds between 2 and 8mbit in mind may give lower results than expected on 20+mbit connections unless their design was foresighted enough to adjust their behaviour as speeds scaled up.
Other differences occur with which statistics methods testers use to account for the fact our links can sometimes be bursty. A meter that reads the highest value it sees will result in a larger reading than one that displays an average of all readings. Some attempt to remove spikes that may make a reading artificially high or low by taking many readings and discarding, for example, the highest 5% and/or slowest 5% before calculating the average. You can't compare the results from two speed testers meaningfully without knowing what methods each uses to derive the figures they display.