Hi,
I'm currently working on a Java project that involves a whole lot
of multi-threaded infrastructure. I'm currently running into a strange
problem with trying to sleep a thread.
First, Hardware:
- ABit BP6, with two Celeron 366s overclocked to 516Mhz
- 512M of RAM
- Linux 2.2.14-1.3.0 (built with config changes from RH src.rpm
I've tried it with two different JVMs: IBM's 1.1.8 JVM which uses native
threads (i.e. one Java Thread==one native Thread) and Sun's 1.2.2 JVM
which uses green threads (i.e. fake threads, many java threads==one native
process/thread).
The problem in my software that I am trying to diagnose is whether I am
hitting architecture limits in the way I designed my software or hardware/OS
limits in the ability of my machine to handle the threading/scheduling.
The way I test this is by controling how fast my EventGenerator tool generates
events into my architecture. When I see the performance of my event handling
change with increases in my event generation "latency", I know that I am
maxing out my system's ability to handle the overall architecture.
Which brings me to my problem:
Time in milliseconds before and after a Thread.sleep call, using 5 millisecond
sleep value, IBM JDK native threads ...
955643952450/955643952470
955643952471/955643952490
955643952490/955643952510
955643952510/955643952530
955643952530/955643952550
955643952550/955643952570
955643952570/955643952590
955643952590/955643952610
955643952610/955643952630
You'll see an average time of 20 millseconds to print the time in milliseconds,
call sleep(5) and then print the time in ms again.
But now with a pause of 4 milliseconds, same VM ...
955644044605/955644044605
955644044605/955644044605
955644044605/955644044605
955644044605/955644044605
955644044605/955644044605
955644044606/955644044606
955644044606/955644044606
955644044606/955644044606
955644044606/955644044606
955644044606/955644044606
955644044606/955644044606
955644044606/955644044606
955644044607/955644044607
Note that there is no pause or latency (at least at the millisecond level) between
the two print statements.
Now, we switch to JDK 1.2 (green threads), five millisecond sleep value ...
955644162761/955644162770
955644162770/955644162780
955644162781/955644162790
955644162790/955644162800
955644162801/955644162810
955644162810/955644162820
955644162821/955644162830
955644162830/955644162840
955644162841/955644162850
You'll notice that the latency for the whole print-sleep-print is now down to 9-10ms.
Now, the JDK 1.2 (green threads) with a four millisecond sleep value ...
955644239451/955644239460
955644239461/955644239470
955644239470/955644239480
955644239481/955644239490
955644239491/955644239500
955644239501/955644239510
955644239511/955644239520
955644239521/955644239530
955644239531/955644239540
955644239541/955644239550
955644239550/955644239560
955644239560/955644239570
Same latency as the 5 millisecond sleep call. So the overhead involved with sleeping and
waking up is still large enough to not affect the overall latency.
If we continue decreasing the sleep value, we see that the 9-10ms latency
for the sleep() call continues, all the way to 1 ms. At 0ms (where we cut out
the sleep call with an if/then/else) we go to no latency (at least at the ms
resolution).
So, after all that information, what's my question?
1) Well, is the Linux threading architecture up to this kind of stuff? I
remember seeing IBM post about the fact that the scheduler needs work
in order to get a better threading architecture in place (i.e. one
that can support a many-to-many relationship).
2) Is the behavior I'm seeing simply the limitations of the linux
threading coming out? Why can't the thread seem to sleep when I call
a sleep of less than 5ms? Is there something strange going on in the
native threads that would make them not respond to the sleep call?
3) And ... is this just a java problem? Before you jump on this
and say, "YES, YES, YES! For the love of God YES!" I did manage to get
some late night access to a friend's Ultra Sparc 2 (it has two processors)
and running the same application there experience NO problems and
performance was stunning.
4) Is this a hardware problem? I.e. despite being proud of my little
setup, is it still not enough to support this application?
TIA,
Matt
P.S. If there is another/better forum to post this to, please let me
know.
-- ---------------------------------------------------- Matt Luker r e d s t a r h a c k e r s geek marine your source for programming 781.255.5781 know-how kostya@redstarhackers.comWWW: http://www.redstarhackers.com PGP: http://www.redstarhackers.com/keys/kostya.pub ----------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:22 EST