Erm, the huge dips going back to zero are not a sign of bufferbloat but simply caused be the way speedofme performs its measurements; it will use iteratively bigger and bigger test files and the gaps appear when a new filetransfer os started (this is obvious once you look that the duration of the turquoise pats between the dips gets longer and longer). But honestly, the speedofme test is quite nice looking but not the most stringent test for bufferbloat.
Have a look at https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803/11 for recommendations how to use the dslreports speedtest for probing bufferbloat... Yes I see you used that test as well, but please post the results here as well.