September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



Distributed Computing

  Download PDF version of this article PDF

Error 526 Ray ID: 48a5e1b09f41c5e2 • 2018-12-17 02:15:23 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 13, no. 4
see this item in the ACM Digital Library


Tweet


Related:

Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - Corp to Cloud: Google's Virtual Desktops
How Google moved its virtual desktops to the cloud


Pat Helland - Life Beyond Distributed Transactions
An apostate's opinion


Ivan Beschastnikh, Patty Wang, Yuriy Brun, Michael D, Ernst - Debugging Distributed Systems
Challenges and options for validation and debugging


Sachin Date - Should You Upload or Ship Big Data to the Cloud?
The accepted wisdom does not always hold true.



Comments

(newest first)

Elios | Sat, 07 Nov 2015 09:29:52 UTC

Hi Andrew,

Thanks for the nice post. That's a great sum-up of problems in the design and implementation of distributed low latency systems.

I'm working on a distributed low-latency market data distribution system. In this system, one of the biggest challenge is how to measure its latency which is supposed to be several micro seconds.

In our previous system, the latency is measured in an end-to-end manner. We take timestamp in milli seconds on both publisher and subscriber side and record the difference between them. This works but we are aware that the result is not accurate because even with servers having clock synchronized with NTP, users complain sometimes that negative latency is observed.

Given we are reducing the latency to micro seconds, the end-to-end measurement seems to be too limited (it should be better with PTP but we can't force our users to support PTP in their infrastructure) and thus we are trying to get a round-trip latency. However, I can see immediately several cons with this method :

- extra complexity to configure and implement the system because we need to ensure two-way communication. - we can't deduce the end-to-end latency from the round trip one because the loads on both direction are not the same. (we want to send only some probes and get them back)

Do you have some experiences on the round-trip latency measurement and if so could you please share some best practices ?

Thanks a lot, Helios


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.