Firmware 7.1 is now in GA!

firmware

#1

Firmware 7.1 is now available as GA! Here are some of the features to look forward to:

  • New Algorithm - Fastest Response Time: Traffic gets forwarded to the WAN connection with the fastest response time.
  • Docker Support For MediaFast: MediaFast enabled routers can now host Docker containers.
  • Smoother Video Streaming: SpeedFusion now supports better receive buffering, reducing jitter and out-of-order packets, for better video streaming experience.
  • Upgraded AP Support: A number of devices have been upgraded to 30 APs.

Here are the release notes, get your copy and give it a go!

Download Firmware 7.1


#2

#3

We are very excited about this release!

Video buffering is great but docker support is awesome!!

We ll keep you posted on the results.


#4

Curious how the “fastest response” works in my scenario where I have a satellite connection and a microwave connection - the satellite will always ping slower, but it has 10x the bandwidth of the microwave. Does the new firmware have a way to deal with this scenario?


#5

Installed 7.1. THANK YOU FOR THE WIFI PROFILES!!! Very helpful.

One issue I discovered. I’m in the US so my operating country is United States. However, I’m missing several of the 5Ghz US frequencies when United States is selected. See below…

As a temporary workaround I selected another operating country that has the same frequencies available in the US and they returned.

I will let you know if I find anything else.


#6

Can you please define Fastest Response precisely and distinguish it from Lowest Latency (as defined in 7.0.2 UI):

Lowest Latency - Traffic will be routed through the healthy WAN connection that is selected in the field Connection and has the lowest latency. Periodic latency checking packets are sent to the selected connections to determine their latency values. Thus additional network usage will be incurred.


#7

The detailed explanation for Fastest Response Time can be found in the help text of the Outbound Policy Custom Rule configuration panel, and here you are:

Fastest Response Time - Traffic will be duplicated and sent to all selected healthy Connection. Once a connection receives the first earliest response, any further traffic of the session will then be routed to that particular connection for the fastest possible response time. If there are any slower responses received on other connection afterwards, they will be discarded.


#8

Thank you. I don’t have the beta so didn’t see that.

Can you help distinguish that from Lowest Latency? Lowest Latency I would guess doesn’t duplicate packets and uses simple transactions to estimate a narrower measure of network round trip time, vs. Fastest Response Time which would possibly be protocol- and payload-dependent?


#9

Below is the description for Lowest Latency.

Lowest Latency - Traffic will be routed through the healthy WAN connection that is selected in the field Connection and has the lowest latency. Periodic latency checking packets are sent to the selected connections to determine their latency values. Thus additional network usage will be incurred.


#10

Right, but how do you define “Latency” and how do you define “Response Time”? How do these two algorithms differ, in theory and practice? Without understanding precisely what these are really measuring, it’s hard to decide which, if either, is the proper algorithm to use in a given situation.


#12

Hi @glink30, we have revised the help text, hope this is giving a clear explanation about the difference of these two algorithms, what do you think?

Lowest Latency - Latency checking packets will be periodically sent to all selected healthy connections. Latency will then be determined by the response time of the second and third hops. New traffic will then be routed to a healthy connection with the lowest average latency during that detection period.

Fastest Response Time - Traffic will be duplicated and sent to all selected healthy connections. The connection with the earliest response will be used to send all further traffic from the session for the fastest possible response time. If there are any slower responses received from other connection afterwards, they will be discarded. As a result, this algorithm selects the most responsive connection on a per session basis.


#13

Thank you. The per-session vs. rolling average distinction does help. I’m still assuming the Lowest Latency packets are lightweight packets to fast servers (e.g., DNS), and the Fastest Response Time packets, being live packets, are more dependent on protocol, payload, and destination processing time.


#14

I understand the literal explanation, but I don’t understand the real world benefits of choosing between the options. Could you elaborate on that, and give us examples of a situation where each type would be the best choice?


#15

One typical use case I’d say, is TCP traffic should go for Fastest Response Time instead of Lowest Latency. The first packet of any TCP session is a TCP SYN packet and we know a 3-way handshake is taking place and this means there will be a “response” from remote server. Fastest Response Time works well in this case.

However, for some traffic without “response”, may be UDP streaming, should go for Lowest Latency instead.


#16

Not Display Icon Port ? but can click Show Status Port.


#17

Please clear your browser’s cache then try again. Below is my testing on HD4.


#18

Please let us know what browser and its version you use on the OS? We have tested successfully with Chrome / Firefox / Safari / IE.

Thanks,
Eddy


#19

Now, i refresh (ctrl+F5) in Chorme is show icon. but IE / Mozilla firefox can show it. Thx


#20

Hello @Alan,
The new features of the firmware are looking good and we are excited about rolling many of these new features out to our clients ASAP.

One thing I have noticed is that the beta release requires a manual updated/download to be done for the “Content Filtering Database”, will the final release include the update or the ability to be automatically updated (with management controls from InControl2)?

With the release schedule we would like to recommend holding back until after the second week of the new year in January 2018, this is purely to ease support requirements during the upcoming weeks were many companies are on reduce support staff.

Happy to Help,
Marcus :slight_smile:


#21

Hello @Alan
Another thing we have noticed over the weekend is on the MAX Transits, the new feature of the LAN status can not been seen, we operate some of the MAX Transits occasionally with the WAN port as a LAN port giving two LAN ports, so having the new feature would be good.

In addition to this we would like to recommend the WAN ports MTU be changed from “Custom Value” to “Auto”, we have been working with @sitloongs and other team members to work out why certain MAX Transits would not remotely upgrade their firmware, @sitloongs found it was cased by the factory default MTU size of the WAN port, when he set this to AUTO, both the remote web admin and the updates began to work again (Support Ticket #778999).

Happy to Help,
Marcus :slight_smile: