Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Television

Journal: The unfriendliness of Digital Cable Tuning Boxes 3

Journal by codegen

For various reasons, I finally subscribed to digital cable. I won't be watching
TV that much more, but my sister will be staying with me for a period of time.
I only have a regular 27" TV, and thus we now have a digital cable tuner box.

My biggest peeve is that there doesn't seem to be any way to get it to skip
the channels that I do not subscribe to. Since there are a large number of such
channels, the channel up down key becomes useless once you leave the block
of common everyone channels. Similarly the program guide always displays
all of the channels and there doesn't seem to be anyway to limit it to display
only the channels that are subscribed.

Since my existing TV and VCR have the ability to skip channels, it seems
to me that I have taken a step backwards in usability.

User Journal

Journal: Gripe about electronic alarms....

Journal by codegen

I just got back from buying an alarm for my sump. The basement was flooded as part of hurricane Frances. The contractors are finally getting around to my house. The alarm I just bought was shrink wrapped and after opening it, I've discovered that it is useless (I was worried it might be when I bought it). At this point I'm assuming that the device is functional, but I can't hear it.

I have a hearing problem. At most normal pitches (i.e. conversation), my hearing is only moderately affected. But at the higher pitches, the loss is greater than 90dB. As a result I cannot hear watch beeps, most cell phones and most alarms. In my previous place of employment, I had to arrange for a co-worker to notify me if the fire alarm went off (The building had several false alarms while I worked there). It took me some time to find a fire and CO alarm that buzzed in the lower frequencies for my house. Needless to say, they were more expensive than the more common alarms. Fortunately the University where I work uses lower pitched fire alarms (with visual signals).

Most aquired hearing loss starts at higher frequencies. With the general increase in hearing problems in the general public, including that of Music or Noise Induced Hearing Loss, one would think that it would practical to make some adjustments in safety devices. Just because that 95dB piezo buzzer is cheaper doesn't make it safer if a significant portion of society can't hear it when it goes off.

User Journal

Journal: The long saga of using Linux to teach an OS Course Part III

Journal by codegen

The lab for my OS course is moved to a new building that is just being finished. The good news is that the new lab will have updated equipment. I've been using 350 MHz PIIs in the lab running Windows 2000 Pro. The new lab will have 2.4 GHz PIVs runing XP Pro. I'm looking forward to the upgrade. Construction is behind schedule: it is July and the lab is still not finished. We decide to run a test in one of the other labs that is complete.

If I though the first time we ran was a disaster this is even worse. We try and boot 20 VMs from one server and only three come up successfuly. The other 17 corrupt their hard drives. The extra load of booting at 2.4GHz is too much of a strain on the servers. We bring in some other techs to help and after running diagnostics we determine the problem is on the server end. The servers are closing connections because of the load. We spend time looking for some parameter that we can change. To be fair, there probably is some parameter somewhere that we can change, but we don't know what it is, and we can't find it when searching docs and the net. We find a reference to a timeout value in the registry for Windows NT, but changing it in Windows 2000 Pro doesn't seem to make a difference.

One of the techs is managing a Linux server (dual 500Mhz) that is running Samba. It is on the other side of campus (over the campus backbone) and latency may be a problem, but we decide to try it anyways.

Wow!! This is the fastest I have ever seen the lab come up. All virtual machines boot without error. We decide to install Debian on one of the servers to see what happens.

Debian Sarge installs without incident, but we have to download binary drivers for the raid card in the machine. They install without problem. We run the test in the lab and again we have success. Maximum load average while 20 client virtual machines boot is in the mid 7's. After the clients are booted load average drops to less than 0.2 (after all the clients are idle). This is with a straight install and no tweaking!! Non of the clients have any problems with mangling the virtual drives.

I also have to update the version of the kernel being used in the virtual machines. While the 6.2 still works, there were problems last year with students installing at home. It seems that the Redhat installer has problems with PIVs. If an existing image is booted on a PIV, there are no problems. The problems are with the installer itself. This is not surprising since 6.2 predates the PIV.

However, Linux has grown. Mostly the X environment has grown. I still want to keep the image to 500MB if possible to keep the network traffic down. While the lab boots faster with Linux on the server, it still takes time, and the longer the students have to wait, the less time they have in a 2hr lab. I try recent versions of many of the main distributions. The problem is that most of them have compiled the X server with all of the options and bundled most of the clients to gether so that it is impossible to get an install that includes X inside of 500MB. The only mainline distributions that I try that work are Debian Woody and Slackware 10. In both cases, the X window manager is fvwm2, since both KDE and Gnome have long outgrown 500MB. The installations leave about 80 MB free for the students use.

While I like Debian Woody, there is one problem that puts it out of contention. The boot picture is a penguin drinking beer. True, it can be turned off by booting without the framebuffer, but if I am going to distribute it to the students so they can install it at home, the default install will be a problem. My university is a well known international institution, with students from all over the world. There are several religions that take offense at alcohol. My class is a core class, required for the degree program. From a professional and ethical standpoint, this is a problem.

You think we would have learned. While we booted all of the machines at once, (three of us ran around 20 machines starting all of the virtual images), we did not try to transfer files to the main lab file server from more than one machine at a time. The lab does not have a printer. Students work in the lab and then download the files at home to print, or got to a central lab that has a printer. So students ftp from within the virtual machine to the lab server to store the files. In the past there was no problem. However, when installing on the new lab, the techs installed using an option which allows the VM direct access to the host ethernet card. Since we use an imaging process to push the software out to the lab, all of the VMs use the same MAC address for the card.

