Airfiber gps sync is awesome. I am able to use the exact same channel with the antennas 1 ft apart and still pull full bandwidth.

They way UBNT gps sync works is they use gps to sync the 2 airfibers and offset the wave length a little bit so they cant see each other.

Mikrotik are you able to do GPS sync yet?

Here is their M5 version for 5ghz syncing. All aps send at same time and receive at same time so no interference on same channel.

http://www.youtube.com/watch?v=_CqbO8sjwOg

Here is their M5 version for 5ghz syncing. All aps send at same time and receive at same time so no interference on same channel.

http://www.youtube.com/watch?v=_CqbO8sjwOg

Information about gps sync

http://groups.csail.mit.edu/tds/papers/Fan/opodis04.pdf

Hi Dallas,

+1 for synchronisation of Miroktik APs.
We need that very urgent to have lower self interference and in case you have licensed bands with limited channels, it is a must. (let say 3,5GHZ or 3650mhz)
it shoud not be that hard to implement.

Airfiber gps sync is awesome. I am able to use the exact same channel with the antennas 1 ft apart and still pull full bandwidth.

They way UBNT gps sync works is they use gps to sync the 2 airfibers and offset the wave length a little bit so they cant see each other.

Mikrotik are you able to do GPS sync yet?

In 24 GHz using Parabolic you can omit sync if you have at least 30 Degree between. In 38 we alway get the same frequency from our regulator on the same tower. So this is not a real sign for working GPS. It is the narrow beamwidth which make it work.

Sync for multipoint is most important. Yeah I have used parabolics but that's for back hauls. I am fine there. We have about 200mbps top going over our back hauls so parabolics are a must. Back to GPS sync, we need it.

Microtik could use have a master ap that sends out sync beacons and the apps that can see that ap would sync with that signal. That way all those aps would be on same channel. We could group 10 towns with one channel. Then have another master sync for another group of 10 towns. Microtik may be able to do this with there existing wireless chip sets. Also all aps would transmit at same time and receive at same time. Clients would sync to ap of course that's it. Nv3 is what they should call it.

Sync for multipoint is most important. Yeah I have used parabolics but that's for back hauls. I am fine there. We have about 200mbps top going over our back hauls so parabolics are a must. Back to GPS sync, we need it.

Microtik could use have a master ap that sends out sync beacons and the apps that can see that ap would sync with that signal. That way all those aps would be on same channel. We could group 10 towns with one channel. Then have another master sync for another group of 10 towns. Microtik may be able to do this with there existing wireless chip sets. Also all aps would transmit at same time and receive at same time. Clients would sync to ap of course that's it. Nv3 is what they should call it.

Sync for multipoint is most important. Yeah I have used parabolics but that's for back hauls. I am fine there. We have about 200mbps top going over our back hauls so parabolics are a must. Back to GPS sync, we need it.

Microtik could use have a master ap that sends out sync beacons and the apps that can see that ap would sync with that signal. That way all those aps would be on same channel. We could group 10 towns with one channel. Then have another master sync for another group of 10 towns. Microtik may be able to do this with there existing wireless chip sets. Also all aps would transmit at same time and receive at same time. Clients would sync to ap of course that's it. Nv3 is what they should call it.

Sync for multipoint is most important. Yeah I have used parabolics but that's for back hauls. I am fine there. We have about 200mbps top going over our back hauls so parabolics are a must. Back to GPS sync, we need it.

Microtik could use have a master ap that sends out sync beacons and the apps that can see that ap would sync with that signal. That way all those aps would be on same channel. We could group 10 towns with one channel. Then have another master sync for another group of 10 towns. Microtik may be able to do this with there existing wireless chip sets. Also all aps would transmit at same time and receive at same time. Clients would sync to ap of course that's it. Nv3 is what they should call it.

You're dreaming. Even systems with gps we are using are not specified for channel reuse. Gps sync does not take away the work to place antennas in a way to have clean spectrum. Sync reduce problems but do not solve them.
Of course I want MT to offer sync but I dont expect too much.

Your not too otomistic. Ubiquiti has already done it for multipoint. I know mikrotik can do it. Just waiting for them to do it.

Your not too otomistic. Ubiquiti has already done it for multipoint. I know mikrotik can do it. Just waiting for them to do it.

You tested UBNT and compared with and without sync?

At least the 3,65GHz Version is told to not work.

only 5ghz and airfiber airsync works

only 5ghz and airfiber airsync works

What is the gain using the 5GHz Sync? Are you able to reuse the same frequency on the same tower?

My network is MT 100% based and I want continue to use MT in the future, GPS SYNK is a must if we want to do this job with MT hardware

Giuseppe

You're dreaming. Even systems with gps we are using are not specified for channel reuse. Gps sync does not take away the work to place antennas in a way to have clean spectrum. Sync reduce problems but do not solve them.
Of course I want MT to offer sync but I dont expect too much.

+1

If using same band for sectors + Ptp's then to get the best from GPS sync everything thing on a mast should be in sync (PTP's + PTMP sectors) and that would reduce overall throughput.

only 5ghz and airfiber airsync works

What is the gain using the 5GHz Sync? Are you able to reuse the same frequency on the same tower?

Yes, also same with airfiber. Works very well. No loss of bandwidth either. Amazing!

+1 for GPS sync

-1 for GPS sync

no sharing same channel is rules.

GPS Sync would reduce overall throughput?
If I understand correctly for example;
Sector A has 10 clients,
Sector B has 60 clients,
Sector C has 20 clients,
Sector D has 30 clients,
Sector A has after having received responses from its 10 Clients has then to wait, so has Sector C & D to wait until Sector B has received responses from its 60 clients, before all the Sectors can respond in sync?
All the AP’s will have the performance of the sector with the highest number of registered clients?
Throughput takes a nosedive when syncing AP’s + Ptp’s links
By the way I don’t need Sync as I use AP’s + PtP with good RF screening and carefully select frequencies.

GPS Sync would reduce overall throughput?
If I understand correctly for example;
Sector A has 10 clients,
Sector B has 60 clients,
Sector C has 20 clients,
Sector D has 30 clients,
Sector A has after having received responses from its 10 Clients has then to wait, so has Sector C & D to wait until Sector B has received responses from its 60 clients, before all the Sectors can respond in sync?
All the AP’s will have the performance of the sector with the highest number of registered clients?
Throughput takes a nosedive when syncing AP’s + Ptp’s links
By the way I don’t need Sync as I use AP’s + PtP with good RF screening and carefully select frequencies.

No. The normal way sync works is that all APs send and receive at the same time.
Each AP using a different Frequency can send in parallel. Problem is that the TX/RX Ratio has to be fixed
for all radios at all sites to use the effect of GPS-Sync.
So you can decide to do e.g. a 50:50 rate in your network. So if your modulation allows 100MBit TDD you
never get more than 50 down or 50 up on all radios at all sites. No radio will give you 70MBit down as it
would need to exceed the TX Time frame to do this.

If you use a synced radio to connect 2 towers you get a problem. Which side is the AP? One side sends with the
CPEs ...

No. The normal way sync works is that all APs send and receive at the same time.
Each AP using a different Frequency can send in parallel. Problem is that the TX/RX Ratio has to be fixed
for all radios at all sites to use the effect of GPS-Sync.
So you can decide to do e.g. a 50:50 rate in your network. So if your modulation allows 100MBit TDD you
never get more than 50 down or 50 up on all radios at all sites. No radio will give you 70MBit down as it
would need to exceed the TX Time frame to do this.

If you use a synced radio to connect 2 towers you get a problem. Which side is the AP? One side sends with the
CPEs ...

OK thanks for that but does that not confirm my example for all APs to send & receive, the AP with 10 clients must wait till the AP with 60 clients has finished listening to the 60 clients and then all the APs can send then?

Mikrotik either needs GPS sync or needs Full duplex wireless N for point to multipoint. If we had dual nstreme for point to multipoint there is no need for GPS. Right?

No. The normal way sync works is that all APs send and receive at the same time.
Each AP using a different Frequency can send in parallel. Problem is that the TX/RX Ratio has to be fixed
for all radios at all sites to use the effect of GPS-Sync.
So you can decide to do e.g. a 50:50 rate in your network. So if your modulation allows 100MBit TDD you
never get more than 50 down or 50 up on all radios at all sites. No radio will give you 70MBit down as it
would need to exceed the TX Time frame to do this.

If you use a synced radio to connect 2 towers you get a problem. Which side is the AP? One side sends with the
CPEs ...

OK thanks for that but does that not confirm my example for all APs to send & receive, the AP with 10 clients must wait till the AP with 60 clients has finished listening to the 60 clients and then all the APs can send then?

No AP waits for another. Every AP waits for the AP TX-Timeslot. If one AP has 60 clients he has to use this fixed timeslot to send to all of them. When timeslot ends he has to wait for the next TX Timeslot.
So in a typical residential environment you will not choose 50:50. You will do something like 80:20.

I agree. Its not link WDS where you split the bandwidth on every hop.

Mikrotik either needs GPS sync or needs Full duplex wireless N for point to multipoint. If we had dual nstreme for point to multipoint there is no need for GPS. Right?

"Full duplex N for P2P"? So 2 dual chain antennas on each client and in tower? Looks a bit expensive, ackward and not so esthetic....
The perfomance gain for such a setup in TDMA environment is little while the per client cost is doubled.

Regarding sync I agree with n21roadie; In TDMA environment each AP is assigning tx/rx time slots to each station and aren't necessarily of the same length between AP's, thus the tx/rx is different too. To get sync you have to follow the one with the longest slots. Increasing the latency on the others....
Usually P2P link with biggest distance and probably big frames has biggest time slot. Put it in sync with an P2MP AP and the latter will see a big fall in capacity.


I think sync is overrated. Theoratically is looks fine but there are too many negatives to deal with.
Imho ubnt uses it more as a sales tool than that it actually improves their 'many AP's on a tower' setups. Their parabolic antena's are good shielded against unwanted signals and together with their high radio outputs (and almost no cable losses) they can achieve high s/n ratios and thus the 'many AP's on a tower' setups works fine... but not so much due to the sync. Obvious no-one in their 'camp' will acknowledge this for obvious reasons....

Imho sync is good for lease frequencies where operator has little freq's (or even only one) available for small amount of antennas. Network and protocols (G3, G4) also differ so to them it gives better usage of that single freq.

