I think that we have diagnosed the problem.  It is a runaway process.  The name of the process is timidity, which is a midi player.  One solution is <br><br>ps -A | grep timidity<br><br>then <br><br>kill [PID for timidity]
<br><br>Thanks for your thoughts, Jim!<br><br><div><span class="gmail_quote">On 9/24/07, <b class="gmail_sendername">jim stockford</b> <<a href="mailto:jim@well.com">jim@well.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>here's how i understand attacking the problem:<br>* watch network traffic to see if the network is overloaded.<br>* watch workstations/chubby-clients to see where the CPU is working<br>* watch the server to see where the CPU is working
<br><br><br>On Sep 24, 2007, at 4:09 PM, Christian Einfeldt wrote:<br><br>> hi<br>><br>> Here is the next issue for our public middle school project. And it<br>> is actually part of a recurring theme, it seems: why is our linux lab
<br>> lagging, when most people think that it should be able to handle what<br>> we are throwing at it. My question is fairly long to explain, but<br>> simple to summarize: why are we experiencing delays in playing music
<br>> compositions using GNU Denemo under Edubuntu over a GB network that<br>> should be performing better, and what can we do to solve the problem<br>> without spending any money?<br>><br>> As most of you know from reading this list, I am a volunteer
<br>> supporting a public middle school with FOSS. We have a brand new dual<br>> core server with 2 GB of RAM whose only purpose in life is to support<br>> 24 chubby clients running edubuntu. The thin clients have at least
<br>> 256 MB of RAM, and most of them have swap space on their hard drive<br>> also, although some of them are true thin clients in that the hd has<br>> no swap and is basically a vestige. I am told that we have a gigabyte
<br>> network. The server feeds the signal to the first 18 clients through<br>> one GB switch, and then that switch feeds another identical switch<br>> with services about 6 more clients.<br>><br>> Our problem is that when we use GNU Denemo to play the short little
<br>> compositions that the students write in class, we can have only one<br>> student play his / her composition at a time or the system is choked,<br>> meaning that it lags. More specifically, all of the students find
<br>> that their GNOME desktops are almost completely non-responsive to the<br>> mouse. The mouse still moves, but programs launch very slowly for<br>> about 5 mins, at which time the choke point is presumably cleared, and
<br>> then one student can again play his / her composition. It might be<br>> possible for, say, 2 students or maybe even three students to play<br>> their music; but we don't know where that stress point is.
<br>><br>> And, in some ways, it doesn't even make sense to slowly add students<br>> and have them play music, simply because some people who have heard of<br>> this problem in passing furrow their brow and say that we shouldn't be
<br>> having these problems.<br>><br>> We are, of course, going to be trying to get more RAM in the clients;<br>> and swap for all of the clients; and we have thought of running GNU<br>> Denomo natively on each of the clients by booting them as stand alone
<br>> work stations.<br>><br>> For those of you who are familiar with the school, you can stop<br>> reading here, because what follows is basic data about the school, and<br>> you probably don't need to read it again.
<br>><br>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><br>><br>> This inner city school has absolutely no budget for a real tech
<br>> support person, and all of the teachers already are at work by 6:50<br>> a.m., and they usually stay until 6:30 p.m., and then each of the<br>> teachers is expected to be available to field phone calls at home
<br>> until 8 p.m. All of this might sound kind of drastic, but our<br>> students typically come to this school of 290 students<br>> under-performing their grade level by 2 grade levels, but leave the<br>> school as 8th graders typically performing at or above grade level.
<br>> Seventy-five (75%) of our students come from households below the<br>> federal poverty guidelines. 65% of our students are African American;<br>> 17% are Latino; 10% are Asian; and 8% are Caucasian. Despite the life
<br>> challenges facing our students, last year our students tested in first<br>> place (as a student body) based on standardized testing. So this<br>> school is succeeding in many ways, but they are really struggling in
<br>> terms of technology, and that is all because of funding shortfalls.<br>><br>> Coincidentally, the students spend no time here on Windows boxes,<br>> except for occasionally random Internet browsing on a teacher's
<br>> Windows box. But that is the exception, because, as you can imagine,<br>> the teachers don't want the students accessing their computers. So<br>> when the students are not in the lab, they are using PClinuxOS boxes
<br>> in several of the classrooms to do their Internet research.<br>><br>> Overall, this school is making miracles with no funding. I am hoping<br>> to move the whole school to FOSS eventually, but of course there is
<br>> still a lot of work to be done. Thus far, the music teacher is fairly<br>> impressed with the ability of students to compose music on GNU Denemo,<br>> but she would just like to be able to have all of the students listen
<br>> to their compositions at the same time. Typically, these compositions<br>> are no more than, say, 6 or 10 bars long, just enough to get the<br>> students familiar with the basics of scales, rests, note duration,
<br>> tempo, beat, etc. Just the basics.<br>><br>> Thanks in advance for the help.<br>><br>> --<br>> Christian Einfeldt,<br>> Producer, The Digital Tipping<br>> Point_______________________________________________
<br>> sf-lug mailing list<br>> <a href="mailto:sf-lug@linuxmafia.com">sf-lug@linuxmafia.com</a><br>> <a href="http://linuxmafia.com/mailman/listinfo/sf-lug">http://linuxmafia.com/mailman/listinfo/sf-lug</a><br><br>
</blockquote></div><br><br clear="all"><br>-- <br>Christian Einfeldt,<br>Producer, The Digital Tipping Point