Running the modem in Gateway mode or Bridge mode with a router behind it? I agree with @gp-se, finding two modems back to back with similar UI corruption is extremely odd, you should be buying lottery tickets! Are you running blockers on those web browsers? More importantly, are you running the same blocker(s) on all of them?
Maybe not, but, to prove that the issue exists or not, I'd connect a pc/laptop to the modem in Bridge mode, or flip it to Gateway mode and connect directly to the modem to check the UI. It doesn't make sense that you would end up with UI corruption on two consecutive modems.
Have you tried out running fq_codel on the router yet? If so, whats your opinion on the packet scheduling that fq_codel does?
In a nutshell, all modems and routers manage the packet flow into and out of the modem or router in accordance with long standing rules. There has been a lot of work done in the very recent few years to come up with a better packet scheduling scheme to prevent "bufferbloat" and provide for a fairer management scheme for packet flow. The latest version of that development is titled fq_codel, which stands for "fair queuing controlled delay". That is now built into pfsense but apparently its a command line function. In theory, it should provide better packet and que management than any similar function now in operation. If you look at Dave's post regarding the drop in latency from 2.0.10.26 to 2.0.10.27, this looks very much like an fq_codel result. However, despite what ever improvements have been made in the modem packet management, my thoughts on this are that any follow on router short circuits the modem improvements as that router on its own, will impose its own packet management scheme on top of what ever the modem is doing. So, I suspect that with a router in operation, the end result will be worse performance compared to what one might see with the modem operating on its own. I won't get into the issue of other functionality that routers offer above and beyond any modems. This is to keep the discussion centered on packet and que management. So, its interesting food for thought for anyone who has the capability to run fq_codel to give it a go and see what the results are. There are several posts of ping tests before and after fq_codel has been loaded on a router that show a marked improvement in latency from before to after. So, if you're someone who doesn't mind experimenting, this might be worth looking at.
Here's Dave's post on the .26 to .27 comparison in latency:
These results look very similar to test results with fq_codel loaded and running.
Here's a link to a thread on the pfsense forum. There may be others:
https://forum.pfsense.org/index.php?topic=87931.0
The drop in latency as seen on this page is pretty dramatic.
There is definitely some homework to do here to fully understand how to implement it, but, it looks pretty promising.
Seach results for fq_codel:
I'm running pfsense 2.3.4 so I can't do fq_codel without a recompile, but it looks like it works in the upcoming 2.4 release of pfsense.
*EDIT* did some messing around with HFSC & Codel according to this thread:
https://forum.pfsense.org/index.php?topic=126398.0
It made a huge difference with latency and buffer bloat, I'm getting A+ on DSL Reports Test:
This is over WiFi in my home office which is far from the router, hence my slower speeds, but the improvement can be felt just loading websites, they're loading instantly now. It's almost like the difference going to .27 firmware on the CODA.
Hello Community,
I just updated the release notes (post #2) of this thread with information regarding firmware 2.0.10.29 and 2.0.10.30 on the CODA-4582 and also 4.5.8.31 on the AC series.
I will be receiving the new CODA firmware 2.0.10.30 tomorrow and will deploy to those who signed-up for the early preview of 2.0.10.29. I will deploy to the participants next week.
On the AC series (CGN3ACSMR, CGN3AMR, CGN3AMF, CGN3ACR and CGNM-3552), I am looking for volunteers for to receive the latest code (4.5.8.31). Once I have a few people (10 would be ideal) running the firmware for a few days, I’ll start the global deployment to all trial participants. This code introduces major latency improvements (Puma 6 issues) and also introduces a button to control the operating mode (IPv4/IPv6/Dual-Stack) similar to what was introduced on the CODA-4582. This button will not work at the moment on the CGN3ACSMR due to a conflicting network configuration. It will be addressed in the future before we release this firmware publicly.
Happy testing!
Dave
@RogersDave does .31 for the AC series modems address all Puma 6 latency, as in ICMP, TCP/IP, and UDP for both IPV4 and IPV6?
Did Intel also build in the same packet scheduling into .31 that is now included in the 4582 firmware?
Can you add the USB2 / USB 3 issue to the list of issues to be addressed for the 4582.
Is DLNA enabled in the 4582? Should it have its own user controlled enable / disable switch?
@Datalink wrote:@RogersDave does .31 for the AC series modems address all Puma 6 latency, as in ICMP, TCP/IP, and UDP for both IPV4 and IPV6?
That is the plan but I haven't tested it (the firmware was received overnight from Hitron). Will welcome feedback on this.
Can you add the USB2 / USB 3 issue to the list of issues to be addressed for the 4582.
Yes I will, still need to update/clean-up the issue list on the CODA-4582.
Is DLNA enabled in the 4582? Should it have its own user controlled enable / disable switch?
I honestly don't know. I can tell you that even in the operator interface, there is no button to enable/disable this function. It would have to be tested with a USB2 device to confirm.
Dave
@RogersDave, one last question that I added above:
Did Intel also build in the same packet scheduling into .31 for the AC series modems that is now included in the 4582 firmware? That would be a good combo for users still running any of the AC series modems, fix the latency and improve on the packet scheduling at the same time.
@Datalink wrote:@RogersDave, one last question that I added above:
Did Intel also build in the same packet scheduling into .31 for the AC series modems that is now included in the 4582 firmware?
No they didn't. I asked for it but the ARM chipset in the Puma 6 can't support it.
@mrq, I've updated your modem to 4.5.8.31.
@st_brown, in order to receive this firmware, you must first register to the firmware trial program. You can do so by sending a private message to @CommunityHelps including your modem MAC address and serial number (can both be found on a label on your modem).
Once you are registered, I will be happy to push the latest firmware to your modem.
Dave
@RogersDave, does the following situation exist for trial .31 for the AC series modems where you can run a reboot/restart and the modem will retain the trial firmware, but, if you run a Factory Reset, the modem will revert back to the latest production firmware which is 4.5.8.27? If so, the trial participants should take note of this.
This would be the same situation as the 4582 has when its running a trial firmware version.
"AC" series modem do not have update on boot enabled so factory reset is not an issue on these.
Dave
-
941965 views
-
669 Likes
-
-