In 802.11a/n we have plenty options to differ the freq's. The usage of the tdma tx/rx 'slots' is more variable so sync is not helping a lot. It probably makes things worse....

And what about several ops using same tower? Do we now have to negotiate with other op to use one and the same sync? Interesting....

The mentioned issue of backhauls between towers using sync is another problem that can arise. Station on tower 2 will follow sync of tower 1 and thus will never be in sync with tower 2. So it has to have a good frequency separation with other stuff of tower 2. Or tower 2 has to be in sync with tower 1. Which will give issues with distant stations 'hearing' both.
This also shows that a city wide network sync all using same freq. is impossible because the time shift over distance between towers.. That's why tdma can't be used in WDS/mesh setups, like sync won't work in WDS or mesh.

The best way of getting high performances is good balanced and adjusted antenna systems. "S/N ratio" is the magic word. The bigger the better...

Wont witheld me though to buy a sync system of MT if it ever comes. Maybe my sceptisism will be proven wrong...

............................................

No AP waits for another. Every AP waits for the AP TX-Timeslot. If one AP has 60 clients he has to use this fixed timeslot to send to all of them. When timeslot ends he has to wait for the next TX Timeslot.
So in a typical residential environment you will not choose 50:50. You will do something like 80:20.

Thanks WirelessRudy I was confused by the reply?

...........In TDMA environment each AP is assigning tx/rx time slots to each station and aren't necessarily of the same length between AP's, thus the tx/rx is different too.

Does this mean and picking numbers at random
AP with 60 clients uses timeslot for each client =1
AP with 10 clients uses timeslot for each client =6

Taken from manual:

Media access in Nv2 network is controlled by Nv2 Access Point. Nv2 AP divides time in fixed size "periods" which are dynamically divided in downlink (data sent from AP to clients) and uplink (data sent from clients to AP) portions, based on queue state on AP and clients. Uplink time is further divided between connected clients based on their requirements for bandwidth. At the begginning of each period AP broadcasts schedule that tells clients when they should transmit and the amount of time they can use.

In order to allow new clients to connect, Nv2 AP periodically assigns uplink time for "unspecified" client - this time interval is then used by fresh client to initiate registration to AP. Then AP estimates propagation delay between AP and client and starts periodically scheduling uplink time for this client in order to complete registration and receive data from client.

Nv2 implements dynamic rate selection on per-client basis and ARQ for data transmissions. This enables reliable communications across Nv2 links.

Meaning the time slots are continously variable in length.

Time slot assigned to a client at long distance has to be longer than close client. It will increase latency but distant client need opportunity to send answer and AP has to wait for it.... So, even with same amount of clients AP1 can have time slots that are longer than AP2. Imaging AP1 has client at 20km, when sync'd AP2 will than have to act like it also has client at 20km, even if AP2 only has clients up to 100m !

Time slot for high bandwidth requiring client is also assigned more often than for low use/idle client of same AP.
So here again, if AP2 is now to sync with AP1 which has one high bandwidth requiring client, AP2 has to sync its clients to the same 'long' slots of this AP1 client. Which could unneccesarily create extra latency in AP2 network.
(The Tx/Rx sequence itself can be sync'd. If the length of the slots are set the same (and be 'fixed' to that length) than AP1 with 2 clients can sync with AP2 with 3 clients, example;
|AP1aTx|AP1aRx|AP1bTx|AP1bRX|AP1bTx|AP1bRx|AP1bTx|AP1bTx|AP1bRx|AP1?Rx|AP1aTx|AP1aRx etc. etc.
|AP2aTx|AP2aRx|AP2bTx|AP2bRx|AP2cTx|AP2cRx|AP2?Rx |AP2aTx|AP2aRx|AP2bTx|AP2bRx|AP2cTx etc. etc.
"AP1?Rx" or "AP2?Rx" are slots where AP listens to possible new station.)


The more I read about the working of NV2 (TDMA) the more I actually wonder how ubnt (and others) are dealing with this? Maybe they work with a fixed length time slot assignment for all connected AP's and averaging between AP with little usage/short range clients and big usage/long range client. So big usage/long range clients will see lower throughput (because more 'slots' needed than actually is ideal, thus more overhead) while low usage/short range clients get higher latency than actually could be achieved without sync.

Maybe because the 'n' protocol with its high connection rates masquerades the poorer performance of their sync'd system. User won't notice and they have the sales tool!

Taken from manual:

Media access in Nv2 network is controlled by Nv2 Access Point. Nv2 AP divides time in fixed size "periods" which are dynamically divided in downlink (data sent from AP to clients) and uplink (data sent from clients to AP) portions, based on queue state on AP and clients. Uplink time is further divided between connected clients based on their requirements for bandwidth. At the begginning of each period AP broadcasts schedule that tells clients when they should transmit and the amount of time they can use.

In order to allow new clients to connect, Nv2 AP periodically assigns uplink time for "unspecified" client - this time interval is then used by fresh client to initiate registration to AP. Then AP estimates propagation delay between AP and client and starts periodically scheduling uplink time for this client in order to complete registration and receive data from client.

Nv2 implements dynamic rate selection on per-client basis and ARQ for data transmissions. This enables reliable communications across Nv2 links.

Meaning the time slots are continously variable in length.

Time slot assigned to a client at long distance has to be longer than close client. It will increase latency but distant client need opportunity to send answer and AP has to wait for it.... So, even with same amount of clients AP1 can have time slots that are longer than AP2. Imaging AP1 has client at 20km, when sync'd AP2 will than have to act like it also has client at 20km, even if AP2 only has clients up to 100m !

Time slot for high bandwidth requiring client is also assigned more often than for low use/idle client of same AP.
So here again, if AP2 is now to sync with AP1 which has one high bandwidth requiring client, AP2 has to sync its clients to the same 'long' slots of this AP1 client. Which could unneccesarily create extra latency in AP2 network.
(The Tx/Rx sequence itself can be sync'd. If the length of the slots are set the same (and be 'fixed' to that length) than AP1 with 2 clients can sync with AP2 with 3 clients, example;
|AP1aTx|AP1aRx|AP1bTx|AP1bRX|AP1bTx|AP1bRx|AP1bTx|AP1bTx|AP1bRx|AP1?Rx|AP1aTx|AP1aRx etc. etc.
|AP2aTx|AP2aRx|AP2bTx|AP2bRx|AP2cTx|AP2cRx|AP2?Rx |AP2aTx|AP2aRx|AP2bTx|AP2bRx|AP2cTx etc. etc.
"AP1?Rx" or "AP2?Rx" are slots where AP listens to possible new station.)


The more I read about the working of NV2 (TDMA) the more I actually wonder how ubnt (and others) are dealing with this? Maybe they work with a fixed length time slot assignment for all connected AP's and averaging between AP with little usage/short range clients and big usage/long range client. So big usage/long range clients will see lower throughput (because more 'slots' needed than actually is ideal, thus more overhead) while low usage/short range clients get higher latency than actually could be achieved without sync.

Maybe because the 'n' protocol with its high connection rates masquerades the poorer performance of their sync'd system. User won't notice and they have the sales tool!

Just read the documentation for 802.16e (Physical Layer of WiMAX) and you will see how a TDMA/Synced system works.
You have a fixed time for all APs to send and a fixed time for all APs to receice. GPS ensures all APs have the same timing.

802.16e uses a 5ms Timeframe where the Network operator can decide how much of this 5ms is for *all* APs sending and for *all* APs receiving. When the operator configures APs UP/Downratios different he will get interference. In the AP TX time the APs sends a Table/Mask which describes which CPEs are allowed to send in the next AP receive timeframe.
This is a simpified description as 802.16e does a some more complicated stuff to improve scheduling.

UBNT is a salesforce of it's own. I dont believe anything told by them and their fanboys after I tested their equipment.

....................................


I think sync is overrated. Theoratically is looks fine but there are too many negatives to deal with.
Imho ubnt uses it more as a sales tool than that it actually improves their 'many AP's on a tower' setups.
............................................................

Well put and how often have we seen sales omitting vital information or data that should be included for consideration before purchase?

And how often is the reply from support “well we didn’t exactly say that…..”

So, conclusion?

Sync is nice but overrated. It can be used but don't expect maximum performance on multi AP tower.
802.11a/n has still 8 fully free 40Mhz channels available in most countries so it seems a bit strange to me to have 'a need' for sync because you're running out of channels? With the 'maturing' of NV2 in the last 2 years I have no more issues with interference in a spectrum environment where every available 5Ghz channel (either 5, 10, 20 or 40Mhz) is used, and sometimes used twice. I don't need sync. (Maybe because I am almost the only one using ROS in a further dominated airmax spectrum... )

The energy of MT engineers could better be put to develop 802.11a/c hardware and software to use it and further development of triple chain radio/software.
There are many other ways of improving the 802.11 protocol and squeezing the best out of the available spectrum.*1
MT can only maintain itself on the market if they stay on top of developments and bring products to get their networks to the top performers. Otherwise they will play a marginal role and slowly die...

*1 Ruckus's Channel Fly is a nice example. MT should develop a algorithem where AP 'tests' preset channels for usage and than uses the best channel for its communication. When they would develop a multi chain (3, or better 4) radio than the scanning can be done on a permanent basis by using one of the chains. Radio would swap to better channel without users actually even noticing it. (A 'learning' curve can also be build in the ROS to prevent unnecessary swaps).
This way interference will be avoided and by always using the 'best' channel the total available throughput will increase...

MT needs engineer with imagination and take a good look what is possible and available yet. Then improve their stuff to do it better.... the only way to move forward.....

Oh yeah, just noticed the subject title again "Mikrotik GPS Sync just like Airfiber"
Airfiber is a typicall example of the sales of ubnt. A first everyone things "Yes, that's what I need! Finally an avordable compact easy to install one package high troughput link!" .......
Well, in Europe and probably other countries the max. EIRPP is very limited so it can only be used at short ranges. Where 802.11a/n-a/c can do almost the same.
And you better be not living in a rainy climate. 24Ghz is very, very fulnerable to rain..... it completely destroys the link even at relative short distances.... Waste of money.

And yes, because you only have very limited bandwidth available, to re-use the freq. sync can do a bit of help here, especially if taken in consideration we also mainly speak about backhaul links. These can all run in sync without the scetched issues that might arise in P2MP AP's on a tower.

