[Beowulf] IEEE 1588 (PTP) - a better cluster clock?

[Patrick Ohly]

Hello,

I have some news about IEEE 1588 that look like they'll address some of
the concerns raised on this list about the use of multicasts for
communication: the next revision of the standard will have extensions
which allow to run PTP without multicasts or at least less of them.

The first change is that clients can ask their server for permission to
communicate via unicast. This alone would already avoid the situation
that the clients' multicast packets wake up all daemons on all nodes.
The master still has to receive and process all these packets.

The second change is that switches and routers can act as "peer-to-peer
transparent clocks". In that mode the network device responds to clients
connected to it directly instead of forwarding the clients' packets to
the master. This mode is both more accurate and more scalable.

The accuracy could also be improved if the switch/router act as
"end-to-end transparent clocks": in that mode they add the delay added
by their own processing to a field in the outgoing message, but all
packets still need to be transmitted between clients and master.

I've heard that at least one vendor will improve IEEE 1588 support in
his switches; I'm not sure whether this has been publicly announced, so
please excuse me for not saying which one. Instead I'd like to turn the
question around:
      * Which switches/routers are currently your preferred choice when
        building a cluster?
      * If for some reason your preferred choice is impossible, what is
        used instead and why?
      * Would good IEEE 1588 support influence the buying decision
        (probably too early to ask, but who knows, perhaps you are
        already excited about it and can't wait to add support for it to
        clusters...)?

Reply privately if you want to; I'll summarize the responses on the
list.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.