Observing Time

Photo by John Baker on Unsplash Photo by John Baker

One of the most salient features of Cardano is time; time from a stake pools operator perspective is what will be recognized here.

How to measure time?

The mere act of measuring time changes the measurement of it. In physics, this is called the observer effect theory. An example of this is monitoring the pressure in a tire, letting some air out while you are checking it, changes the pressure in the tire.

Keep that in mind, as we are not, seeking out the absolute measurement of time, letting out some air is acceptable. The tools we will employ to measure time are cheap and fast, not necessarily good, but not that bad for what we are accomplishing here comparing network latency across one network span to another.

Core & Relay

Cardano stake pool operators are in charge of two different types of nodes, core & relay.

Core nodes are the ones that do the actual signing on to Cardano's blockchain, defined by Cardano's variable k, 100 or 1,000, or? Core nodes typically are not exposed to public networks.

Relay nodes are exposed to the harsh public network, announcing to Cardano's ecosystem the changes that a core node have undertaken on behalf of the stake pool.

Core nodes typically communicate only with trusted relay nodes, unrestricted relay nodes then pass the changes out into the public network, for further distribution.

In Cardano, a stake pool can have only one core node operating at a time. Whereas, the number of relay nodes has no restrictions.

Measuring Time

Below is an actual evaluation we conducted across one IP transit provider. In evaluating their network, we deployed to four locations, Amsterdam, New York, Sunnyvale, CA. and Tokyo.

The three tables are broken down by three transit address types IPv4, IPv6, and backend. IPv4 and IPv6, are over public routes, the backend is over mostly private interconnections.

Remember we are not seeking absolutes, so the tool employed here, ping, is not ideal but it is standard on almost all operating systems, so let's go with it and if you find a network promising you can employ better tools to optimize further. 1

ping  ipv4-address

ping6 ipv6-address

IPv4 Public

IPv4 Public Amsterdam New York Sunnyvale Tokyo
Amsterdam 0.034 75 152 236
New York 75 0.035 68 196
Sunnyvale 152 68 0.065 126
Tokyo 236 196 126 0.029

IPv6 Public

IPv6 Public Amsterdam New York Sunnyvale Tokyo
Amsterdam 0.052 104 174 270
New York 104 0.062 74 168
Sunnyvale 174 74 0.068 118
Tokyo 270 168 118 0.062

IPv4 Backend

IPv4 Backend Amsterdam New York Sunnyvale Tokyo
Amsterdam 0.035 80 148 254
New York 80 0.031 67 168
Sunnyvale 148 67 0.063 101
Tokyo 254 168 101 0.032

The tables allow for a row or column selection of a location to a destination.

Recall that time measured in milliseconds, 1/1,000th of a second is roundtrip. 2

The first thing we noticed is IPv6 never came out on top, with the lowest ping times. It is not always the case for IPv6, coming in last, but sadly it's mostly a given.

With IPv6 out, we turned to IPv4 latency times over public and backend private addresses. Having backend private IPv4 available, allows one to extend traditional private transfer across worldwide locations without the need to operate transportation overhead like SSH for example. Trust us backend networks are very valuable if you can get it, do!

The clear winner is the IPv4 backend, almost always this is the case because the IP transit provider is in charge of all or part of the routes between backbone locations.

Let's say that we like these backend latency numbers for our stake pool, so we decide to deploy 1-core node and 4-relay nodes. Which location should get our primary core node?

IPv4 Backend Amsterdam New York Sunnyvale Tokyo
Amsterdam 0.035 80 148 254
New York 80 0.031 67 168
Sunnyvale 148 67 0.063 101
Tokyo 254 168 101 0.032
Time Total 482.035 315.031 316.063 523.032

By totaling time across all four locations New York and Sunnyvale offer the lowest latency times. By looking at a world map it becomes quite clear, lowest latency locations for a core node is more in the middle than not. Makes sense right? The shortest distance between two points is in the middle.


Core & Relay Bare-metal Relay Only Container Core & Relay Launching Q4, 2019


Now when viewing our Cardano stake pool world map, it should be clear why certain places were selected, over others.

Hopefully, this post gets Cardano stake pool operators thinking about latency and how to quickly measure it.

It certainly seems to us that Cardano's framework writers Philipp Kant, Lars Brünjes and Duncan Coutts did, they put the cost variable under a pool operators desirable command. 3

Even if every user were to run a node that was online all the time, it would be hard to keep all those nodes well enough in sync to avoid forks and still keep a short slot length. Our delegation design is aimed at keeping the number of nodes that produce a significant amount of blocks reasonably small (about 100 or 1000 nodes), so that effective communication between them is feasible.

For more on operating a Cardano stake pool see, Operate a Cardano Stake Pool No Cost for how some are viewing cost wrongly, You Need to Pledge to a Cardano Pool. Here is Why. on how Pledge makes decentralization of owners possible, and Cardano Stake Pool Variables for all the controls a pool operator has to adjust their desirability level.

Now go and measure your pools latency, lets put time on Cardano's side.





© 2019 to Adaizen, LLC Keep Cardano Roaming Free
Remember, we're not only engineers, but we're also Cardano owners.