[omniORB] omniorb/omnievents - How do I improve events/sec throughput

[Ian]

--- Alex Tingle <alex.tingle at bronermetals.com> wrote:

> Hi Ian,
> 
> Thanks for trying omniEvents. Sorry it's taken a couple of days to
> get 
> back to you. I've been busy.
> 
Alex,

No problem - less than 24 hours is a quick turn around in my book. I've
had paid for support take even longer!

> > Initially with the above setup I was getting a pretty low
> events/sec 
> > rate (<100
> > from memory).
> >
> > The I discovered CYCLE_PERIOD_NS. Knocking this down to 0 got me up
> to 
> > ~1300
> > events/sec. All other omniORB/omniEvents configs are as per a
> default
> > installation.
> 
> It sounds like you are using a single supplier and consumer. 

In my simple example at present that's correct.

> If you
> use 
> lots more, you'll find that you get more events/sec through the
> system 
> when you increase CYCLE_PERIOD_NS.
> 
> > But is it sensible to make CYCLE_PERIOD_NS = 0 ? Are there any
> gotchas 
> > looming
> > on the horizon if I do this.
> 
> It all depends on how many suppliers/consumers you have, and how 
> quickly messages need to be delivered. I suggest you experiment. If
> you 
> make CYCLE_PERIOD_NS=0, then performance might be worse in cases
> where 
> lots of suppliers & consumers are communicating on the same channel.
> 

In general I'm looking at using 1 channel per client/server pair.

> > I also notice that CPU usage is still only running at around 20% 
> > usage. I was
> > expecting the above to run the CPU flat out.
> 
> CPU use will be higher too with a fast cycle. You are using Linux 
> aren't you? 

Correct (kernel 2.6.8.1).

>One user who was on Solaris found that it was much easier
> 
> to soak up 100% CPU on Solaris than it was on Linux (2.4). At the
> time 
> Linux's threading was a bit crude, and unexpected 10ms sleeps were 
> keeping the CPU usage down.
> 
> > So is there some other omniEvent / omniORB parameter that is 
> > throttling my current
> > throughput.
> 
> omniEvents is not designed to give you maximum bandwidth between two 
> stations on a single channel. Instead it's designed to deliver
> messages 
> from many suppliers to many consumer with a certain maximum latency.
> 
> The idea behind CYCLE_PERIOD_NS is that you choose how quickly
> messages 
> must be delivered, and you then set CYCLE_PERIOD_NS to achieve that. 
> Most applications will have a requirement that says "A must respond
> to 
> B's trigger within Xms". You would then set CYCLE_PERIOD_NS to X/2
> (or 
> whatever).
> 

So I can expect more events/sec with multiple consumer/suppliers.
That's fine. That's what my final system probably needs. But at certain
times I still need a high rate (~1000/sec) between some consumer/server
pairs at their peak. With each posted event being the result of a
remote procedure call by the consumer ( so the eventchannel will never
overflow) - as per my simple test.

At 1300 event/sec I'm probably ok. Especially if you say that will
increase with multiple client/servers.

But I'm curious to know why my test isn't using 100% CPU usage. Is
there some omniEvent() or omniORB configuration/coding modification I
can make to get it to pass more events/sec in my simple test? 

If it's a rewrite of some major piece of code then I'll probably live
with it as is. If it's something I've simply missed in the
omniEvents/omniOrb documentation or my config then I'd like to try it
out.

Thanks again for the prompt reply.

cheers,

Ian



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com