Hi Martin,
On Wed, Jun 9, 2010 at 12:09 PM, Martin Sustrik wrote
> I believe the "send_requests" is the initial node of the pipeline. It
> produces request. Down the stream there's arbitrary number of
> "component"s which do the actual processing and generate replies.
> Further down there's "rec
other than zmq_sleep and zmq_stopwatch being missing in 2.0.7 i ran
into another problem
in receive_replies.cpp, line 65 should declare a variable sync
containing an empty message.
ex.
zmq::message_t sync;
out_socket.send (sync);
right now i think its sending the address of the sync syscall ?
wi
> I believe as long as the operations are serializable, you can roll
> them up across multiple endpoints, depending on your consistency (as
> in eventually) you can use source sequencing or clock vectors with a
> resolution protocol.
Definitely — in a lot of cases, you can do some post-proce
> Ok. I see. So basically, you want messages to be load-balanced by 0MQ
> but at the same time ensure that all messages with a particular
> "subject" (whatever that means) go to the same downstream component.
Yep, that's the behavior we need — though I should say that I'm not
necessarily asking
On Jun 21, 2010, at 10:34 AM, Martin Sustrik wrote:
> Douglas,
>
>>> Does that mean you have a cluster of components that processes
>>> requests
>>> of type X, another cluster that processes requests of type Y and
>>> so on?
>>
>> Not really, I think. Here's a simplified picture:
>>
>> +---
Douglas,
>> Does that mean you have a cluster of components that processes requests
>> of type X, another cluster that processes requests of type Y and so on?
>
> Not really, I think. Here's a simplified picture:
>
> +--+ +-+
> | Read from DB |>| Sum |+
> +---
Michael,
> I've never seen this kind of latency for 1KB messages, but then again I've
> only used 0MQ on Linux. I don't have access to a system with a real-time
> kernel, but I'd be willing to try to duplicate the raw buffer comparison
> tests on Linux w/ Ethernet and 20Gb Infiniband. It will be
> Does that mean you have a cluster of components that processes requests
> of type X, another cluster that processes requests of type Y and so on?
Not really, I think. Here's a simplified picture:
+--+ +-+
| Read from DB |>| Sum |+
+--+ +-+|
ZeroMQ Raw Buffer 170 usec
>
> This seems bit too high for 1kB messages. Even on lousy kernel like
> Windows I wouldn't expect it to be more than ~75us. Is anyone seeing
> this kind of latency (170us?) If so, it should be considered a
> regression IMO.
>
> Martin
I've never seen thi
Peter,
>> Btw, one thing that would be worth implementing in the scheduler IMO are
>> priorities. That way you would be able to say: load balance the work
>> among components A, B and C and only if none of those is available use
>> component D (which may be off-site or too expensive etc.)
>>
>
>
Hi Martin,
On Sat, Jun 19, 2010 at 3:11 AM, Martin Sustrik wrote:
> Peter Alexander wrote:
>
>> The first is a very flexible, even autonomous load
>> distribution/balancing scheme(s) that take into consideration various
>> aspects of distributed pipeline processing like the distribution of
>> com
Brian,
>> I'd like to suggest that ZeroMQ adopt "semantic versioning"
>> (see http://semver.org/ ) when the 2.x API settles down and the first stable
>> release is made. (v2.1.0 perhaps?)
Yes. That was the idea. The versioning is supposed to copy the library
versioning which AFAIU is the same as
Hi,
>>> ZeroMQ Raw Buffer 170 usec
This seems bit too high for 1kB messages. Even on lousy kernel like
Windows I wouldn't expect it to be more than ~75us. Is anyone seeing
this kind of latency (170us?) If so, it should be considered a
regression IMO.
Martin
_
13 matches
Mail list logo
