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...