I agree 24ghz is crap in rain. Its not worth it. I have 12 airfibers.

Airfiber gps sync is awesome. I am able to use the exact same channel with the antennas 1 ft apart and still pull full bandwidth.

They way UBNT gps sync works is they use gps to sync the 2 airfibers and offset the wave length a little bit so they cant see each other.

Mikrotik are you able to do GPS sync yet?

I agree 24ghz is crap in rain. Its not worth it. I have 12 airfibers.

I am curious back in March you say "...gps is awesome.." and now "....Its not worth it.." so what is the final verdict 24GHZ is crap, and sync in not as good as the marketing says it is?

gps sync is good. 24ghz is not good.

Well, my lesson on this tread is that some are hit by the sales show of ubnt. (+1 for ubnt)
But than ask the same from MT. MT is not able/willing to do the same which is left arbitral if this is a plus or minus for them...

MT has its propietary tdma which is a big plus in an airmax dominated world, I would call that a "+1" for MT.

So, the score is unsettled. If MT users are not falling into the sales trap of ubnt but keep on pushing MT to deliver HQ software and hardware options, I would say MT can still be a winner.


In regard of this tread I would conclude that 24Ghz is only good at very short distances on non priority links. And when freq. re-usage is needed on a tower gps sync can be of (little) help here.

For 5Ghz sync is not bringing lots of improvements, could even be the contrary. And 'a' has plenty of spectrum available, so actually not any real need for sync.

If we are able to build triple chain, or a/c links in 5Ghz, there is no need for Airfibre too. Probably with triple chain or a/c when can do much better than Airfibre, for less money and in every wheater type. I challenge anyone to make some long backhaul based on triple chain or a/c (not available in MT, yet I suppose...)

I am building my self a 12km link and I am going to try to do better than a lease line can offer me at 10 times of the cost..... keep you updated....

Yeah I am waiting for 802.11ac to come out. But want to see some type of frequency sync used with 802.11ac.

M5 GPS is not working and nobody is using it. In fact RocketM5.

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

On the other hand, I completely agree that 802.11ac has to be the focus of Mikrotik. Mt has to be the first releasing it for PtMP fixed applications for us WISPs.

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

On the other hand, I completely agree that 802.11ac has to be the focus of Mikrotik. Mt has to be the first releasing it for PtMP fixed applications for us WISPs.

This depends on country and rain conditions. We're limited to 100mW EiRP in 24GHz so we found no link where AirFiber would be useful for us. 8km in 24GHz sounds like "It never rains in Southern California" ).

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

On the other hand, I completely agree that 802.11ac has to be the focus of Mikrotik. Mt has to be the first releasing it for PtMP fixed applications for us WISPs.

If Airfibre is a good product, then you would have no problems in posting here actual throughtput results and not the sales promo material, also I would like to see actual throughtput levels during heavy and prolonged rain showers?

Otherwise we could be singing that famous Albert Hammond song?

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

I've been tempted to buy these units because hell, their promo rocks... But as a good pro I started to investigate in the product and link caracteristics. I was suprised that although they sell them in Europe, with the low power we can use here it renders the stuff almost useless.
Than I found several guys even on the ubn forum that really warned for the 'rain issue' here so decided it was yet again ubnt stuff presented in a cloud of optimistic promises....

And 600Mb over 6-8km's? Can you show us some real data? Because even their own info doesn't really promise this... In one of the website's .pdfs they talk about 500Mb at 3,5miles..... Above that range speeds drops dramatically. And no rain!

Yeah it rains a lot where we live also. It works great if there is no rain.

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

On the other hand, I completely agree that 802.11ac has to be the focus of Mikrotik. Mt has to be the first releasing it for PtMP fixed applications for us WISPs.

This depends on country and rain conditions. We're limited to 100mW EiRP in 24GHz so we found no link where AirFiber would be useful for us. 8km in 24GHz sounds like "It never rains in Southern California" ).

Oh yeah, just noticed the subject title again "Mikrotik GPS Sync just like Airfiber"
Airfiber is a typicall example of the sales of ubnt. A first everyone things "Yes, that's what I need! Finally an avordable compact easy to install one package high troughput link!" .......
Well, in Europe and probably other countries the max. EIRPP is very limited so it can only be used at short ranges. Where 802.11a/n-a/c can do almost the same.
And you better be not living in a rainy climate. 24Ghz is very, very fulnerable to rain..... it completely destroys the link even at relative short distances.... Waste of money.

And yes, because you only have very limited bandwidth available, to re-use the freq. sync can do a bit of help here, especially if taken in consideration we also mainly speak about backhaul links. These can all run in sync without the scetched issues that might arise in P2MP AP's on a tower.

All I can say bla bla bla bla
U ubnt hater
AirFiber is no waste of money its revolutionary something that no one has done
who care for EU limitation and EU market, u hate it because u cant use more than 20Db
with up to 33dbl of power up to 5miles Airfiber is running just fine

Airfiber is a great product for backhaul and we are currently using a few in the varying distances of 6km-8km without any problems. You cant ever find a product in the same price range giving you 600mbit throuput. It opens up a wide range of possibilities for us WISPs due to the cost effectiveness.

So please do not confuse the things and spread false information. If you have anything else on the same 24ghz band giving equivalent throuput and same price range, than I am ready to hear your comparison (I doubnt that such a thing exists). Until then, AF rocks and is a big plus for the WISP industry.

I've been tempted to buy these units because hell, their promo rocks... But as a good pro I started to investigate in the product and link caracteristics. I was suprised that although they sell them in Europe, with the low power we can use here it renders the stuff almost useless.
Than I found several guys even on the ubn forum that really warned for the 'rain issue' here so decided it was yet again ubnt stuff presented in a cloud of optimistic promises....

And 600Mb over 6-8km's? Can you show us some real data? Because even their own info doesn't really promise this... In one of the website's .pdfs they talk about 500Mb at 3,5miles..... Above that range speeds drops dramatically. And no rain!

If u dont like it dont buy it
U still dont get it its not AirFiber its limitation to 20Dbl in EU, u should consider this before buying
AirFiber is one of the best products its just the nature of the 24Ghz not suitable to EU low

I had some time I thought I'd like ubnt products. But the more you work with it, the more you find it is limited and not performing to it`s promises.

Just a simple example; All ubnt devices have http access built in or some 'nobody really knows how it works' telnet.
But if you have to work on a network wher you have ip conflicts or no ip networking in place.... try to access your units...
Hell I'm glad MT has winbox. Very easy and very fast GUI that works without the need of IP connectivity.

"If you don't like it, don't buy it." Why not? Product lines are ever changing and to learn what is possible, and what not, you need to buy the stuff. So now and than I buy something from ubnt that looks interesting enough to do. If of use I use it, but so far most of their stuff end up in my waste bin...

Another example; Study the Airmax sector antennas and for what sector they are sold for. Than study their very poor quality radio patterns, and compare them agains any other vendor of antennes.
Where everybody uses 3dB antenna fading to tell you what working sector it has, ubnt uses 6dB. If you than try to interpolate it to 3dB you really see they are actually performing much poorer. Even according their own graphs!
And than look at their vertical beam range. Really not an antenna you want in a high tower or on a mountain top. It will have a very limited working pattern on the ground...
I tried 3 times to setup a sector with these Airmax sectors. 3 times I learned a cheaper sector from almost any other vendor that give me true data, is performing much better... so, if you want some cheap airmax sectors... I have to start digging in my bin....

But don't tell it on.. all my competitors work with their stuff. Which makes me King in network performances in my region....

Imho it is the technicians that will go for MT (or Motorola, Aruba, Cisco or whatever) where the sales dept. will go for ubnt. So who is smartest in the end... only time will tell....

maybe it is stupid question... why do we need a gps sync? What about some kind of sync over ethernet on the same place? What about sync over time (NTP) Is it really so hard to make it work? Lets say that it will be necesary just to set up place A, or place B on RB and common ntp server....

maybe it is stupid question... why do we need a gps sync? What about some kind of sync over ethernet on the same place? What about sync over time (NTP) Is it really so hard to make it work? Lets say that it will be necesary just to set up place A, or place B on RB and common ntp server....

NTP ist not accurate. Atheros Ethernet has no sync capability as far as I now. This would need custom Ethernet chip.

maybe it is stupid question... why do we need a gps sync? What about some kind of sync over ethernet on the same place? What about sync over time (NTP) Is it really so hard to make it work? Lets say that it will be necesary just to set up place A, or place B on RB and common ntp server....

GPS works on measuring distances between your location on the earth's globe towards the several sattelites. By now measuring the time differences in the time it takes for a signal to reach each of the sattelites, it can calculate your location on the globe. (very simplistic explanation. Actually also the difference in speed of the signal is measured. They make use of the doppler effect.)

To do an accurate measurement it is very important that at every moment the exact location of the sattelites in the orbit is known (that is by the sattelite tracking stations controlled) and that the time clocks onboard of the sattelites are very precise. We are talking of time differences between the several sattelite clocks less than several millions of a second. So, these clocks are atom clocks, the most precise clocks a man can build.
The sattelites now also make their time available to the earth receivers. So, these GPS receivers have the most accurate time we as human realistically can achieve.
If you now want to sync several radios the first thing you need to do is to make sure each of the radio's have a clock running at exact the same speed. This can only be achieved by aligning them with the GPS time signal. Any other way of synchronising is not as accurate and not as widely available (and thus relative cheap).

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

If only doing a local tower sync it would be a smarter Installation doing it together with Ethernet cabling.
So you dont need GPS-Antenna. In most cases a local tower sync is enough for unlicensed bands as you cant
control signal from foreign devices on other towers.

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

If only doing a local tower sync it would be a smarter Installation doing it together with Ethernet cabling.
So you dont need GPS-Antenna. In most cases a local tower sync is enough for unlicensed bands as you cant
control signal from foreign devices on other towers.

"with Ethernet cabling"? How do you see that? To interconnect the antennas? But you still need some clock to steer the sync process. So either you have a separate device with clock that is able to steer each of the connected radios. Or you must have each radio connected to a clock.

So, yet again the option of a separate time measurement device is needed. >>> GPS.

Now I don't know how the gps in ubnt for instance are connected to the radios but I presume with coax to eliminate radio interferences on the signal. Better would be fibre but yeah, I presume it can be done with (shielded) utp cable as well...

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

