Technical: Bufferbloat bad, but better. Still far worse than bridge mode.

Options
Jacques_Assert
Jacques_Assert Posts: 159 ✭✭
in Internet

New installation, tested with DSLReports speedtest consistently received 'F' for Bufferbloat (>400ms).

Today, after resolving a problem (caused by 7.1.1.2.7b8 firmware?) Bufferbloat is consistently 'C'( <200ms).

This is better than 'F' but still garbage compared to Fizz in bridge mode ('A' <30ms).

Fizz 60/10 (7.1.1.2.7b8 firmware) avg. download 88ms, upload 45ms (high: 175ms)

http://www.dslreports.com/speedtest/68277755

Fizz 60/10 (bridged): avg. download 34ms, upload 26ms (high: 44ms).

http://www.dslreports.com/speedtest/68277775

When the same hardware on the same connection can produce results that are over twice as good, why doesn't Fizz make the effort to demand the open and well documented fq-codel QoS capability into software that will significantly improve performance with no extra hardware costs?

Note: bridge mode routing via low-end consumer Ubiquiti ER-X using QoS (fq-codel).

Best Answer

  • ValentinMTL
    ValentinMTL Posts: 80 ✭✭
    Answer ✓
    Options

    I totally agree that bufferbloat is a problem.

    For the companies offering a pure bridge modem (no wifi or router), it is up to the customer to implement QoS.

    As far as I know, you have to configure your connection speed for QoS to work properly, maybe that is holding them back? The router would need some sort of auto-configuration or provisioning to determine the up/down speed. Else you would end up with customers "calling" support because their speed has not increased following a plan change.

Answers

  • Jacques_Assert
    Jacques_Assert Posts: 159 ✭✭
    edited May 2021
    Options

    This may sound like a rant, but if you compare the performance of the connection with and without QoS enabled, it's like ranting about cars with an on/off switch for a throttle: it's either idle or WOT. QoS should be the default, not some high-end feature. It's necessary for VoIP, Zoom, interactive gaming, and anything else interactive on the web, and improves performance for everyone.

    Why do ISPs not demand this from modem suppliers up front? Do they think we enjoy choppy Zoom meetings?

    The Videotron equivalent EMG2926-Q10A includes StreamBoost, Zyxel's brand name for zero tuning fq-codel QoS support.

    Their modems used to explicitly mention it in the UI, but no longer do so. Whether that means it's always on or deleted is unknown, but the Videotron modems have never reported 'F' for bufferbloat as Fizz modems have.

    They already have a modem that supports QoS that works with the same infrastructure. But can we use it? No. :/

    Then can we use a smaller wall mountable (Videotron) modem in bridge mode and skip the wasted Wi-Fi stack? No. :/

  • Jacques_Assert
    Jacques_Assert Posts: 159 ✭✭
    edited May 2021
    Options

    I'm using bridge mode with a Ubiquiti ER-X using their Smart Queue Management (i.e. fq_codel) QoS.

    I have a 60/10 service. 

    With QoS and bandwidth set for 70/12, I see A+ for bufferbloat (<5ms) and <1% packet loss.

    http://www.dslreports.com/speedtest/68372376

    Without QoS, I have D for bufferbloat (<400ms) and <5% packet loss.

    http://www.dslreports.com/speedtest/68372082

    Since the Hitron (cable modem) already has the connection speed via DOCSIS, it should be trivial to communicate that to a QoS algorithm within the Hitron (router). Any speed penalty is trivial. I see 64/11 with QoS enabled and 67/10 without QoS (all figures rounded).

    Wouldn't a massive improvement in real-time performance be an obvious positive market differentiator for Fizz? It's also a basic requirement for online anything, including Zoom, VoIP, and online gaming.

    I don't understand why QoS like fq_codel this is not the default.

This discussion has been closed.

Categories