So they all get the same IP address from the DHCP server. So a single machine can ftp to the main server, but multiple students cannot ftp to the server at the same time. It does not affect the boot since the VM access the HD image file through SMB on the underlying XP OS which uses the ethernets card native MAC (and statically assigned IP address). Switching to NAT mode for the VM solves the problem. There were also some minor problems with the security profile, but all kinks seem the have been worked out.

So now it seems we finally have a functional Linux lab for the OS course. The students write their exam next week and hopefully next year will proceed without technical glitches

User Journal

Journal: The long saga of using Linux to teach an OS Course Part II

Journal by codegen

Fast forward ahead to the next summer. The rest of the class has gone reasonably well, with only small problems having to do with the students learning C during the Class, and the fact that one TA and a Prof is not enough support for 80 students working on a lab.

Now it is time to try and track down the network gremlin that is trashing the Virtual Disk files. To recall the setup, we have 20 PCs running Windows 2000 Professional connected by windows file sharing to a server running Windows 2000 Server. Each account on the server has a copy of the virtual PC hard disk with Red Hat 6.2 installed on it. Each client machine is running virtual PC and using the file as a virtual disk. When 20 virtual machines are started off a single server at once, some of the virtual disk files (avg 2) become badly corrupted. For example, some of the the contents of a configuation file from /etc are found in the middle of the /bin/sh binary file.

I write a small C program that runs under windows that just opens a 500 MB file and does random seeks followed by reads in the file. This is to be a rough simulation the behaviour of the Virtual Machine as it accesses various files on the virtual disk. The file consists of consecutive binary integers (4 bytes), so we can tell if the seek and read is successful. No writes are done so the file will not become corrupted. It also prints out status continously as it operates.

Weird. I was expecting that when we start the C test program on 20 machines accessing 1 server, that we would get an occasional error from several individual machines. We start up the 20 machines and they are running rather slowly (20 machines doing random seeks and reads means lots of head motion on the disks). No errors so far. Then suddenly, one machine starts running full speed printing status lines, all of which are errors. It is as if it has lost the connection to the server! The master image for the lab workstations is updated with the latest Windows 2000 Pro patches and the lab is reimaged. Running the test produces the same results. Several attempts are made to change settings on the server and client, but nothing works. We are running out of time before the fall term starts, so we decide to manage the problem. Start only 10 machines at a time (TA's control who starts up the VMs and when during the lab). This works with only a few cases of corrupted drives the next term.

to be continued

User Journal

Journal: The long saga of using Linux to teach an OS Course

Journal by codegen

Several years ago (Summer of 2002), I decided to move from using java threads to linux for the labs in my operating system course. The idea was (and still is) to give a more hands on approach to the labs. Previous years labs had done the standard producer/consumer problem in Java Treads, simulate scheduling algorithms, simulate VM replacement algorithms, etc.

The one problem is that the labs at my university were mostly windows based, and even if they were linux based, the students would have to have root access to install modules. The other problem was server disk space. If this was to work, each student would have to have thier own virtual disk (minimum 500M perstudent). The upgrades to the main lab servers were not in the budget. The servers were from a commercial vendor and the proprietary disks were much too expensive on a per gigabyte basis. After pricing both vmware and connectix virtual PC (now owned by Microsoft) for bulk academic purchases, We obtained some curriculum development money and purchased:

  1. Two Dedicated Servers for the class(1 GHz PIII, Raid 5 cards, Windows 2000 Server, 5 40 GB Drives). While I would have prefered Linux and Samba (More on that latere). I was not the one maintaining the servers, nor did I want to be. I have enough to do with teaching the class, managing TAs and Marking Exams. (As well as trying to keep up on my own research). The techs installing and maintaining the servers prefered windows.
  2. 40 copies of Virtual PC for the machines in the Lab.
  3. Funding for a 3rd year student for the summer to evalutate the approach (before Servers and Licences were prurchased) work out the bugs, and prepare two years worth of labs for the class. Some of the labs contained code skeletons to guide the students in writing the code. That is, files with some of the boilerplate code such as proc structures or device file operation structures already in place. This would allow the students to focus on the purpose of the lab and not get bogged down in some of the nuts and bolts to make it happen.

The evalutation went well. We used Red Hat 6.2 (older kernel) and were able to come up with 10 labs that would be suitable for a 3rd year OS class. Two of the reasons for using an older kernel was that that we could build smaller virtual disks (500M) and the kernel modules were simpler to write. The assignments ranged from introductory modules that created /proc files that read the clock, to more sophisticated modules that report on scheduling or virtual memory management within the kernel to a software device driver that managed kernel data queues (essentially a kernel pipe).

Based on the evaluation we decided to go ahead with the project. The servers were bought and installed. A base Virtual HD image containing the skeleton file was generated and copied out to all of the accounts. Tests were run and the first lab approached (Fall 2002). The student who work on the labs over the summer agreed to stay on as the TA during his 4th year studies.

Disaster. With only a couple of techs and one professor and one student, several tests had been run, but only a limited number of clients were run at a time (about 10). We had 40 machines on the lab, with 2 servers, means 20 machines per server. It turns out an individual server could not handle the load of 20 virtual machines booting at once. Once the VMs were up and running, network traffic was low enough that there were no problems, but 20 machines booting at once was apparently too much for the network and server. About 2 of the VMs would corrupt the virtual disks under the load. This was totally at random and different machines would do it each time. Needless to say this was a bit of a shock to the students starting up the VMs (as well as to the instructor[me]). For the 4 students affected (2 per server) we quickly copied new VMs into their accounts and had them boot up again.

to be continued...

Hold on to the root.

Working...