I’ve just downloaded the new 6.2.0 beta 3 firmware, and got some notes about it:
1 - I would love to see the UI interface for the “SF Analyzer” set like the “SF Test”. The way it is now, it’s only possible visualize the bandwidth the activity for each modem by opening a new tab, or a graph. It would be much easier if it was something like this:
2 - I don’t get and couldn’t find this new feature, could you explain it better?
"Web UI:
Instead of automatically choosing a carrier, LTE-enabled devices now offer the option for users to choose which carrier to connect to."
3 - I’ve noticed a little delay on SF tunnel to detect when a particular modem is down. It first becomes red and after a few seconds it goes out of the list. The thing is, during the time it’s red, waiting to be removed, the overall sum of the bonding gets really affected and slow, only accelerating after the particular modem goes out of the list.
Could this process be faster? the way it is really affects a video streaming application for example.
4 - I’ve tested the “Cut-off latency” and I love it! this could be a game changer for me. But sometimes the modems are changing latency so fast (from high to low) that the system gets crazy, it adds and removes the particular modem from the SF bonding like crazy, affecting the overall bonding result. I wonder how could we improve that, any ideas?
I’ve made the following video to show my point:
When we are redesigning the PepVPN Test UI with WAN Statistics shown on the panel, we have discussed internally whether we should do the same for PepVPN Analyzer. From technical point of view, PepVPN Analyzer is testing the performance of each “tunnel”, as shown in your screenshot, there are two tunnels, “Local WAN3 > Remote WAN1” and “Local WAN4 > Remote WAN1”, PepVPN Analyzer is designed to give us an overview of the average performance of each tunnel, and results of bonding different combination of them. We see there is not much valuable info from the WAN Statistics table on PepVPN Analyzer panel and therefore we skipped this, but of course we are still working hard on providing more tools to make troubleshooting VPN performance easier.
Sorry for the confusion about this new feature, this is only available for devices with embedded Cellular WAN (applicable LTE models only) and not for USB WAN. If this feature is available for your device, you will find the “Carrier Selection” settings in the Cellular WAN details panel (changes may apply in final GA firmware since this is still in beta).
This is not an expected behavior, to have a better understanding of this issue, could you please help to record a video to demonstrate this? Also may I know what is the model of your device? Is it a MAX 700 or MAX OTG?
When “Cut-off latency” is active, you will not notice any changes on the PepVPN Status page, no WAN will show a red LED to indicate this state. If a WAN gives red LED on PepVPN status and later on removed from the PepVPN WAN Statistics table, there may be a real disconnection of the USB WAN (e.g. Health Check failed), which is not triggered by “Cut-off latency”.
1 - I understand your point, but in my opinion no harm would be done by adding such a feature. In fact it would make the reading process a little easier because people could follow it in real time. But that is my humble opinion, maybe I’m only thinking in my personal workflow. I understand that you develop the system thinking in all clients in general, so I respect that.
2 - I see, my units are USB only, that is why I can’t see the option. Though I’ve been wondering if a network type selection could be added to all routers, I would love to have a option to select “WCDM Only” or “LTE Only” for a specific USB port. Is that even possible with a unit that doesn’t have embedded modems?
3 - I’ve tried on both, MAX700 and MAX_OTG It’s not always, but basically it takes a while for the red USB comes out of the tunnel and during this time you see that the overall connection is affected, from what I remember this was much faster on 6.1.2. But I’ll check it again and will make a video out of it.
4 - I understand your confusion, but please ignore the last USB (Claro) shown on the video (that one was really unstable at the moment). Focusing only on the 3 first USBs, you see that the first modem goes really fast from 200 ms to 80ms, going beyond the cutting point and back on a very fast interval. But because that particular modem had a much worst speed performance, every time it went back (from the cutting point) It made the overall bonding slower. Not sure if that is clear enough, I could make another video if you like. I’m also not sure if there is anyways to make this process more effective too.
