[zeromq-dev] Formally modelling the publish-subscribe pattern

John Lång john.lang at mykolab.com
Wed Nov 4 09:29:42 CET 2020


Hi Brett,

Thanks again for your answers!

About HWM, do you think it would make sense assuming a HWM of 1 in the 
model? I think HWM 1 would be the worst case scenario where messages are 
most likely to be dropped. HWM 1 would mean that there can be only 
either one small or one large message in transit at a time. If the 
system satisfies (at least safety) properties in such harsh environment, 
then these properties must also hold when HWM is increased, right? 
Increasing HWM in the model would increase the size of the state space 
exponentially, if I'm not mistaken, and I already have many other 
parameters causing exponential growth. (Last time I tried, 2 TB of RAM 
wasn't enough for simulating even three messages.)

I'm not verifying real-time properties such as latency. These will have 
to be estimated through empirical trials.

Cheers,
John

Brett Viren via zeromq-dev kirjoitti 3.11.2020 klo 18.53:
> Over what bandwidth?
It's hard to estimate the actual numbers in production, but in 
simulations we've achieved data rates around 50 MB/s. Our network 
bandwidth is 10 Gb/s, so 50 MB/s (i.e. 400Mb/s) isn't even near the 
saturation point. We should have plenty of safety margin for our 
application. (This safety margin maybe even as high as 100-1000 times 
the current measured average throughput of the system, but the system is 
being upgraded and the data flow is expected to increase substantially.)
> My own tests at 100 Gbps bandwidth found zero copy less important than
> other things and these other things bring their own problems.
In retrospect, our solution might be unnecessarily complicated. We 
didn't know in advance what level of performance we'd get when designing 
the system. We've put hundreds of hours of work into our simulations so 
we're not going to change the system design anymore at this point. Also, 
there's a deadline approaching. Hence, I'll just have to endure my 
zero-copy approach.


More information about the zeromq-dev mailing list