TBB speedtests, HomeHub 3 and TPLink gigabit switch

I noticed odd behaviour and am posting it here (1) partly in case anyone can give more detail for possible reasons behind it and the real application effects it might have, and (2) partly in case it helps clarify anything for anyone else in a similar situation.

My setup included BT HomeHub3 connected to basic TPLink gigabit switch connected to Windows 8.1 computer.
Thinkbroadband speed tests showed TBBx1 12Mbps, HTTPx6 65Mbps, upload 18Mbps. (results fairly consistent but averaged/rounded for simplicity)

Using either a direct connection HH3 gigabit port to computer, or using HH3 100Mbps port to switch to computer, gives TBBx1 65Mbps,, other results as before.
I am now using the HH3 100Mbps port to switch to computer setup without issues, but have questions.

- What is the likely cause of that incompatibility, given that each device seems to work fine?

- Are there likely to be computer settings (MTU?) that would resolve it even using the HH3 gigabit port? (HH3 and switch too basic to have any settings).

- Most applications do not seem to notice any difference. For example SquirrelSave was able to take full advantage of download and upload speeds with the 'TBBx1 wrong' setup. However, BT Cloud did see an improvement from a very poor 1.6 Mbps upload to a poor 3.9Mbps (still not 100% proven this was due to my network change). What characteristics of application are likely to suffer in the same sort of way as the TBBx1 test?

Tbbx1 is a tcp download using a single thread so it might be impacted by a network card and full half duplex issues

Is latency consistent?

Httpx6 by using six downloads can get around many bottlenecks

Thanks. Looking around it seems that there are quite a few issues with the HomeHub 3B gigabit port.
As far as I could see latency was consistent, as measured by pings or tracerts, and I didn't see much evidence of lost packets.

I know multithreaded operation can often get over latency issues, but if there were duplex related packet loss issues I would expect them to suffer almost as much as single threaded. Maybe somehow the outbound packets were getting through more reliably than the incoming control packets.
Just out of interest I may go back temporarily to the old configuration and test for packet loss at the same time as doing a TBBx1 test.

Thanks again anyway.