If only doing a local tower sync it would be a smarter Installation doing it together with Ethernet cabling.
So you dont need GPS-Antenna. In most cases a local tower sync is enough for unlicensed bands as you cant
control signal from foreign devices on other towers.

"with Ethernet cabling"? How do you see that? To interconnect the antennas? But you still need some clock to steer the sync process. So either you have a separate device with clock that is able to steer each of the connected radios. Or you must have each radio connected to a clock.

So, yet again the option of a separate time measurement device is needed. >>> GPS.

Now I don't know how the gps in ubnt for instance are connected to the radios but I presume with coax to eliminate radio interferences on the signal. Better would be fibre but yeah, I presume it can be done with (shielded) utp cable as well...

We have a gear which does this with seperate RJ45 connectors connected together with a kind of switch which needs no power (just passive interconnection). Some other gear have a central POE-Unit which gives time sync over the ethernet cable.
As I know this is not done with ethernet packets. There is a Signal modulated on top of the ethernet Signal.

So think of a 750UP which gives a signal to all ethernet ports.

Well, he ho, if MT would come out with something like a rb750sync I wouldn't mind. But with some other improvements and wishes I vent on this forum re upgrade of the rb750UP and now putting sync also in it would probably outprice these boxes. Let alone that if we would have something like MT-only sync on a single tower, we will still fall back towards the other disadvantages that sync is not making it the holy grail for wisps. (other wisp's devices, other nearbye towers, private radio's etc.)
But yeah, in towers full of your own MT stuff I'll guess syncing all these radios might improve overall performance of your radios. How MT actually can do it is up to them. I think GPS based technology will be the cheapest and fastest implementable. But maybe they have smart technicians that can do better than that......

thanks for answer... i hoped it will be easier to implement, just sync via local area network would by so nice and simple...

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

Interesting. Apart from some other reserves I have against sync this one is new to me..
Why would bad weather have a bad influence on the GPS sync? Syncd antennas like with ubnt are steered from within one GPS device? So the sync of the radios takes place no matter what weather, and since the GPS time signal usually is only used to continiously update the build-in precise clock, a short drop in communication with a sattelite due bad weather would'n hurt the clock, let alone the sync...
So the claim that weather would have an bad impact need some more explanations....? I really can't imagine how..

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

Interesting. Apart from some other reserves I have against sync this one is new to me..
Why would bad weather have a bad influence on the GPS sync? Syncd antennas like with ubnt are steered from within one GPS device? So the sync of the radios takes place no matter what weather, and since the GPS time signal usually is only used to continiously update the build-in precise clock, a short drop in communication with a sattelite due bad weather would'n hurt the clock, let alone the sync...
So the claim that weather would have an bad impact need some more explanations....? I really can't imagine how..

Yes why would weather have a effect on GPS sync, perhaps a issue with signal fade margin on the GPS receiver

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

Interesting. Apart from some other reserves I have against sync this one is new to me..
Why would bad weather have a bad influence on the GPS sync? Syncd antennas like with ubnt are steered from within one GPS device? So the sync of the radios takes place no matter what weather, and since the GPS time signal usually is only used to continiously update the build-in precise clock, a short drop in communication with a sattelite due bad weather would'n hurt the clock, let alone the sync...
So the claim that weather would have an bad impact need some more explanations....? I really can't imagine how..

Yes why would weather have a effect on GPS sync, perhaps a issue with signal fade margin on the GPS receiver

No, because the signal from the sattelite updates the clock the moment it notice that the clock in the earth device is not synchrone with the sattelite clock. But if there is no signal, or a poor one not enough to communicate time stamps, the build-in clock of the GPS device is just running and in case of radio sync, it can still be used.

Basically, to do radio sync no GPS is needed as in the "P" usage ("Positioning"). Imho gps signal in sync device is only used for updating the clock. The positioning is now just a bonus...
Full GPS devices with their continously updated clocks are much cheaper than any other clock device with the same accuracy. Hence radio manufactures use GPS por this purpose, not ordinary clocks. (Off course, a simple electronic clock could do the job but they simply cost more than bulk produced GPS boards that also come with all the electronics to give a time stamp in digital ouput. All in one hand for no money..)

Now this also explains why weather circumstances can't have any influence on the radio sync. Even if the GPS internal clock doesn't get updated, it works stable enough to be used for radio sync for as long as the clock runs....

Apart from that, radio sync takes place on units close to eachother, usually in a tower. The only weather effect I can think of that would interupt the sync is a tornado or other destructive phenomena

NTP ist not accurate. Atheros Ethernet has no sync capability as far as I now. This would need custom Ethernet chip.

Cambium ePMP 1000 and Radwin 5000 are both Atheros based systems that have a fully functional GPS sync.

There is simply no reason to not have GPS sync other than the inability to figure it out.

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

How does bad weather have anything to do with GPS sync?

BTW: To the people talking about non-GPS sync, the sync is the hard part, the GPS is the easy part. Just do it right from the get-go.

maybe it is stupid question... why do we need a gps sync? What about some kind of sync over ethernet on the same place? What about sync over time (NTP) Is it really so hard to make it work? Lets say that it will be necesary just to set up place A, or place B on RB and common ntp server....

NTP ist not accurate. Atheros Ethernet has no sync capability as far as I now. This would need custom Ethernet chip.

Well sure its true gps time can show 0.00000001 accuracy
but аs I understand we dont need accurate time we dont care if its 5pm or 9am all wee need two antenna A and B to get sync and thats all.
Why it cant be done with another software mechanism? why we need GPS time?

maybe it is stupid question... why do we need a gps sync? What about some kind of sync over ethernet on the same place? What about sync over time (NTP) Is it really so hard to make it work? Lets say that it will be necesary just to set up place A, or place B on RB and common ntp server....

NTP ist not accurate. Atheros Ethernet has no sync capability as far as I now. This would need custom Ethernet chip.

Well sure its true gps time can show 0.00000001 accuracy
but аs I understand we dont need accurate time we dont care if its 5pm or 9am all wee need two antenna A and B to get sync and thats all.
Why it cant be done with another software mechanism? why we need GPS time?

You dont need the exact time/date but you need a signal on the APs which is synced exactly.
With TDD you have a small timegap between APs sending time and CPE sending time.
When this gap is 0,1ms the sync pulse has to be reliable at all APs within << 0,1ms.
If this is not the case there is reliable interference.

This would be a way to go:
http://grouper.ieee.org/groups/1394/c/2 ... _draft.pdf

But I guess MT does no Ethernet HW-Design ...

There's no need to reinvent the wheel. Cambium, Radwin, etc. already do GPS sync with Atheros chipsets.

There's no need to reinvent the wheel. Cambium, Radwin, etc. already do GPS sync with Atheros chipsets.

well there actually is. each uses a proprietary technology, so every new player needs to "invent a wheel of their own"

There's no need to reinvent the wheel. Cambium, Radwin, etc. already do GPS sync with Atheros chipsets.

well there actually is. each uses a proprietary technology, so every new player needs to "invent a wheel of their own"

And can we ask when is Mikrotik going to "invent a wheel of their own" or will they borrow wheels for now

The interest me too!
we will buy 8 pieces Cambium EPMP 1000, only because GPS Sync!
but we prefer mikrotik!

and wecan wait, if it does not take too long.

The interest me too!
we will buy 8 pieces Cambium EPMP 1000, only because GPS Sync!
but we prefer mikrotik!

and wecan wait, if it does not take too long.

My guess: It will not happen. You would see much more progress in the wireless part of ROS if they hired a wireless engineer. And they need a wireless engineer to do such stuff like gps sync.

E.g. there are channel lists. If you use them you'll see that regulations are not respected. You see nv2 improvements in 5.24 and then in 6.9. So there is not a lot of effort in this direction.

We wait until the first usable 802.11ac gear appears and then we will walk into this direction. This will be this year. If MT makes it happen we are happy, if not we have to shop elsewhere. EPMP is 11n based but proprietary. So I would wait at the moment. The expensive line has 256QAM but is expensive and the CPEs are weak so they suffer from poor NAT-Speed.

The interest me too!
we will buy 8 pieces Cambium EPMP 1000, only because GPS Sync!
but we prefer mikrotik!

and wecan wait, if it does not take too long.

My guess: It will not happen. You would see much more progress in the wireless part of ROS if they hired a wireless engineer. And they need a wireless engineer to do such stuff like gps sync.

E.g. there are channel lists. If you use them you'll see that regulations are not respected. You see nv2 improvements in 5.24 and then in 6.9. So there is not a lot of effort in this direction.

We wait until the first usable 802.11ac gear appears and then we will walk into this direction. This will be this year. If MT makes it happen we are happy, if not we have to shop elsewhere. EPMP is 11n based but proprietary. So I would wait at the moment. The expensive line has 256QAM but is expensive and the CPEs are weak so they suffer from poor NAT-Speed.

Anything GPS sync will be proprietary, but they are working on an 802.11 mode for non-sync operations. The radios that have GPS are more expensive than many radios, but they work. None of the ePMP have 256 QAM, only standard N. Since you're not off to a good start, I'm not going to put a lot of faith into your NAT statement, but would be interested in hearing your observations.

The interest me too!
we will buy 8 pieces Cambium EPMP 1000, only because GPS Sync!
but we prefer mikrotik!

and wecan wait, if it does not take too long.

My guess: It will not happen. You would see much more progress in the wireless part of ROS if they hired a wireless engineer. And they need a wireless engineer to do such stuff like gps sync.

E.g. there are channel lists. If you use them you'll see that regulations are not respected. You see nv2 improvements in 5.24 and then in 6.9. So there is not a lot of effort in this direction.

We wait until the first usable 802.11ac gear appears and then we will walk into this direction. This will be this year. If MT makes it happen we are happy, if not we have to shop elsewhere. EPMP is 11n based but proprietary. So I would wait at the moment. The expensive line has 256QAM but is expensive and the CPEs are weak so they suffer from poor NAT-Speed.

Anything GPS sync will be proprietary, but they are working on an 802.11 mode for non-sync operations. The radios that have GPS are more expensive than many radios, but they work. None of the ePMP have 256 QAM, only standard N. Since you're not off to a good start, I'm not going to put a lot of faith into your NAT statement, but would be interested in hearing your observations.

