Threading / Polling question (Linux, JDK 1.5)

[James Kimble]

I'm trying to write a method to poll a quasi-real time system for
various data via UDP. What I need to do is send 10 different messages
over a period of 10 seconds with each message send operation separated
by 1 second. The system then responds on another UDP port.

The orignal programmer had a method that simply had a counter for
each message. The method was called from an infinte loop. Each message
had a count to wait for and would then be sent. A sleep of 10 seconds
was then called after all messages had been sent. This created some
issues with some messages being sent vertually on top of each other
and others being sent at too long an interval. I wanted to do something
much more predictable and maintainable.

I created a method that sends a message, does a "this.sleep(1000)",
then sends the next message and so on. Because there are 9 different
messages this gives me just the messaging rate I want. Unfortunately it
also seems to take my system load (according to top) to a level of 3.8
to 4.5 where the previous method was down around 1.9 to 2.5. System
load is critical to this system (quasi-real time).

Can anyone suggest the best method for doing what I'm attempting while
keeping system load as low as possible? Can anyone explain why a number
of sleeps would drive sytem load so high?

Any help greatly appreciated.

James Kimble

 

[Wibble]

I'm trying to write a method to poll a quasi-real time system for
various data via UDP. What I need to do is send 10 different messages
over a period of 10 seconds with each message send operation separated
by 1 second. The system then responds on another UDP port.

The orignal programmer had a method that simply had a counter for
each message. The method was called from an infinte loop. Each message
had a count to wait for and would then be sent. A sleep of 10 seconds
was then called after all messages had been sent. This created some
issues with some messages being sent vertually on top of each other
and others being sent at too long an interval. I wanted to do something
much more predictable and maintainable.

I created a method that sends a message, does a "this.sleep(1000)",
then sends the next message and so on. Because there are 9 different
messages this gives me just the messaging rate I want. Unfortunately it
also seems to take my system load (according to top) to a level of 3.8
to 4.5 where the previous method was down around 1.9 to 2.5. System
load is critical to this system (quasi-real time).

Can anyone suggest the best method for doing what I'm attempting while
keeping system load as low as possible? Can anyone explain why a number
of sleeps would drive sytem load so high?

Any help greatly appreciated.

James Kimble

This sounds like an artifact of the way load is calculated, rather than
an increase in actual work. Your doing work every second, where the old
version did work every 10th second. The amount of work would be the
same, as would be the amount of sleeping.

 

[John C. Bollinger]

I'm trying to write a method to poll a quasi-real time system for
various data via UDP. What I need to do is send 10 different messages
over a period of 10 seconds with each message send operation separated
by 1 second. The system then responds on another UDP port.

The orignal programmer had a method that simply had a counter for
each message. The method was called from an infinte loop. Each message
had a count to wait for and would then be sent. A sleep of 10 seconds
was then called after all messages had been sent. This created some
issues with some messages being sent vertually on top of each other
and others being sent at too long an interval. I wanted to do something
much more predictable and maintainable.

I created a method that sends a message, does a "this.sleep(1000)",
then sends the next message and so on. Because there are 9 different
messages this gives me just the messaging rate I want. Unfortunately it
also seems to take my system load (according to top) to a level of 3.8
to 4.5 where the previous method was down around 1.9 to 2.5. System
load is critical to this system (quasi-real time).

Can anyone suggest the best method for doing what I'm attempting while
keeping system load as low as possible? Can anyone explain why a number
of sleeps would drive sytem load so high?

The java.util.Timer class may be useful to you for this sort of thing.
After all, that's what it's for. I don't know how it will compare on
system load, however.

 

[Patricia Shanahan]

I'm trying to write a method to poll a quasi-real time system for
various data via UDP. What I need to do is send 10 different messages
over a period of 10 seconds with each message send operation separated
by 1 second. The system then responds on another UDP port.

The orignal programmer had a method that simply had a counter for
each message. The method was called from an infinte loop. Each message
had a count to wait for and would then be sent. A sleep of 10 seconds
was then called after all messages had been sent. This created some
issues with some messages being sent vertually on top of each other
and others being sent at too long an interval. I wanted to do something
much more predictable and maintainable.

I created a method that sends a message, does a "this.sleep(1000)",
then sends the next message and so on. Because there are 9 different
messages this gives me just the messaging rate I want. Unfortunately it
also seems to take my system load (according to top) to a level of 3.8
to 4.5 where the previous method was down around 1.9 to 2.5. System
load is critical to this system (quasi-real time).

Can anyone suggest the best method for doing what I'm attempting while
keeping system load as low as possible? Can anyone explain why a number
of sleeps would drive sytem load so high?

Any help greatly appreciated.

James Kimble

Can you get at paging and cache statistics for the processor?

One possibility is that there is an overhead, such as cache misses, for
sending the first message of a block. The old form of the program paid
that overhead once every ten seconds. The new form pays it once per second.

If that is what is happening:

1. The effect will be smaller on an otherwise idle system than on one
that is running other work.

2. Some statistic such as cache misses would be significantly higher for
the new program than the old one.

Patricia

 

[James Kimble]

Yeah, I'm going to try that. I don't think it will help with my loading
problem but who knows. This is very strange though.

Thanks for your help

 

[James Kimble]

There's definately something weird going on. It's been suggested that
in freeing up the system from messaging I'm opening it up to work on
things that consume more CPU cycles. This sounds very counter to
how I would expect things to work though.

I need to get some metering in place or a good monitoring tool and
see where the cycles are going.

Thanks for your help,

 

[James Kimble]

That's an interesting thought. I've had someone here suggest something
similar. I think it's time to get a monitoring tool and see where all
these
cycles are going.

Thanks for your help,

 

[Harald]

had a count to wait for and would then be sent. A sleep of 10 seconds
was then called after all messages had been sent. This created some
issues with some messages being sent vertually on top of each other
and others being sent at too long an interval. I wanted to do something
much more predictable and maintainable.
I created a method that sends a message, does a "this.sleep(1000)",
then sends the next message and so on. Because there are 9 different
messages this gives me just the messaging rate I want. Unfortunately it
also seems to take my system load (according to top) to a level of 3.8

There was a time when --- in the Linux kernel --- short sleeps where
actually idle waits because consistently yielding the processor for
the requested time was technically impossible. Maybe there is a
similar issue here --- although 1 second is not really a short time.

The other possibility: Your previous implementation called sleep only
once. Now you call it 10 times.

Harald.