[HN Gopher] White Rabbit Project (2020)
       ___________________________________________________________________
        
       White Rabbit Project (2020)
        
       Author : kimburgess
       Score  : 95 points
       Date   : 2023-06-23 11:57 UTC (11 hours ago)
        
 (HTM) web link (ohwr.org)
 (TXT) w3m dump (ohwr.org)
        
       | throwoutway wrote:
       | Now getting a Gitlab 500 "Whoops, something went wrong on our
       | end" error page on even the root domain
        
       | mitchbob wrote:
       | https://web.archive.org/web/20230623115746/https://ohwr.org/...
        
       | twic wrote:
       | Not mentioned in their list of users, but at least one stock
       | exchange uses it internally, and exposes it to participants:
       | 
       | https://www.eurex.com/ex-en/support/initiatives/archive/high...
        
       | tracker1 wrote:
       | Not to be confused with:
       | https://en.wikipedia.org/wiki/White_Rabbit_Project_(TV_serie...
        
       | orourke wrote:
       | "sub-nanosecond synchronization"
       | 
       | "typical distances of 10 km between nodes"
       | 
       | Light travels 30cm in a nanosecond. How do they achieve sub-
       | nanosecond accuracy over long distances?
        
         | faisalhackshah wrote:
         | It seems that you're implying that nodes cannot be synchronized
         | within the time it takes for light to travel between the nodes.
         | 
         | Images both nodes having their own atomic clocks. Now allow
         | them to timestamp transmitted and received messages with very
         | high precision.
        
           | tgingold wrote:
           | In a white-rabbit network you don't need atomic clocks on
           | each node. One atomic clock is enough, its frequency is
           | distributed over the network.
        
         | [deleted]
        
         | Xarodon wrote:
         | Because they know the speed of light and the distance between
         | nodes so they can account for the propagation delays of light
         | due to distance.
         | 
         | They're not talking of sub millisecond latency in
         | communications.
        
           | dphidt wrote:
           | Even better, the actual in situ delays are measured and
           | compensated for, and it works independent of the physical
           | connection (and through fiber/copper, switch layers, etc.).
        
             | willis936 wrote:
             | And even better: they suggest the use of a single medium
             | for both transmission and receiving (1000BASE-BX10) to
             | minimize asymmetry.
             | 
             | https://ohwr.org/project/white-rabbit/wikis/SFP
        
             | tgingold wrote:
             | Only over fiber. Copper SFPs are not deterministic enough
             | to precisely synchronize networks.
        
           | tgingold wrote:
           | No, we don't know the distance between nodes (although we
           | could deduce it). But using timestamps, we can know the
           | round-trip time.
           | 
           | See https://www.ohwr.org/project/white-
           | rabbit/uploads/2b9d42b664... (page 9 and later for the
           | principle).
           | 
           | If you want all the details, see
           | https://ohwr.org/project/white-
           | rabbit/uploads/6a357829064b9e...
        
             | Aune wrote:
             | When synchronizing two nodes A and B, where there is a
             | persistent difference in the travel times A->B and B->A,
             | how do you achieve synchronization when knowing A->B->A or
             | B->A->B?
        
               | rcxdude wrote:
               | you can't. You can only assume that they are equal and
               | attempt to make them as equal as possible. (the same
               | issue arises when measuring the speed of light: it's
               | actually not possible to distinguish if the speed of
               | light is different in one direction to another, we only
               | know accurately the average of each direction)
        
               | ooterness wrote:
               | Delay symmetry is a critical assumption in any two-way
               | time transfer process. White Rabbit goes to extreme
               | lengths to maintain that property.
               | 
               | This includes mandating use of cables that share a single
               | optical fiber, with specific wavelength pairs and fiber
               | types so you can calibrate for unavoidable differences in
               | propagation time.
               | 
               | More info on their wiki:
               | 
               | https://ohwr.org/projects/white-rabbit/wiki/SFP
        
               | tgingold wrote:
               | For a first approximation, you can assume A->B and B->A
               | travel times are equal.
               | 
               | And because optical links are used, the asymmetry is
               | mainly due to the wavelength difference which is known.
        
             | ramdac wrote:
             | What happens when the roundtrip time isn't consistent?
        
               | nickez wrote:
               | The roundtrip time is never consistent. Light travels
               | with different speed in fiber depending on the
               | temperature. This is why you calibrate every second.
        
           | bestouff wrote:
           | Indeed. It's exactly the same (albeit on a different scale)
           | as NTP synchronization, where you can frequently (ha!) reach
           | a few ms accuracy over a hundred ms latency network.
        
       | willis936 wrote:
       | Important and relevant piece of information: IEEE 1588-2019 HA
       | (default profile) is interoperable with White Rabbit.
       | Unfortunately I haven't seen any commercial support for this yet.
        
       | cbm-vic-20 wrote:
       | [flagged]
        
       ___________________________________________________________________
       (page generated 2023-06-23 23:01 UTC)