I meant 450 with expensive,256QAM and weak CPEs. ePMP is 11n based so something that MT should have done for a while now but is not willing/able to do. That's what will make me think MT will be late with 802.11ac too and will force us to go away with the wireless part of our network.
We're watching the market and see what happens.

I meant 450 with expensive,256QAM and weak CPEs. ePMP is 11n based so something that MT should have done for a while now but is not willing/able to do. That's what will make me think MT will be late with 802.11ac too and will force us to go away with the wireless part of our network.
We're watching the market and see what happens.

Sorry for the misunderstanding. By expensive line, I thought you meant the GPS sync radios of the ePMP line as they're $500 vs. $100 for the integrated or standard connectorized versions.

Learned today that ePMP does ATPC. So no problem with regulations.
@Mikrotik Please Hurry up. I like to use Mikrotik for Wireless but If you are not willing to get wireless things done ...
Ordered some test equipment now.

...........................

My guess: It will not happen. You would see much more progress in the wireless part of ROS if they hired a wireless engineer. And they need a wireless engineer to do such stuff like gps sync.
.....................................................

Is the real issue with Mikrotik a lack of professional staff or does it go much further?

As a WISP I place reliability paramount, performance second, price third and cannot understand why Mikrotik does not concentrate its efforts at a market (wisp) which has long term customers that purchase in volume, if they produce the products requested.

...........................

My guess: It will not happen. You would see much more progress in the wireless part of ROS if they hired a wireless engineer. And they need a wireless engineer to do such stuff like gps sync.
.....................................................

Is the real issue with Mikrotik a lack of professional staff or does it go much further?

As a WISP I place reliability paramount, performance second, price third and cannot understand why Mikrotik does not concentrate its efforts at a market (wisp) which has long term customers that purchase in volume, if they produce the products requested.

I can guess only. Looking at new products (CCR, ...) it looks like MT concentrates on Routing market. They seem to not have enough staff to do other things like Dude and Wireless in parallel. Looking at ePMP this is a thing MT could have done for a while. It is Atheros Stuff MT is used to for a much longer time.
I dont know the sales numbers MT has in different markets. May be they make more money doing routing stuff?

I can guess only. Looking at new products (CCR, ...) it looks like MT concentrates on Routing market. They seem to not have enough staff to do other things like Dude and Wireless in parallel. Looking at ePMP this is a thing MT could have done for a while. It is Atheros Stuff MT is used to for a much longer time.
I dont know the sales numbers MT has in different markets. May be they make more money doing routing stuff?

And maybe "Made for Mikrotik" is another market consideration for Mikrotik when deciding what new features and products are introduced, this something other manufacturers don't have to worry about.

What the wireless world needs is per site gps sync. Let the wireless techs control site to site channel selection. But we would like to sync devices on that specific site. Can you do it mikrotik? Or what method are you guys looking for.

I'm having a hard time translating that.

I just woke up. Maybe that has something do it with it. Maybe I can clarify. Lets say you have a tower with many backhauls. It would be nice to use the same frequency for all of them. For example using the new AR9882 chip. I wonder if that chip will allow us to sync the same frequency so the wave length dont match. So we can reuse the same frequency. The airfiber 24ghz does something like this. Correct me if I am wrong. But it works great in production for me.

Dallas

Oh, yeah, so sync. Well, the PtMP systems have ABAB channel reuse, but the PtP systems can reuse 1:1 with sufficient antenna quality.

I just woke up. Maybe that has something do it with it. Maybe I can clarify. Lets say you have a tower with many backhauls. It would be nice to use the same frequency for all of them. For example using the new AR9882 chip. I wonder if that chip will allow us to sync the same frequency so the wave length dont match. So we can reuse the same frequency. The airfiber 24ghz does something like this. Correct me if I am wrong. But it works great in production for me.

Dallas

This is Antenna/Frequeny dependent. E.g. in 38GHz you can use the same frequency for ptp without sync when there are 30degree between.

Yep I have done the with AF24. With AF5 I use sync. Seems to work well. I shoot 100M tcp 1 con couple hours away from the Fiber.

Dallas

I had some time I thought I'd like ubnt products. But the more you work with it, the more you find it is limited and not performing to it`s promises.

Just a simple example; All ubnt devices have http access built in or some 'nobody really knows how it works' telnet.
But if you have to work on a network wher you have ip conflicts or no ip networking in place.... try to access your units...
Hell I'm glad MT has winbox. Very easy and very fast GUI that works without the need of IP connectivity.

"If you don't like it, don't buy it." Why not? Product lines are ever changing and to learn what is possible, and what not, you need to buy the stuff. So now and than I buy something from ubnt that looks interesting enough to do. If of use I use it, but so far most of their stuff end up in my waste bin...

Another example; Study the Airmax sector antennas and for what sector they are sold for. Than study their very poor quality radio patterns, and compare them agains any other vendor of antennes.
Where everybody uses 3dB antenna fading to tell you what working sector it has, ubnt uses 6dB. If you than try to interpolate it to 3dB you really see they are actually performing much poorer. Even according their own graphs!
And than look at their vertical beam range. Really not an antenna you want in a high tower or on a mountain top. It will have a very limited working pattern on the ground...
I tried 3 times to setup a sector with these Airmax sectors. 3 times I learned a cheaper sector from almost any other vendor that give me true data, is performing much better... so, if you want some cheap airmax sectors... I have to start digging in my bin....

But don't tell it on.. all my competitors work with their stuff. Which makes me King in network performances in my region....

Imho it is the technicians that will go for MT (or Motorola, Aruba, Cisco or whatever) where the sales dept. will go for ubnt. So who is smartest in the end... only time will tell....

What sectors do you suggest?

After some years of working Mikrotik has announced a new sector antenna with nothing new, except ac standard
http://routerboard.com/RB921GS-5HPacD-19S

No NV3, no GPS sync, no powerfull x core cpu, why?

What is the maximum throughput of this kind of device, in NV2 mode for 15 CPEs for example.
It can handle 100mbit? 10mbits/client, I´m not sure.
Maybe with 80Mhz channel bandwidth with new Lite5 ac as CPE.

But find 80Mhz free of interference and change all Lite5 clients to Lite5ac? Isn´t a cheaper solution to buy Cambium?

no SYNC no PARTY in the next close future we have to swithc to other vendor..... we are starting to use airfiber 5x for PtP for PtMP cambium seems to be the best choice for now.

No NV3, no GPS sync, no powerfull x core cpu, why?

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

GPS Sync used for synchronizing wireless transmissions is not the same as PTP/NTP/SNTP used to synchronize clocks. GPS sync is constant and much higher precision. PTP/NTP/SNTP is done every few hours to keep clocks for logs in sync. Even then, GPS Sync requires a PPS signal, which isn't supported in USB GPS devices or those in a USB based m-PCIe LTE card.

I do believe that adding true GPS Sync to a mikrotik device would require an internal GPS connected via serial and not USB. So this isn't just a simple "make a GPS Sync package for RouterOS" situation. In this case, if you need GPS Sync for transmissions, you will need to get devices that have GPS Sync as part of it.

eactly and thats Why PTP called "gap-filler" for most applications, thus.
GPS may work in some conditions, but may cause more troubles than help in really many others. and not always only technical, but legal troubles aswell.
and no, second version of IEEE1588 is Much more accurate and easy to use. its used both over RF backhaul and fiber in Very many countries in cases when they can't or not wan't to use GPS, inlcuding very long links sometimes.
you may "beleive" in whatever you prefer, its your right, but networking had Nothing with Religion "in general".
full-scale GPS thing is may be bulkier in terns of silicon or front-end, but if you need just sync or paging/messaging - its much simpler to implement. in fact you will suprised to find How Much portion of devices with major SoC suppliers - may already had ninja-support within(*approved by NSA, NRO and CIA offices here and here, stamp you finger here and put you blood here, then*).
and so far 10ns-40ns time accuracy usual for PTP - i find more than enough for practical use in RF links or fiber.
if you need better instrumental accuracy, then probably GPS become not good source aswell(poor clocks in satellites, inaccurate software and other issues) and generally other kind and grade of sync/time suggested, Much more expensive, geenrally/sadly

eactly and thats Why PTP called "gap-filler" for most applications, thus.
GPS may work in some conditions, but may cause more troubles than help in really many others. and not always only technical, but legal troubles aswell.

GPS... in what use?

eactly and thats Why PTP called "gap-filler" for most applications, thus.
GPS may work in some conditions, but may cause more troubles than help in really many others. and not always only technical, but legal troubles aswell.

GPS... in what use?

more like "GPS? what for ??!"
so far even "worst-case"(usually/achievable - less) 40ns accuracy seems enough practically for necessary time accuracy for commodity networking both over RF, fiber , copper, whatever.

eactly and thats Why PTP called "gap-filler" for most applications, thus.
GPS may work in some conditions, but may cause more troubles than help in really many others. and not always only technical, but legal troubles aswell.
and no, second version of IEEE1588 is Much more accurate and easy to use. its used both over RF backhaul and fiber in Very many countries in cases when they can't or not wan't to use GPS, inlcuding very long links sometimes.
you may "beleive" in whatever you prefer, its your right, but networking had Nothing with Religion "in general".
full-scale GPS thing is may be bulkier in terns of silicon or front-end, but if you need just sync or paging/messaging - its much simpler to implement. in fact you will suprised to find How Much portion of devices with major SoC suppliers - may already had ninja-support within(*approved by NSA, NRO and CIA offices here and here, stamp you finger here and put you blood here, then*).
and so far 10ns-40ns time accuracy usual for PTP - i find more than enough for practical use in RF links or fiber.
if you need better instrumental accuracy, then probably GPS become not good source aswell(poor clocks in satellites, inaccurate software and other issues) and generally other kind and grade of sync/time suggested, Much more expensive, geenrally/sadly

What a lot of bull is written here.... both in facts as in language usage....

