IRIS Knowledge Base :: Delayed exports from seedlink

Knowledgebase Home

Search the Knowledgebase

Browse by Category

Delayed exports from seedlink

Q: At the moment, a station I am observing with seedlink will have
delays of just a couple of minutes, but this afternoon I was seeing
delays closer to 10 minutes.

I am pretty naive on this subject, but from my Earthworm and Antelope
experiences I don't see why data should ever be more than maybe 10
seconds delayed if everything is working correctly. And yet the BUD
latency monitor shows that most of my primary network is delayed
well over the one minute mark. Moreover, the networks with which I
feel we have the most similarity seem to exhibit the same.

1) Can you make any general observations about why these networks are
mostly delayed?

2) What is the difference between feed latency and total latency?

A:
1) Delay on the network operator's end is usually how quickly they can get the data to a server that feeds us, it is often a secondary task relative to their real-time operations. For networks using Earthworm we often get the data from a waveserver which is not really designed for low latency streaming, we use that method because it's better than an Earthworm export process regarding completeness.

When the data arrives at the DMC it does not become available to other systems until we can fill a fixed-length SEED data record, lower sample rate data are delayed longer due to the process, noise level also plays a role as it effects compression efficiency. As a reference 40 Hz data is hardly delayed by this record building process, but 1 Hz data is definitely effected. We need SEED data because our system has been designed to feed our archive primarily, there is a tradeoff with the latency of export feeds.

2) Here's a graphic that may help: http://www.iris.edu/data/latency.htm

In general it is almost always one of three things.

1) The Packetizing time at the network operator --- they fill packets and then send them. However the way we define latency normally eliminates most of this delay. Networks get behind sometimes as well and it takes time to catch up.

2) At the receiving end some processes buffer things to sort out of order data and this introduces an artificial delay, this happens due to systems that send data in a LIFO priority. CD1.1 is a good example of this.

3) At the DMC we also have to fill packets. If a packet is almost full but not quite it has to wait for the next packet before it can complete the previous packet. This can introduce delays of a bit more than the length of time a packet covers... a 20 sample per second stream in a 512 byte buffer
can introduce a delay of 25-30 seconds in this manner. This is of course dependent on the transport protocol and affects different networks.

Delays of greater than a minute are usually the result of something going on at the network operator end.

Real Time Data Uptime Expectations

We now have a policy for expectations of real time data availability. Users should consult this policy to understand what our mission goals are in terms of providing real-time data.