We’ve deployed nearly 40 point-to-point pairs and things have been flawless. Reliability and performance is better than all other multipoint WiGig-based products we’ve tried, and at a fraction of the price.
We’ve also deployed a multipoint AP with 4 stations. Reliability is still solid, but latency and jitter do go up when more than one station connected. There also appears to be a hit in capacity for every station added. Running traffic generator tests between a point-to-point pair nets us over 960 Mbps full-duplex, but running a test against a single station of the 4, full-duplex speeds are just under 500 Mbps, dipping when the other stations are active. I’ve been assured there is a lot to be done in tuning the performance as these things are very complicated, and I look forward to seeing things improve with future firmware upgrades.
Very useful post.
Can you clarify what you mean with; “I’ve been assured there is a lot to be done in tuning the performance as these things are very complicated”?
This is what MT crew told? Because in fact in the ROs there is not so much to be tuned (yet?) on these units. You can pick one of the 3 channels and set the SSID and master or station. That’s it…
Due the high free space loss and directional characteristics ‘same tower’ interference is much lower then for instance with 5Ghz. Metrolinq states that an ample couple of meters separation and more then 45º angle between units makes them ‘invincible’ for each other. But what happens with units in close proximity where channels can be the same (only 3 available where ML has 4 channels) in relation to the ‘beam forming’?
Already any experiences? Would different SSID be enough to prevent 60Ghz station to jump to another AP if this happens to be reachable due the beamforming and at the same channel?
One AP with one client on 94 and the other at 108 meters. Each one along could have some 800Mbps download. If running both up and down we see some 1,4 - 1,5 Gb aggregated.
When tests are run from both clients at the same time each falls back to some 60% of this and at the AP the traffic increases some 45-50% to make up for both.
We are planning to add some extra clients on this AP so we have to see. As long as each client can sustain 100Mbp down plus 50Mb up I am happy. Let’s see how many client we can hook up.
Yes I am aware of this. But some wrote somewhere that after 4 things were spiraling down…
And is this limit just hardware limit? (i.e. ROS just won’t accept 9th unit because MT software design told so to prevent complaints?) or is this just capacity limit in the protocol?
What would the back to back noise be of these units? Would they be able to work back to back on a pole in the same frequency? We only have 3 to use and if we have a tower with 4 sectors plus maybe one or two P2P’s leaving we already have to start to make a puzzle. Some more antenna and radiation characteristics would be nice.
Some wrote two P2P’s in parallel setup would be possible in same frequency but that sounds weird to me. As long as the units are not syncd that would be asking for problems imho. Or they have to be several meters apart from each other…
The units have phased array antennas doing beam forming, and the antenna patterns seem to be very narrow. That would be a nice experiment to do. Probably the result would be surprising.
So, are there any plans to support more than 8 customers ? If yes, any idea of the max number of simultaneous clients that WAP60G may support in future?
PtMP is delivering some pretty good speeds. Customers are thrilled, etc.
Few questions/requests;
Would like to have radius AUTH - so it’s not just a password to get access.
It’s not just for added security, but so we know what CPE/customer is connected and online when troubleshooting.
What has not been answered already - will there be support for more than 8 CPEs? (this is pretty important, considering there’s only ~4 channels).
We have deployed these in dense populated areas, so have been able to fill a couple w60G’s already - the clients sometimes get stuck wanting to connect to the same AP (that is already full) as well, instead of then trying another AP it can connect to.
Yesterday we in Latvia had a great opportunity to observe the 60Ghz MultiPoint experience.
So far, neither snow, rain or wind, each in itself, has had much effect on link stability (perhaps a slight decrease in PHY rate).
But yesterday the wind gusts 19 up to 22 meters per second and precipitation of 11 millimeters and this is the reason why wAP ↔ nRaY at 350 meters could not maintain a regular link. It should be noted that another nRAY worked stably at a distance of 270 meters.
The problems on the nRAY side were not with the RX sector, it was stable as a stone, but with the TX sector (in the end I set to fixed).
It’s not just about manufacturers’ presentations when the weather affects the PHY rate (I might not worry about a lower PHY rate either), but about the fact that the link is fall.
I tried to change the frequencies from 60480 to 66000, but for stability it didn’t help, the only thing I noticed was that at 60480 pings walked from 0-600ms, but 62640/64800/66000 pings were stable at 0-1ms, even when Signal 20, MCS 1, PHY 350. At this time, the wAP60Gx3 side was also experimented with mdmg-fix yes or no, but it did not give any results either.
Conclusion: wAP ↔ nRAY is stable (average gusts with rain) can work 270 meters, but 350 no.
It is also worth considering the idea of installing wAP at a minimum height where the wind will have less effect with the rain.