0MQ: The Intelligent Transport Layer
Mike Fitzpatrick
fitz at noao.edu
Tue Dec 27 10:15:41 PST 2011
On Tue, Dec 27, 2011 at 10:49 AM, Rob Seaman <seaman at noao.edu> wrote:
> Hi John,
>
> > I'd certainly be surprised if scalability were an issue: 2e6 events at –
> say – 10 kB event is only 20 GB, or about 0.5 MB/s over 12 hours. That sort
> of rate does't sound worrying at all.
>
> End-to-end latency is also a key issue. We should bear this in mind when
> any benchmarks or data challenges are performed.
Indeed, the math isn't that simple and much depends on how the LSST events
are deployed. Forgetting even the inefficiencies of sending many small
packets
the above calculation only applies to streaming the whole 20GB.
Assuming these events are distributed from Chile, the current network
latency is
~250ms, and the vTCP requires at least one round-trip to message to complete
delivery. For 2e6 events sent one at a time the latency alone makes this
transfer
on the scale of 1-2 weeks (i.e. at best you could send 3-4 events /
second).
Although the network capacity to/from Chile will improve dramatically by the
time LSST starts running, I'm not sure the latency will improve as
dramatically.
Secondly, vTCP couldn't be used as-is for bulk transport since there is a
32-bit
limit on the byte-count that couldn't accommodate 20GB of events (but could
presumably for ~10K events per LSST 'visit' sent every few minutes).
Distributing
2e6 events from someplace other than Chile still begs the question of how to
do the bulk transport to a better-connected location and what tweaks to vTCP
would be required. Lastly, no comment has been made about how an event
packet is sometimes the start of a cascade of other packets (requests for
references from repositories, follow-on packets, etc), so the actual numbers
flowing through the "system" may be more than 2e6 / day.
vTCP is fine for authors and end-delivery of single packets, but my own
opinion
is that something more structured is required for bulk transport,
repository replication,
SEAP service requests, etc to operate a real backbone network and federated
repositories. Sorting that out is the job of the VOEventStream and
VOEventServer
docs.
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20111227/26bfecdb/attachment.html>
More information about the voevent
mailing list