1. "GPS is a much more accurate timing signal than radio based time transmissions. The GPS timing signal is typically accurate to 10 nanoseconds. However, most gps receivers lose timing accuracy in the interpretation of the signal. A typical GPS receiver with a pulse per second output can provide an accuracy of 100 nanoseconds to 1 microsecond.", just google it and you get this info for instance...
2. The time doesn't have to be accurate for sync purposes, it has to be the same 'heartbeat' all over the sync'd units. And the start 'beat' has to be the same. Any drift in time between sync'd units have to be corrected by a clock that has the same 'beat' for all devices in same sync. For this purpose GPS works perfect.
3. GPS equipment is widely available and used. There are probably more GPS devices nowadays than wifi..... meaning the knowledge to work with GPS and use it for any kind of purpose should be around and widely available. If MT has to 'invent their own new wheel' to use it, they will have no problems finding examples or just buy that technology from any specialist. The wide availability and use also makes it cheap.

Anybody writing "pool clocks in satellites" is not having any understanding in how satellites actually work. Without a atomic clock reference they can't work for what they are made for and become useless. So a 'poor clock satellite' is a non existing thing. It would be junk flying around the globe....

Imho it serves no purpose to discuss any other form of time sync than GPS because GPS time is almost the most accurate time mankind can produce and nowadays probably also be far the cheapest clock mankind can buy....

Let us better try to persuade MT to start making GPS sync available in their product line.
With new profesional antennas on the market (RF elements to name one) and the new 720Mhz cpu high power 802.11ac NetMetals we already reduced interferences a lot in our networks while at the same time increased average throughput to clients and/or can serve more clients per AP.
All we want now is sync so we can re-use more frequencies, special on towers where we have several backhauls and AP's that all want their own frequency now.....

So MT, when can we hear something about GPS sync?

so, basically GPS had no (real)advantages over PTP, right ? same feature, more overhead(both silicon and software), more troubles(technical, legal, others) without any kind of benefits.
marketing/PR bs you used in, wrapped - didn't counts for. "widely used". oh yeah. tell that to someone in places where not even one of Navstar sattelites seen
same 10ns accuracy, but no IP and political troubles, no need for extra-silicon or firmware quirks/hacks - what not to like in PTPv2, compared to GPS ? :=)

so, basically GPS had no (real)advantages over PTP, right ? same feature, more overhead(both silicon and software), more troubles(technical, legal, others) without any kind of benefits.
marketing/PR bs you used in, wrapped - didn't counts for. "widely used". oh yeah. tell that to someone in places where not even one of Navstar sattelites seen
same 10ns accuracy, but no IP and political troubles, no need for extra-silicon or firmware quirks/hacks - what not to like in PTPv2, compared to GPS ? :=)

The "bull" in my previous message was related to your language and some negatives GPS might have etc.
I'm not saying PTP is something bad, not even "something worse than GPS".
Indeed it would be more simple to implement network wide. But it does comes with its imperfections too.
PTP is depending on 'near zero loss of packet' networks or things become even worse. On a 'local-tower-only' level it might be cheaper to implement than GPS but you still need some reliable remote clock that sends the PTP packages over a near zero package loss network. How many of wlan WISP operators can really say they have that?

Your remarks of GPS beeing unreliable at some places on the globe; the risk beeing without GPS is smaller than beeing without wifi.... and the remark on 'political' or 'legal' issues'???? beats me, what political or legal issues? As long as these satellites are up you can use them freely. And if they would have been shut down by their operators I'd presume we have bigger issues on our doorstep than a running network........

I think from a sales point of view a GPS based sync might be a smarter choice since it can work on tower level even in a poor wireless network. Most of wlan WISPs will not be high-end network operators when it comes to their radio's so probably many of their buyers don't have 100% reliable networks. When MT would implement PTP time sync they would run into many more after sales complaints than just sell some GPS sync equipped devices.

PTP definatly has its purposes and for some even better than GPS. But to say its a winner over GPS based sync in general, and more in particular on Mikrotik radio based networks, that's bull.

I found a link with a nice explanation of the technology and you can distill pros and cons: http://www.albedotelecom.com/src/lib/WP-Mobile-PTP.pdf

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

If only doing a local tower sync it would be a smarter Installation doing it together with Ethernet cabling.
So you dont need GPS-Antenna. In most cases a local tower sync is enough for unlicensed bands as you cant
control signal from foreign devices on other towers.

Local only is a waste of time. Syncing multiple towers is critical.

I learned gps sync is not good to use in some environments. If you have bad weather it actually hurts your network more than helping. I found that using full duplex links that use seperate frequencies work the best. Now I am talking about backhauls. I am not talking about PTMP.

That seems to be a bad GPS installation. You shouldn't lose GPS.

So. although other methods might be available. In cost/quality nothing beats the time signal of a GPS sattelite.

If only doing a local tower sync it would be a smarter Installation doing it together with Ethernet cabling.
So you dont need GPS-Antenna. In most cases a local tower sync is enough for unlicensed bands as you cant
control signal from foreign devices on other towers.

"with Ethernet cabling"? How do you see that? To interconnect the antennas? But you still need some clock to steer the sync process. So either you have a separate device with clock that is able to steer each of the connected radios. Or you must have each radio connected to a clock.

So, yet again the option of a separate time measurement device is needed. >>> GPS.

Now I don't know how the gps in ubnt for instance are connected to the radios but I presume with coax to eliminate radio interferences on the signal. Better would be fibre but yeah, I presume it can be done with (shielded) utp cable as well...

AirMax (which failed), some PMP models, ePMP and AirFiber X all have integral GPS radios with external GPS antenna. The B5c and B5 have integral radio and antenna.

Cambium radios support on-radio GPS and proprietary GPS over Ethernet. You can use Cambium, Last Mile Gear or PacketFlux timing sources for those radios.

Well, he ho, if MT would come out with something like a rb750sync I wouldn't mind. But with some other improvements and wishes I vent on this forum re upgrade of the rb750UP and now putting sync also in it would probably outprice these boxes. Let alone that if we would have something like MT-only sync on a single tower, we will still fall back towards the other disadvantages that sync is not making it the holy grail for wisps. (other wisp's devices, other nearbye towers, private radio's etc.)
But yeah, in towers full of your own MT stuff I'll guess syncing all these radios might improve overall performance of your radios. How MT actually can do it is up to them. I think GPS based technology will be the cheapest and fastest implementable. But maybe they have smart technicians that can do better than that......

Anything short of a CCR1009 is getting to be too little for a tower router.

GPS sync is largely a win for everybody involved, so I'm not sure of any real world disadvantages other than an increase in cost.

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

I wasn't real sure what you were meaning by PTP, but I see that it's just an updated version of 1588. 1588 is fairly common.

eactly and thats Why PTP called "gap-filler" for most applications, thus.
GPS may work in some conditions, but may cause more troubles than help in really many others. and not always only technical, but legal troubles aswell.
and no, second version of IEEE1588 is Much more accurate and easy to use. its used both over RF backhaul and fiber in Very many countries in cases when they can't or not wan't to use GPS, inlcuding very long links sometimes.
you may "beleive" in whatever you prefer, its your right, but networking had Nothing with Religion "in general".
full-scale GPS thing is may be bulkier in terns of silicon or front-end, but if you need just sync or paging/messaging - its much simpler to implement. in fact you will suprised to find How Much portion of devices with major SoC suppliers - may already had ninja-support within(*approved by NSA, NRO and CIA offices here and here, stamp you finger here and put you blood here, then*).
and so far 10ns-40ns time accuracy usual for PTP - i find more than enough for practical use in RF links or fiber.
if you need better instrumental accuracy, then probably GPS become not good source aswell(poor clocks in satellites, inaccurate software and other issues) and generally other kind and grade of sync/time suggested, Much more expensive, geenrally/sadly

What a lot of bull is written here.... both in facts as in language usage....

1. "GPS is a much more accurate timing signal than radio based time transmissions. The GPS timing signal is typically accurate to 10 nanoseconds. However, most gps receivers lose timing accuracy in the interpretation of the signal. A typical GPS receiver with a pulse per second output can provide an accuracy of 100 nanoseconds to 1 microsecond.", just google it and you get this info for instance...
2. The time doesn't have to be accurate for sync purposes, it has to be the same 'heartbeat' all over the sync'd units. And the start 'beat' has to be the same. Any drift in time between sync'd units have to be corrected by a clock that has the same 'beat' for all devices in same sync. For this purpose GPS works perfect.
3. GPS equipment is widely available and used. There are probably more GPS devices nowadays than wifi..... meaning the knowledge to work with GPS and use it for any kind of purpose should be around and widely available. If MT has to 'invent their own new wheel' to use it, they will have no problems finding examples or just buy that technology from any specialist. The wide availability and use also makes it cheap.

Anybody writing "pool clocks in satellites" is not having any understanding in how satellites actually work. Without a atomic clock reference they can't work for what they are made for and become useless. So a 'poor clock satellite' is a non existing thing. It would be junk flying around the globe....

Imho it serves no purpose to discuss any other form of time sync than GPS because GPS time is almost the most accurate time mankind can produce and nowadays probably also be far the cheapest clock mankind can buy....

Let us better try to persuade MT to start making GPS sync available in their product line.
With new profesional antennas on the market (RF elements to name one) and the new 720Mhz cpu high power 802.11ac NetMetals we already reduced interferences a lot in our networks while at the same time increased average throughput to clients and/or can serve more clients per AP.
All we want now is sync so we can re-use more frequencies, special on towers where we have several backhauls and AP's that all want their own frequency now.....

So MT, when can we hear something about GPS sync?

I know the challenge to Mikrotik in making their protocol friendly with sync is not insignificant, but it does need to be done.

so, basically GPS had no (real)advantages over PTP, right ? same feature, more overhead(both silicon and software), more troubles(technical, legal, others) without any kind of benefits.
marketing/PR bs you used in, wrapped - didn't counts for. "widely used". oh yeah. tell that to someone in places where not even one of Navstar sattelites seen
same 10ns accuracy, but no IP and political troubles, no need for extra-silicon or firmware quirks/hacks - what not to like in PTPv2, compared to GPS ? :=)

What legal and political issues? Most equipment can use GPS and GLONASS.

Local only is a waste of time. Syncing multiple towers is critical.

I do not completely agree on that.
I have one tower that has 5 backhauls and 5 AP's. Its amidst a valley with many more towers from me and others.
This tower of myself needs 5 x 40Mhz channel and 5 x 20Mhz channel. Each available channel will also receive some signal from distant radios.
I can make the whole thing work by using high to very high gain antennas to create narrow beams and very high signals (-35 to -45dBm range) and by using the professional dome or carrier class antennas from RF elementes for my AP's that are all shielded pretty much from co-tower interference and remote channel interferences. Clients are fit with antennas that at least receives -70dBm but preferrably below -65. But sometimes we need to change frequencies just because some tool decided to use same as me or very close to it. It's a hell of a puzzle to find a new frequency. I always also need to look at the other end not to interfere with radio's on my other towers....(And some clients are 'looking' at one tower but get signal from another tower at the same strength if it was an omni-cpe)

