Do raid controllers syncronize HDD platter rotation?

Generally I'm pretty sure the answer is no (in fact I know of no controller that does this).

Doing such a synchronization would be incredibly difficult - vibration, temperature, natural power supply fluctuation, etc. all have small effects on the platter rotational speed (and if you want to be REALLY picky, the size of a sector). You would need to constantly vary the speed of the disk spindle motor by infinitesimal amounts to maintain synchronization, which would require very precise (very expensive) motor controls, and lots of disk controller overhead to determine the current platter position of each drive. As there's little to no practical benefit from doing this it's not worth the silicon and time.

(This idea also completely falls apart if you think outside the box of rotating rust media -- Solid State Disks have no seek time or spindle speed: Reads are effectively constant time for any sector, and there's nothing to "synchronize".)

RAID controllers did not (and could not) synchronize disk spindles, but it was an option on some drives. Given a set of identical drives with spindle sync connectors you could ensure a set of disks were all synchronized. I happened to own some Seagate Elite 3 (ancient, obsolete SCSI-2 drives) which I remembered having such a connector so I found the Seagate ST43400N/ND Elite 3 user guide which has this handy illustration in Figure 1 (note connector second from the left):

Figure 14 (not shown here) illustrates how to connect the drives together:

Synchronizing the spindle

The spindle sync feature makes it possible to synchronize the spindle rotation of a group of disc drives. This reduces the latency normally encountered when the initiator switches between multiple disc drives. Figure 14 shows two system configurations. In one type of system, one of the disc drives in the system provides the reference clock. In the other type, an external signal source provides the reference clock.

Synched drives dont make sense any more for several reasons:

• Disks have bad sectors relocated at production. Disks are huge, and have a number of defects after production, which are relocated. Therefore, two disks of the same production run will not be 100% in sync anyway.
• Disks internally relocate bad sectors during use. These sectors get moved to reserved space on the disk, putting it more out of sync.
• Cache, TCQ/NCQ and relocated sectors make disk access ordering nondeterministic on the physical level. If the load is high, if one disk goes out of order, it may be a long time until it gets back in order.
• Multi-Stripe access can go over sector (or even platter) boundaries, disaligning reads anyway. If you access, say, 4x stripesize on a Raid 6, some of the stripes might be in different zones of the different disks.
• Read accesses in Raids generally do not target all disks, as long as the disks do not complain about their block checksum. This puts disks out of cache sync, and out of physical sync in consequence. (Unless you also turn off read cache)
• Read caches on the raid controller, read-write caches in the OS further complicate the matter. And I hope there is no swap space on the raid, which might thrash any performance issues anyways.

In the early days, disk synch was implemented to make access deterministic, which was important when Memory to store results was scarce, or when the implementation of the raid needed it (Raid 2, Raid 3).

It is hard to quantify the advantages of synched drives. I suppose if there was a substantial performance advantage to be gained, synch would be possible in some way.

In the future, with SSDs, the matters are similar, but for different reasons, with block relocation, wear levelling, trim, etc.

Modern drives have their own operating systems and spend time internally for a number of issues, be it HD or SSD. Even if you made them physically in sync, logically they would not be in sync anyway.

If you ever go down and use the never used RAID-2 where data is striped at the bit level, it required disks to be synched. No one I know ever used it, but, technically, if a RAID controller supports RAID2, it would need to be able to synch platter rotation. This would be the only need to have it now a days.