If I could use sync only in this tower it would make my life much easier because I could basically use just 2 (1x 40 and 1x 20Mhz band) or 4 frequencies instead of the 10 different ones I need now. If I could do one other tower of mine the same again I would free a lot of spectrum. Since I have 60+ radio's all in theoratical 'hearing' range where the competition adds another 40 or so spectrum is short. Off course it would be better to have more towers of mine sync'd but I can't do them all anyway since some are inter connected to at least two other towers of mine so I still need to play with the frequencies.
But the puzzle would become much simpler by one fully sync'd tower, much but less simpler with 2 towers, more but even lesser with 3 etc. etc.

I hope to see soon GPS synk from MT, it's no a option.

Local only is a waste of time. Syncing multiple towers is critical.

I do not completely agree on that.
I have one tower that has 5 backhauls and 5 AP's. Its amidst a valley with many more towers from me and others.
This tower of myself needs 5 x 40Mhz channel and 5 x 20Mhz channel. Each available channel will also receive some signal from distant radios.
I can make the whole thing work by using high to very high gain antennas to create narrow beams and very high signals (-35 to -45dBm range) and by using the professional dome or carrier class antennas from RF elementes for my AP's that are all shielded pretty much from co-tower interference and remote channel interferences. Clients are fit with antennas that at least receives -70dBm but preferrably below -65. But sometimes we need to change frequencies just because some tool decided to use same as me or very close to it. It's a hell of a puzzle to find a new frequency. I always also need to look at the other end not to interfere with radio's on my other towers....(And some clients are 'looking' at one tower but get signal from another tower at the same strength if it was an omni-cpe)

If I could use sync only in this tower it would make my life much easier because I could basically use just 2 (1x 40 and 1x 20Mhz band) or 4 frequencies instead of the 10 different ones I need now. If I could do one other tower of mine the same again I would free a lot of spectrum. Since I have 60+ radio's all in theoratical 'hearing' range where the competition adds another 40 or so spectrum is short. Off course it would be better to have more towers of mine sync'd but I can't do them all anyway since some are inter connected to at least two other towers of mine so I still need to play with the frequencies.
But the puzzle would become much simpler by one fully sync'd tower, much but less simpler with 2 towers, more but even lesser with 3 etc. etc.

Are there any products currently available in the fixed wireless market today local sync only? I think every form of fixed wireless sync in use today is GPS based. There must be a reason for that.

Maybe I should rephrase that. Anything other than GPS based sync as an end-game is a waste of time.

Local only is a waste of time. Syncing multiple towers is critical.

I do not completely agree on that.
I have one tower that has 5 backhauls and 5 AP's. Its amidst a valley with many more towers from me and others.
This tower of myself needs 5 x 40Mhz channel and 5 x 20Mhz channel. Each available channel will also receive some signal from distant radios.
I can make the whole thing work by using high to very high gain antennas to create narrow beams and very high signals (-35 to -45dBm range) and by using the professional dome or carrier class antennas from RF elementes for my AP's that are all shielded pretty much from co-tower interference and remote channel interferences. Clients are fit with antennas that at least receives -70dBm but preferrably below -65. But sometimes we need to change frequencies just because some tool decided to use same as me or very close to it. It's a hell of a puzzle to find a new frequency. I always also need to look at the other end not to interfere with radio's on my other towers....(And some clients are 'looking' at one tower but get signal from another tower at the same strength if it was an omni-cpe)

If I could use sync only in this tower it would make my life much easier because I could basically use just 2 (1x 40 and 1x 20Mhz band) or 4 frequencies instead of the 10 different ones I need now. If I could do one other tower of mine the same again I would free a lot of spectrum. Since I have 60+ radio's all in theoratical 'hearing' range where the competition adds another 40 or so spectrum is short. Off course it would be better to have more towers of mine sync'd but I can't do them all anyway since some are inter connected to at least two other towers of mine so I still need to play with the frequencies.
But the puzzle would become much simpler by one fully sync'd tower, much but less simpler with 2 towers, more but even lesser with 3 etc. etc.

Are there any products currently available in the fixed wireless market today local sync only? I think every form of fixed wireless sync in use today is GPS based. There must be a reason for that.

Maybe I should rephrase that. Anything other than GPS based sync as an end-game is a waste of time.

Radwin has a local solution where gps can be added.

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

I wasn't real sure what you were meaning by PTP, but I see that it's just an updated version of 1588. 1588 is fairly common.

yep. 1588v2 as most widely-used and efficient version of PTP.
and yes its "fairly common"(in fact - MORE than GPS sync in telco), but NOT supported by RouterOS aswell as GPS sync, yet.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

thats why aside GPS sync and NTP is PTP introduced to fill gap between.
usually nodes in Telco - support Both GPS and PTP for obvious reasons. and control nodes and routers - rely on SNTP aswell.
(https://en.wikipedia.org/wiki/Precision_Time_Protocol meant. other PTP protocols exist, but Wastly less popular, as i can see)

I wasn't real sure what you were meaning by PTP, but I see that it's just an updated version of 1588. 1588 is fairly common.

yep. 1588v2 as most widely-used and efficient version of PTP.
and yes its "fairly common"(in fact - MORE than GPS sync in telco), but NOT supported by RouterOS aswell as GPS sync, yet.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

If GPS in devices in your jurisdiction is a crime, I think you have bigger issues ahead of you than ROS. GPS and GLONASS are supported in most every mobile phone.

GPS\GLONASS is used fairly extensively in the mobile wireless infrastructure as well.

What legal and political issues? Most equipment can use GPS and GLONASS.

you must be new to Telco(outside NA), then.
in many installations - both having Navstar enabled or even having GPS-enabled devices in infrastructure - is crime.
same ~ about GLONASS in NATO-controlled countries/regions.
its also somewhat not EMI-resistant much(atleast civilian channels) to be used in surprisingly big portion of installations.
so, no, GPS isn't "magic bullet" or even thing you can rely on. its simply to use(if you had support for or had Rights to use it), but its only advantage, which not worth it, basically, cuz 1588v2 imply same 10ns sync accuracy without all that headache.

That's a stupid statement.
GPS is used in 80% of the world new cars, 100% of the worlds smartphones are using GPS, 99% of worldwide shipping uses GPS, there are hundreds of thousand GPS navigation devices sold of the last years.
Al in all I would guess a couple of billions of GPS equipped devices must be around on the globe, and you refer to a crime of using these? From what world are you?
I can travel to most countries in the world with my smart phone (Includig Russia and China for instance) and nobody asks me if my GPS enable smartphone has a license to use it...... So your comment in that respect to 'Hammy' is really weird....

Also; the statement the PTP protocol is use widely in wireless industry is a bold one. I'd gather ubnt is market leader in the WISP section but can't find no trace of it using PTP. They work with GPS sync.
I didn't go into looking other brands (MT is a small player but also no PTP, nor GPS.) but the PTP protocol isn't hardly so common as your statement would make the inocent to believe.

I think you must be new to Telco (world wide), then.....

then again, you must be new to telco.
anway, using (groundless/unbacked)"arguments" such as "anyone use/know", "for sure", "definitely", "of course", "unboubtely" is as useless as listening to them. you had opinions(but more like perception/expression from you Personal experience in lifetime, work), like most of us - do, but thats not change reality itself. sadly or luckily, nvm.
as for examples, some facts:
all Chinese and Russian telco and ISP, service providers - switched to using 1588v2 long ago(from GPS), same about notable part of middle east of ISP's and far east/pacific countries drifting toward "Chinese"style of 1588v2 adoption.
its include both RF links, fiber(including long-range), satcom and some other applications.
other companies(that include some of NA installations and other affiliates)dropped GPS sync use cause of EMI issues.
anyway, its pointless to argue with someone failing to accept that there is simpler solution with similar performance(despite smaller footprint/overhead both in terms of silicon or software/firmware)/accuracy, just because "he just desperately want something from vendor and and find best way to achieve that to promote/troll such features, aswell as bl other, more convenient option).
personally i wish you luck with Navstar usage, but similarly how how threat 1588v2, i give no fuck bout it, just like other Free World countries do.

The main question remains: is mikrotik planning to develope hardware with any kind of sync? If yes is it possible to know the developing status about this hardware?

Normis please give us an answer.

Thank you Giuseppe

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

Still more emotions that facts......

can we're strip emotions or personan offences and talk bout topic and facts:
1588v2: no need for extra-silicon, simpler code, no IP and political issues, less "blackboxed" things in solution
gps sync: "simplicity" (ony When/IF someone invest TREMENDOUS efforts into implementing support of it)
same 10ns accuracy, same usage, comparable adoption(some sites - used both).
so far, all BTS/base stations, fiber backbone, p2p and p2mp RF links - used 1588v2 as far as i can see, including those with GPS-sync enabled hardware and firmware and disabled GPS sync.
you opinions - maybe differ from mine aswell as experience, but thats not give you "supernatural" and exclusive ability/super-power to both opress others or dictate/manipulat mikrotik devlopers about their priorities and roadmap.
if you like - mikrotik products - fine. if you don't - there is plenty of other vendors on market.
you had you opinion, you shared it, you heard. and even had feedback(sometimes "nicer" than mine and less polar), but there is NO need(in my opinion) to out-cru/shot about again and again and again, trolling others.

Still more emotions that facts......

The whole thread is based on ... nothing. MT never did GPS and never built a radio. UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

To what are you actually referring? A specific radio? Or just their radios in general? And what is the connection to the sync issue in making this last remark?

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

UBNT hired a crew of radio experts from Motorola to do this radio. It is far superior to standard WiFi based radios. You get most out of small channels and it performs very good with other radios near by as it has better neighboring channel rejection.

To what are you actually referring? A specific radio? Or just their radios in general? And what is the connection to the sync issue in making this last remark?

Airfiber as said in $subject. The other radios are atheros based.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

UBNT first tried GPS sync on their AirMax radios and failed. They hired away some of the Motorola crew and got GPS sync right with their AirFiber line.

Cambium does GPS sync on Atheros chips as does Radwin. I know others have as well. Mimosa is doing it with Quantenna chips.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

how much "afwully large" was translated to "common people's math" ?
"7%"? "12%"? i don't think its bigger than 20%. ~avg
and several GPSsyn-enabled/aware devices/solutions - installed/used without it as i explained above/before for reasons told before aswell and some others.

thats basically all of them, enumerated, plus portion of cellphone infrastructure gear/stations manufacturers.
so as you can see "GPS sync" isn't "magic bullet", or widely-adopted in telco/it.

That's an awfully large percent of units shipped in our industry.

how much "afwully large" was translated to "common people's math" ?
"7%"? "12%"? i don't think its bigger than 20%. ~avg
and several GPSsyn-enabled/aware devices/solutions - installed/used without it as i explained above/before for reasons told before aswell and some others.

I would guess well over a third, possibly even a half.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

Besides, it is not even true. PTP (1588) is only a way to distribute time sync over ethernet, and those installations
contain a reference clock that itself is usually synchronized to GPS. So you can call a PTP installation GPS synced as well,
PTP is only a distribution mechanism not a synchronization source. Similar to a distributed PPS line.

I think in this tread we have some confusion amongst some of us.
Let me explain.
In fact, we have different timings happening on radio network to what is our objective:
1. Ordinary time. Useful for log registers and schedulers, scripts etc. As long as there is a clock in a device it is nice it would reflect the time we see on our watch! Special in troubleshooting its handy that you can compare different units on a time base to see what happened. Accuracy needed is seconds....
2. Send/Receive timing in ordinary 802.11 networks. The RTS/CTS protocol. A very rudimentary timing sync for nodes in a network. The nodes have to negotiate amongst each other whose turn it is to speak/listen. No real time needed, not a real timing sync.
3. Send/Receive timing in TDM (tdma or airmax or nv2 etc.) networks. Here an AP sets a send/receive schedule for itself and each connected node. This way the 'hidden node' issue is avoided and better use of the spectrum capacity can be made by separating each node's sending or receiving from the others. "One after the other gets his turn". It becomes important that nodes in a network become synchronized but the (proprietarily) protocol guarantees such. We have a master-slave network where the master depicts when and how long the client can send or receive, each at its assigned time.
4. Send/Receive timing in multi AP networks where frequency or interference avoidance is needed. By having all radio's on a tower that work in the same frequency band sending and receiving at the same time we reduce (up to elimination) interference between radio's in the same tower. Off course we need some master clock that now has to be connected to each of the other units to give a 'zero' ("Z") time signal and the difference to it very precisely. Even after long time all connected units must still run in the same sync. Hence the update of "Z" that can happen at an almost continuously basis.
It now becomes possible on a same tower to use several radios working on the same frequency but in different direction to serve different distant nodes. We need less spectrum and the overall quality of the network (clearer signal) also goes up! Win-win...? No;
There is one side effect; In tdma networks we have several options;
a. Variable, but fixed, time slots. Depending on the latency versus throughput and distance of node we have to set a certain length of the time slots. So they can be different for different AP/BH radio's.
b. Variable adapted times slots. If have seen some examples of technologies where the time slot actually can get change upon need of the network.
If we want a tower to be fully sync, all radio's need to adept to the same scheme. And since the radio that for whatever reason needs the longest time slot it predicts the sync for all others The overall outcome might be that for some PtMP networks (or PtP) the latency goes up (a bit...)

5. Send/Receive timing in multi AP/multi tower networks. For same reasons as 4. we might want to sync even between towers. If all AP's in a region would transmit at the same time clients that receive signals from different AP's will benefit.
This will have a new complication. If these towers are interconnected with radio backhauls in the same radio band and taking part in one of the tower’s sync it automatically will be in counter sync on the other tower.
To solve this, we can start working with ABAB sync over radio backhaul towers but if all these towers have AP's and in between them are clients that can 'hare' two or more the risk is now a client becomes in full counter-sync with some other AP network. If clients are now in close proximity but one connects to tower 'A' and the other to 'B' they could start interfering with each other, special if the frequencies are the same or close.
To arrange such a network properly becomes a complicated task.

1. a simple clock will do, each unit on its own a time stamp from the NTP protocol is sufficient.
2. no clock is needed. Abait that the radio itself creates some time related energy pulses (the frequency) nothing more is needed.
3. A precise clock is needed to sustain a coherent time slot with a protocol that guarantees all nodes are in sync with the master (AP). Since each clock can vary in speed each node also needs to be continuously updated by the master. The tda protocol takes care of that. This could also be done by GPS or the 1588 protocol but since actual time is not needed, only sync, the tda is good enough and doesn't need any further hardware. (I don't know if the 1588v2 is better or worse than tda but since most vendors are still developing or using any form of tda I presume it’s a winner...)
4. To sync between different hardware devices there need to be some interconnectivity between units on the tower with one master. This master not only needs to set a "z" hour time stamp to each unit, it also needs to update it continuously to guarantee all units stay in sync. At the same time, it also needs to override each radio's own tda settings. Since all tda's timeslots on all radio's need to have the same length and therefore start/stop this very important.
To transport the sync, signal a protocol like 1588v2 can be used or any other proprietary. The master is best equipped with a very precise clock and since usually only one master is needed, and a radio that sits on a tower usually also 'sees' several satellites a GPS sync'd clock seems to be the best way to go. (And most vendors do so... Other earlier mentioned GPS 'issues' are virtually of no importance.)
5. If we now also need to sync between towers we have to guarantee the time stamps and hour "Z" are the same on both. We can do that with the 1588v2 protocol but if the towers are only interconnected by radio backhauls it might be more reliable to only transport the start cycle and the tda scheme to be used to send over the radio where the actually timing than is done by a GPS updated clock that guarantees that the time cycles between towers are of the same length.
(GPS is now probably more reliable than 1588v2 because the radio link can be interfered o hammered by all kinds of issues that if towers would be dependent on this sync only would make a mess a soon as packages get distorted, corrupted or delayed. The change two GPS clock in relative close proximity are going to run out of sync of each other is very, very small...)

Bottom line is; Sync within a tower, or between towers, is a spectrum saver and will also benefit the overall quality of the network but isn't the holy grail on itself. Imho several technologies are needed in combination to fight nowadays challenges to make and keep a good network running. That GPS is a tool of choice to sync AP’s and towers can be seen by the many vendors that are using it or are preparing their hardware to do so.

However, I'm done with this GPS vs. 1588 thing.... it's taking away from the core issue of Mikrotik not having sync.

Besides, it is not even true. PTP (1588) is only a way to distribute time sync over ethernet, and those installations
contain a reference clock that itself is usually synchronized to GPS. So you can call a PTP installation GPS synced as well,
PTP is only a distribution mechanism not a synchronization source. Similar to a distributed PPS line.

yep. regardles how its carried - over fiber, copper, RF or open air lazer links - its "just works".
similarly GPS/Navstar is "distribution mechanism" and their atom clocks(still less accurate than Galileo or GLONASS had) and sofware - ARE Source.
but thats my point actually: with PTP support - anyone SO "desperately wanting" GPS syn usage for their (respected)reasons - can simply plug ting/inexpensive device into Mikrotik and have their GPS syn working,without reshuffling and doing lot of work on HW and FW lefls by MT team.

as for "practical side" of question/suggestion: one of MikroTik partners, Qualcomm - one of biggest supplier of cellphones infrastructure components(or even complete solutions, made from) and most of base station chipsets, they supply(as well as stations itself)support all 3 kind/networks of satellite sync. same apply to relevant part of SDK(which isn't part of Atheros stuff, MT may be familar with, i fear).
so talking from implementation side - it wouldn't be big deal for them and long time ago. but apparently they consider it redundant (or simply filter-out cause "cost/profit"ration(in both sense of)), maybe.
as you can noticed, perhaps - there Already "GPS" package in RouterOS, and aside positioning - it HAD support time sync aswell.
so i think whole topic kind redundant, thus(no offense !), caze anyone wanting syncing - would Already have plugged GPS receiver and configured dat package to working state.
maybe im wrong, of course. anyone can.

Just to add some ideas / reading :

http://www.ieee802.org/3/time_adhoc/pub ... 1_0509.pdf

Just to add some ideas / reading :

http://www.ieee802.org/3/time_adhoc/pub ... 1_0509.pdf

thats quite short and quite old article which despite highlight basic issues and conclusions about sync and PTP, referenced only for obsolete version of 802.1AS and PTP IEEE 1588v1. IEEE1588v2 had Much better parformance and had Resolved most of issues restricted its usage as main PTP for both 3G, LTE and 5g networks aswell as long-link fiber and open air laser links
original IEEE1588 was dated 2002, updated/improved IEEE1588v2 was standartidised in 2008, ie ~ only year before this paper released and not really widely-adopted at time of reserarch apparently, but quite common/standard thing nowdays.
https://en.wikipedia.org/wiki/Precision_Time_Protocol
there several 'grades' of precision/sync and different kind of protocols established for different purposes of in result. for most basic needs there was NTP, SNTP, then PTP derrivatives and for "science-grade" sync there several more obscure protocols, most of which never really standartdised or interoperable with counterpart(most never adopted outside country or even outside particular company/lab).
IEEE1588 aside data telecom- used in medical equiment, in broadcasting(not only in SMPTE), in commodities manufacturign and whatever else you need time(ie anywhere).
similarly - most popular IEEE1588-related articles - refering ot obsoleted IEEE1588v1 version of it, like this NI page for example http://www.ni.com/newsletter/50130/en/
IEEE1588v2 had Much better performance, again.
so far 10ns accuracy seems more than enough even for long links in my opinion.

We waited a really long time for synchronization... now we are planning to build new areas with ubnt radios and mikrotik routers. We tried a lot and ubnt just works better in noisy enviroment. It is somehow funny.... when ubnt started we told ourselves that we dont want to use cheap hardware. Situation has somehow changed... ubnt no longer cheap but mikrotik is...

We waited a really long time for synchronization... now we are planning to build new areas with ubnt radios and mikrotik routers. We tried a lot and ubnt just works better in noisy enviroment. It is somehow funny.... when ubnt started we told ourselves that we dont want to use cheap hardware. Situation has somehow changed... ubnt no longer cheap but mikrotik is...