Tuesday March 13, 2007
Tuesday March 13, 2007
FatCatAir site now live.
I've owned the domain fatcatair.com for several years but have never actually had a web site there. The intention was to have this site document the building of my Velocity among other things. Well I recently got a new laptop and that gave me the incentive to finally work on putting the website together. It is pretty crude at this point but it now has all of my construction photos with commentary. So at this point I'll probably not blog about the airplane builder here any more. For keeping up with the construction process you'll have to follow the work over there.
Mar 13 2007, 01:16:45 PM EDT
Permalink
Monday February 05, 2007 I've been working pretty steadily on the new airplane. I've got about 175 hours on it, only about 3325 to go. At this rate I'll be done in, ... well maybe I shouldn't really think about that. So yesterday I glued the center section spar in place. This spar is what the wings will eventually be bolted to.
| Here you can see the spar after it was glued. On each side you can see legs that go down to the floor. These were use to help shim the spar to get it level from left to right. The spar is also supposed to be plumb although since it isn't uncommom for the spar to have a little bit of twist in it you just split the difference on each side. Finally you need to make the sweep identical. In other words you measure from a point at the nose to the corresponding spot on each side of the spar (one of the outer bolt holes) and it must be identical. Because it is hard to do that measurement with a tape and be very precise I made a telescoping jig that rotated in a bolt at the nose.
|
|
You can see the end of it resting on the spar on the right side of the photo. In the belly of the plane you can also see the main gear hydraulic cylinder (the long black thing) along with a lot of my mess.
|
Here you can see me using that jig to measure to the center of the bold in the upper spar hard point. Behind the spar you can (barely) see that metal ruler is bolted to the back of the spar. There is an identical one bolted on the other side of the sparc. This is so we can check the level of spar from side to side. Just behind that is a web cam. I have one on each side of the loft that is capturing photos once every 5 seconds. Then I have software running on my (Solaris) server in the house that once every 5 minutes analyzes the photos and decides if there is any motion. If there is it keeps the photo with the most motion. When the plane is all done on X years
|
I'll be able to assemble a movie of me building the airplane in about a 1/2 an hour. That should be pretty funny. This also has the benefit of keeping better track of my work hours than I tend to do by hand. Also my wife can use one of the computers in the house to check and see if I've fallen off the edge of the loft yet.
|
In this photo you can see my neighbor Pat using the optical level to verify that the spar is level from side to side. As far as we could tell it was level to 1/16 of an inch in 12 feet. Unless I walked on the floor nearby :-)
For grins we put my digital level on the top of the spar to see what it read. Since the spar is by no means precision manufactured you can't really get the level right that way. However the reading was 0.0! I think it was mostly luck.
|
|
The final picture in the show is not so good. It's a picture of the nose gear doors open with the nose strut just jigged in place to see what it looks like.
|
I wasn't too happy with this because the door didn't open quite right. It's actually wide enough for the gear to rais and lower properly but you can see that the door on the left side of the photo is touching the fuselage. That's not good. So I ripped it all apart and re-did it all. This is one of the advantage off a fiberglass airplane. If you do something wrong you can pretty much repair it and no one can tell after the fact. In a metal airplane you prety much either have to buy new metal or live with the mistakes. I used a heat gun to soften the epoxy up and pulled everything all apart. On the next try I used hot glue to partially assemble it. I moved where the swing arm are glued into the doors and now the doors open farther and don't hit the fuselage. Much better. Too bad I didn't do it right the first time.
|
|
Feb 05 2007, 04:07:25 PM EST Permalink
So I had this plan to get my wife a neon sign for Christmas. We'd talked about getting some neon sign/artwork in the past but never got around to figuring out what we wanted or who would do it. Well I decided to do the FatCatAir logo in neon. So back in early November I got in touch with several sign makers trying to get an estimate on what it would cost. After weeks of pestering I finally got an estimate. It was at the high end of my limit so I told my wife that the present I was getting was for both of us so don't get me anything. She was only too happy to oblige.
Well after it taking so long to get an estimate it was pretty clear that I wouldn't get the sign for Christmas anyway. The estimate was it would be ready the first week of January. Well you know how estimates go. It didn't make it. In fact it didn't even make January unless last Friday was really January 33rd. So Friday afternoon I got a call that it was finally ready. So I quick drove over to the sign maker. The sign is 3 feet by 3 feet. I was pretty sure it would fit in the back of my Civic, at least until I got there. As it turned out it fit by about 1 inch. I was driving pretty carefully on Friday.
So Friday evening was the great unveiling. I had my wife go into the 1st floor bedroom and I turned off the lights except for the sign. Then my niece (who already knew what was coming) guided my wife out from the bedroom with her eyes covered and then the sign was revealed. She was pretty impressed. She was also sorry she never thought to do it herself. So without further ado here's a photo of the sign.
The cat isn't holding an airplane like in the real logo for two reasons. First the airplane would be so crude in neon (at this size) that it would mostly look like a blob. Second the current logo shows a plane that resembles my Tiger but once the Velocity is complete and FatCatAir switches its "fleet" to the new airplane, the logo will have to be updated. So my plan was to have my wife make a smal airplane in stained glass that we could attach to the sign. When the Velocity is done she'll just make a new version.
Thursday January 11, 2007 Well no one guessed the answer to yesterday's question as to why the benchmark ran so slowly. I had a couple of internal guesses and one external one. Azeem who used to work in the hotspot compiler group was pretty close. [I expect he might debate whether he was right...]
Truth is I didn't give you all the information but then it wouldn't have been that hard to guess. So the part I left out is what actually happens when we uncommon trap back to the interpreter? Well it depends on the situation to a degree because depending on the cause we want to take different actions. In this particular case the action we requested was to reinterpret for while. In that case we make the current compiled code dead and we reset the event triggers so we will recompile at a later point.
No in the server vm when we trap back to the interpreter we will collect more profile data. In the case that the benchmark presented we trapped because we hit a previously untaken path. In that case we will re-execute the brnaching bytecode and record that the previously cold path is at least more than stone cold.
So I had mentioned previously that in tiered the interpreter doesn't collect profile data. So trapping back to the interpreter won't record that the untaken path is now a possible, though improbable, path. Now since I wasn't thinking I had the tiered system when it tripped the counters for a new compile to always compile at the next level above where we compiled last, or at server level if we had gotten there. So in this case we go server code => interpreter server code.
So now you can see that maybe I was setup for a long set of cycles here since I didn't have a path that would mark the untaken path as taken. That would have been bad but in fact the formerly untaken path was actually still quite improbable. So although we could cycle here it was pretty infrequent so if nothing else had gone wrong the benchmark would have run slower but not as bad as what I was seeing.
Now it turns out that there were multiple uncommon traps happening in this same area of code. The site was a call site in java/util/Hashtable::get. So one of the important optimizations that happens is recognizing when a call site is monomorphic. In that case we can avoid the overhead of a virtual call and even possibly inline the target method. The profile data predicted that this call site was monomorphic. Since we can't rely on the site remaining monomorphic the compiler generates code that will uncommon trap if we find the wrong class. Now things are especially tricky here. Depending on the frequency of this we can do different thing. One thing we try to do is generate code for bimorphic call sites. If we see from the profile data that two classes will cover the site then a runtime test is inserted to chose and we can do non-virtual calls for both classes possibly inlining both targets. Similarly to the monomorphic case when we get a class we didn't expect we uncommon trap.
So as it turns out in running this benchmark the call site goes bimorphic after it has been running a while. Now remember the interpreter wasn't generating profile data. So when we'd trap out of the monomorphic case to go bimorphic we'd end up recompiling the case a monomorphic because the profile data never changed. Now this could really slow you down because this was a relatively hot path. But we have hueristics to cover this. What was supposed to happen was the compiler would detect that we were trapping at this particular point frequently and change its view of the call. Fortunately that trap counting was happening in the runtime system and not the interpreter so we did in fact see that we were trapping at this site with an unexpected class.
Now is where we ran afoul of the heuristics. There are throttling mechanisms that will prevent us from infinite trap/recompile cycles. If the system sees that it thinks that is happening it compiles the code to request that we no longer as for recompilations. We maybe seeing a lot of traps which is not good (in fact it may well be better to simply interpret) but at least we aren't also wasting cycles compiling constantly. What happened is I got caught by two competing hueristics. In order to have the trapping convert from monomorphic to bimorphic the compiler looks at the trap data per method . You might expect it to do it on a byte code index (bci) basis (we have that data too). I believe that because of races in how that data is collected and the recompile to go bimorphic we use the per method limit to give up on the optimization instead of the bci based data. However the decision as to what to do at the trap (for this particular type of trap) was on a bci basis and so we'd decide to not recompile on the traps before we'd give up and simply put a virtual call at the call site.
Once we decided not to recompile, the performance was doomed. We'd pretty frequently be trapping back to the interpreter and finishing the execution of the method. The cost of an uncommon trap is relatively high (they are supposed to be uncommon). So we ended up running even slower than what the interpreter alone would do.
Now here's one final thing about how odd this was. While I was tracking this down I was of course using the debug version of the vm. The debug version of the jvm has tons of assertion checking code. It's a lot slower. Actually we have two versions of the debug vm, fastdebug where the asserts are on, we optimize the c++ code and we generate symbol data for dbx/gdb. There is also the plain debug version where the c++ code is not optimized. Both of these vm versions easily out ran the normal vm. So why was that? Well the vm was slow enough that between the time we decided to compile the method and we actually got around to compiling it the call site went bimorphic. So the initial compile got it right immediately and we didn't uncommon trap at this spot at all. The fact that the vm was running slower than normal was completely overwhelmed by compiling this call site in the way that best suited the way the benchmark was running.
Wednesday January 10, 2007 So the tiered jvm is working pretty well but I want to see startup performance more on par with client. So I have to make some changes to try and help it out. So in the client vm the situation looks like this:
- Interpreter collects no bytecode based profile data but tracks invocations and backbranches on a per method basis. (Backbranches are used to trigger an OSR compile, invocations trigger normal compiles.)
- client compiler generates code that collects no profile data.
In the server vm the situation looks like:
- Interpreter initially collects invocation data and backbranch data on a per method basis. After a method heats up an object is created that allows collection of profile data on a bytecode basis. At this point backbranches counts are unique to the byte code index (aka bci, i.e. the index into a methods bytecodes).
- Server compiler generates code that collects no profile data. The compiler makes extensive use of the profile data. It is able to excise byte codes that based on the profile data are never executed. If we hit one of these expected to be un-taken paths there is code inserted to generate an uncommon-trap. This will cause us to execute in the interpreter again and collect more profile data.
In the tiered vm as it existed a few weeks ago the situation was:
- Interpreter collects no bytecode based profile data, ever. It works exactly like it was the client vm.
- The client compiler (initial tier) generates code to track invocation data and bci based profile data.
- Server compiler works just like it does in the server vm although the invocation count trigger point seems to be best around 35k instead of the server vm's 10k.
The initial theory was that client compiler code was going to be fast enough that collecting full profile data wasn't going to be that bad. I've done some benchmarking with Alacrity and it generally is too bad (10% or so) although there are a couple of benchmarks where the impact is pretty severe.
So in the server vm the interpreter runs in two modes the idea is to do the same for the client compiler and in effect add more tiers. Instead of a 3 speed transmission we go to 4 speeds to try and smooth out the startup performance differences I was seeing. Actually I've added an additional gear, the tiered system can actually create code that looks like:
- No profiling at all, just like in the client vm. Internally this is called tier1.
- Invocation counts and per method backbranch counting. This is called tier2.
- Invocations counts and bci based profile data. This is tier3.
Now the truth is that as I'm currently running the system I'm only using tiers > 1. The expectation is to use tier1 for special circumstances. For instance if someone find a method miscompiles at tier 4 (server compiler) we have a way to allow them to specify that method only reaches tier1. No sense in penalizing them further by collecting profile data we can't even use. Similarly there are methods that for various reasons (resource limits typically) the server compiler can't compile. In that situation we're better off using tier1 instead of being trapped in the interpreter like the current server vm is.
So I added all these tiers and I tried it out. It was pretty disappointing worse than the previous tiered system. It was clear that I was not able to control what compiles were happening and when. After some analysis it was clear what was going on. For various reasons the counters that are used for triggering compiles and for profiling information are partially shared. This was always a compromise at best in the other vms but in tiered I found that you just couldn't reason about how changes to triggering would influence my profile results. I really wanted triggering data to be separate from profiling data.
This was kind of scary. I wasn't the first hotspot developer to see that this overloading made for hard to predict changes in behavior. The current system has be tuned over a long time to get the kind of performance we want. No one wanted to mess with it for fear of spending inordinate amount of time getting the performance where we wanted with a saner system. Fortunately I'm not that smart so I'm changing it. :-) Actually I don't think I had much choice but it was nice to know that others found the counters not entirely rational.
So I split the triggering mechanism out completely. Pretty much immediately I got back to where I was with the initial tiered system and some benchmarks looked a little better. However I had one benchmark that used to run in 5.5 to 6.0 seconds that was now taking more than 400 seconds! What was up with that?
[ I know the answer to that question and I'll answer it next time. I've left clues as to what the problem is. See if you can figure it out. No prizes though... ]
Tuesday January 09, 2007 Over the holiday break I got some work done on the Velocity. Nowhere near as much as I hoped to get done but that is always the case. I've decided to work on the fuselage for a while instead of the wings/canard. It's a lot more assembly and much smaller fiberglass layups.
The very first thing you do is level the fuselage side to side and front to back. I have a cradle I built that has adjustable feet so it is pretty simple to adjust for level. The side to side level is pretty easy just use a long (6 foot) level and check (and mark) a few places on the flange. Front to back it a little more complicate since you have to use a water level (or an optical level /transit). The front point is a hole in the flange marked by the factory. The rear point requires some measuring. In any case I was happy in an hour or so.
The you have to mark the airplane centerline and well as the locations of the canard bulkhead, instrument panel and firewall. The instrument panel isn't particularly critical. The firewall and canard bulkhead are pretty critical. You want them plumb and also perpendicular to the centerline. You want to really sure that they are parallel to each other since the firewall has the spar for the wings mounted against and and the canard bulkhead positions the canard. You'd really like the wings and the canard to be parallel to each other.
I fussed with the placement of these parts for about 3 days before I was happy. I think they are as good as I can get them. Once you are happy you use structural adhesive to mount them in place (along with the gear bulkhead and gear pockets). That part went pretty smoothly.
Then I started working on fitting controls into the keel. The first thing to do is mount the upper aileron torque tube. This control stick gets mounted to the torque tube. Here you can see me sitting in the fuselage pretending I'm flying and making airplane noises.
This picture is sort of a tribute to Andy Millin who has a similar picture on his web site where he is building a Velocity too.
Jan 09 2007, 11:03:31 AM EST Permalink
Monday January 08, 2007
Tiered compilation - where is it?
It's about time I wrote about what I've been working on (although I've been getting requests for airplane building updates too). I've been trying to get the tiered jvm built as the standard vm to replace the server vm. My intention was to get the tiered system visible so we could get feedback on it sooner rather than later. In order to do that I needed to show that people wouldn't have a heart attack over performance. So as a result I'd been running benchmarks.
The good news is that using our internal benchmarking system (Alacrity) the server results were pretty much identical with the tiered vm as with the server vm. The client results which track startup performance weren't quite so good. Now that wasn't really bad for me because I only wanted to replace the server vm with the tiered vm at this point. In the future I want the client vm to go away too but given the state of the tiered vm it wasn't too surprising.
The Alacrity results for startup though were pretty bad so I spent some time investigating them. The suspicion of course is that now the the client compiler is generating code to track execution profiles that would explain it. So I built a client vm that would collect profiles via new switch(es) (switches because I wanted to see what different profile tracking code was the most expensive) and run the tests again. Well it definitely showed that this impacted client performance but to nowhere near the extent I was seeing with the tiered vm. The impact was pretty modest 6-10% or so for most things although there was one benchmark that was impacted pretty drastically.
So one other suspicion was that we didn't have code that allowed a thread that was execution a hot loop in client code to OSR (on stack replace) its way into server code. So I added that capability. That had no real impact. So although we'll need that capability at some point I didn't get anywhere adding that code.
The odd thing was that when I was running test locally on my workstation I wasn't really seeing the same kind of results that the Alacrity results showed. It finally dawned on me that the difference was probably class data sharing (CDS). The client vm supports class data sharing so that classes used during vm initialization are pregenerated when the vm is installed and later client runs can simply load the class data with a good bit less work. This helps startup time. The server vm because it uses a different garbage collector doesn't support CDS. Since when I work on the vm I rarely install it like a normal user would my client vm didn't have a shared archive to load.
So I modified the tiered vm so that when it was run as a client vm (which it was when it was tested in Alacrity) it would use the same garbage collector as the normal client vm and therefore allow dumping/loading of the shared archive. This was the pretty much that missing piece in the performance puzzle. Between the lack of CDS in the tiered vm and the cost of collecting profile data in the client compilers generated code I could account for the performance gap I was seeing compared to the vanilla client vm.
So it is obvious the next important things to attack:
1: get the garbage collector the server vm uses to support CDS. That is not something I have any expertise at so someone else will be doing that work. (My understanding is that it is doable but that it just wasn't seen as that important for server where startup preformance was not that key.)
2: see what I can do about the cost of profiling in the code the client compiler generates. That will be a topic for another day...
Friday January 05, 2007 People who know me know I'm a big Miami Dolphins fan so it would come as little surprise to know how disappointing the season was and to add insult to injury to have Nick Saban desert the team after his "I'm not going to be the Alabama coach" declaration.
As you might guess Nick got quite a lot of bad press in Miami but I can say I've never read anything in a "real" newspaper like Dan Le Batard piece here. Whew, good thing he held back on what he really thinks! It'd been clear for quite a while that the sports press in Miami really disliked Saban and now they have no reason to hide it.
Nick did quite a good job at creating a lot of instant Auburn fans...
Jan 05 2007, 09:48:37 AM EST Permalink
Tuesday January 02, 2007 So I had a very unusual dream the other night. I was back in the neighborhood I grew up in Pittsburgh (current time) in the living room of a boyhood friend Denny. There were two women there and one of them says to me "Hi Steve". I said I was sorry but I didn't know who she was and she responded "I can't believe you don't remember me. I even went to Fla. with your family one summer!". I said that I didn't know what she was talking about. At that point I woke up and immediately thought "Donna" and went back to sleep.
Next morning I woke and was annoyed that I couldn't remember Denny and Donna's last name. Now I hadn't lived in that neighborhood since 1966 when my family moved to Fla. so it wasn't like it was some recent memory. Still I can point at probably 20-30 houses in that google map and tell you who lived there then so it was annoying. After a day of trying to remember with no luck I called my mother in Fla.
I asked what was the last name of Donna that went with us to Fla. that summer? She said wow that was a long time ago she wasn't sure if she could remember but after a few minutes she did. As near as we can place it that summer trip was probably 1964.
So then I was curious to see if I could find out where Denny was so I googled him. The top few hits were all the same person in Akron which seemed promising. I checked the links hoping to find a photo since several were newspaper articles. No luck but there was an email address. So I figured I send a blind email and see.
I got back a message like "Hi Steve, It's been a long time". He wondered how I found him and I told the story above. Now comes the strange part. Denny told me that his sister has 3 grown-up kids and the she and her husband are living in that same house in Pgh. that I dreamed about.
I'm sure I haven't thought of Denny or Donna in nearly 40 years. It'd be interesting to know what triggered that dream!
Wednesday November 08, 2006 I've actually completed the initial fiberglassing of a few parts of my airplane. The elevators are glassed as well as both winglets.
|
Here you can see the first layup on one surface of one of the elevators. The weights are there to convince the foam to remain flat with the surface of the table. In the background you can see the second elevator being glued down temporarily with 5 minute epoxy to the table surface. Once the top surfaces are complete the elevators are popped off the table and flipped over and the second layup is done. Because they are glued to the table when you pop them off the foam on that side is damaged. Normally with dings and voids you'd fill them with a dry mixture of epoxy and micro-balloons. Weight is critical on the elevators so instead the damage is filled by "pour foam" (like "GreatStuff" only you mix it yourself). The cloth used in this layup is called UNI. It has major fibers running in only one directions. It has a cross fiber running only enough to keep the cloth somewhat stable. In these layup you cut 8.5 inch strips on a 45 degree bias. So from the 40 inch roll you end up with pieces about 28 inches long. So it takes about 2.5 pieces to cover a 72 inch elevator. The layup is two layers of glass with the fibers perpendicular to each other. Because the cloth is UNI and narrow if you look at it wrong the 8.5x28 strip becomes a 4x40 strip in a moment. It's really a pain to control.
|
|
It took me more than an hour to do one layer of glass. At first I was pretty frustrated trying to get it to lay right. The second layer went faster but still the first layup took about 2.5 hours. In the construction videos it took about a half an hour to do both elevators. When I did the first surface of the second elevator it took about 1.5 hours. For the second surfaces I did both elevators at once and it took about 2 hours. Still pretty slow but improving.
After that I started on the winglets. The first thing you do on the winglets is install the comm antenna(s). One of the advantages of a fiberglass airplane is that fiberglass is transparent to radio so the antennas can be inside the airplane and not out in the airstream producing drag. (One of the disadvantages is that a lightning strike in a composite airplane is a much bigger deal than in a metal airplane).
|
Here you can see the antenna preparations. The antenna is a simple dipole using copper foil (like used in stained glass) for the elements. They are just stuck to the surface of the foam. The coax is embedded in the foam and then covered. The manual say to cut the foam track by burning it with a soldering iron and to cover the coax with dry micro. I cut the slot with a router and covered the caox with pour foam. Pour foam is a lot easier to sand into shape and less bother than making up the micro. The winglet is laying on the piece of foam it was originally cut from. There is a curve on the surface of the trailing edge and in order to preserve that gentle curve instead of glassing the winglet on a table you let it sit on the other foam piece until the initial layup is complete.
|
|
|
Here you can see the winglet covered with the fiberglass cloth. This layup was also done with UNI cloth, two layers. The first layer had the fibers parallel to the trailing edge and the second layer the fibers are parallel to the leading edge. The larger cloth was much easier to deal with than the cloth for the elevators. The foam beneath the trailing edge is covered with aviation grade release tape (duct tape) so that the winglet can be popped of the lower foam form.
|
|
To the right is just another view of the winglet while it cures. The cloth you see at the bottom edge (and actually is on the trailing edge too) is a strip of dacron that is called peel ply. It doesn't stick to the epoxy and you can peel it off after the cure and you get a surface that doesn't need sanding if you are doing a later layup. It also tends to remove excess epoxy resin and excess resin only contributes weight, no strength. It is also good to use to get a smooth transition from one are to another. Peel ply can reduce the amount of sanding you have to do and anything you can do to reduce sanding in a composite airplane is a very good thing.
|
|
Friday October 13, 2006 Well it's been almost a year since my last Solaris@Home report. I've been busy with a lot of other things and that project has languished as a result. When we last left I had OWW and misterhouse installed. Misterhouse was running but OWW was not. OWW wasn't running since I only had a single serial port and misterhouse was using it. I had yet to get my imap server running.
Well I had a power supply failure in my linux server and that got me moving again. The linux machine is so old it uses an AT style power supply. New versions of those supplies are kind of rare now and expensive in comparison to new supplies. Fortunately I have a lot of old computers and was able to salvage a supply. The handwriting was on the wall for that machine though, I needed to get to the point where I could shut it down.
Well getting the imap server wasn't to bad of a deal. I downloaded cyrus via blastwave and within an hour I had it working and new mailboxes. Spamassassin was another matter. I got that from blastwave also but I'm running razor and pyzor and getting that all together took an evening. Really it was about as much work as when I did it originally on linux. If I had only taken better notes (ok any notes) it would have been a bit faster.
So now I have moved all my email to the solaris machine. I also decided it was time to upgrade. I had been running the original release of Solaris 10 with just a few patches. I got a copy of the S10U2 dvd and installed it. I was really nervous about this since U2 has the change to using grub and I wasn't sure how cleanly this was going to go. I was pleasantly surprised to have zero issues. It just worked. Probably the easiest upgrade I've had with either solaris or linux. Now I can try out zfs. I'd really been wanting to do that.
So the next thing was to get OWW moved to solaris. This meant getting another serial port. Well as luck would have it U2 included support for Prolific PL2303 based usb/serial ports and I've had two of these sitting around unused for a few years. I plugged them in and they were instantly recognized and new serial ports appeared.
This was just a trick to make me think it was going to be easy. When I connected the OneWire interface to the serial port and ran OWW it reported it could see the OneWire interface. So now I started to do some debugging. I hooked up a breakout box and looped the serial port back on itself. Using tip I could see that the port was active. All the handshaking signals (dtr/dsr/rts/dcd/cts) were ok and I could see the led's flash for data going in and out. But I never saw any data echo in tip. More experimentation (actually quite a bit) made it clear that I was sending data fine but couldn't receive it. I was mystified.
I googled for issues with usbsprl and found nothing useful. Here's where it paid to be Sun employee I search the bug database and found the engineer (Lin) that did the usb driver and sent him email describing my situation. He sent back the clues. According to the man page for usbsprl the streams modules ldterm and ttcompat are supposed to be automatically pushed. Using strconf I could see that I only had usbsprl. So on the advice of Lin I did the following:
1 Add the following line to /etc/iu.ap file:
usbsprl -1 0 ldterm ttcompat
2 Run the command, ignore the warnings:
#autopush -f /etc/iu.ap
this immediately fixed the problem and now I could receive data. OWW was happy. One less thing left running on my linux machine.
I suspect that because I had upgraded to U2 and not done a clean install that the upgrade neglected to modify iu.ap and caused my headache. Hopefully now that I written this up if someone else has the same problem they'll have more luck with google.
Now all that remains is to move my firewall/nat to the solaris machine. I expect that will be another adventure since my experience with networking configs has never been very pleasant.
Thursday October 12, 2006
|
I got to fly a Velocity yesterday. A local owner that knows me from the builders email list had promised to give a ride some time when he was going flying. His plane is based at TTA in Sanford which is real close to where I live and close to my drive home.Last evening he gave me a call at work and said he was on his way to the airport if I wanted to go. I was out of here. It's a very nice airplane, an Oshkosh '97 award winner. This is a photo that I stole from Gary's website. He's actually looking to sell the airplane and get an RV-7. It was a really nice evening, very smooth. This airplane is a 173 which is smaller than the one I'm building. It has an IO360 in it so it has 200HP. It has a fixed pitch prop. I'm not sure if it is climb prop or a cruise prop but it isn't really lacking in either category. When we took off we didn't have much trouble getting close to 2000fpm climb. Makes my tiger look like the climb challenged airplane it is.
|
Oct 12 2006, 10:04:47 AM EDT Permalink
Tuesday October 03, 2006 After being away last weekend in NYC I got to do some airplane building this weekend. I've finished attaching the foam cores to each of the wing spars. I had done the leading edges two weekends ago. They turned out to be easier than the trailing edges. Mostly because they fit better which is because they are smaller and thicker. The trailing edges needed a lot more help lining up. In addition since you want the trailing edges straight, real straight you need to clamp these long straight edges to them. Here is the left leading edge while it is clamped and curing.
I didn't have much problem with the left side. The right side I ended up messing up the foam on the trailing edge. As you can see on the photo from the left side the aluminum channels are being held in place by clamps and bungee (and duct tape that you cant see). The duct tape is what mostly holds the channels together. On the left wing I didn't use duct tape on the whole length and I had the bungees pretty tight. While it was curing I was working the right wing and some of the duct tape popped loose. I caught it before the bungees tried to gouge the foam.
On the right wing I used duct tape on the whole length of the aluminum. I also didn't tighten the bungees as tight. Of course when I checked it the next day the duct tape had given way and the bungees had gouged the foam. You can barely see it in the picture below since most of the damage is at the outboard section of the wing. At least it is an easy thing to fix.
One thing I realize is how much room this is all going to take. I can't see how people build these things in their garage. I've got a 20x40 foot area here and I'm really starting to feel cramped. I'm already working on a design where I'll be able to hang the wings in storage out in the open section of the hangar to get them out of the way when I'm not working on them.
Thursday September 28, 2006
Password Hell
I had a frustrating password day yesterday. Like everyone I have way too many passwords to remember. Here at Sun we get a reminder every 6 months (?) to change the password on our main login. I got one a week or so ago and had been putting it off. Last Friday I finally changed passwords. Since I was going on vacation for a few days I left myself a postit to remind that I changed my password (but NOT the password or even a hint for it).
So I came in yesterday morning to my postit and the screen being locked and for the life of me I can't begin to remember what my new password is. I tried password for probably 15 minutes before I gave up and used a trick to defeat my screen lock. That only got me access to my workstation though. I couldn't send email but I could read it. It gave me time to think about the password.
I was sure that the password had something to do with aviation but I couldn't come up with it. The odd thing is I had this word in my mind, a name really and I couldn't begin to connect it with aviation or anything password related. After about an hour or two I was getting close to having to ask IT to reset my password. I said to myself "I sure wish I knew the password". Instantly I remembered it. Now here's the weird thing. The actual password had the same initial 3 letters as the word I couldn't get out of my head. Now that's not too weird except that the word my password is derived from and the word in my head the pronunciation is very different so it seems clear that my memory had filed it away alphabetically and not phonetically. In any case I was glad to finally remember the dang thing.
That is almost the end of the story. When I got home I was working on my Solaris server at home as I'm finally close to shutting down my ancient linux server. For some reason pyzor wasn't working with spamassassin. After a bit of debugging I realized that the pyzor client wasn't able to talk to the pyzor server but it was only blocked from the Solaris box. My linux box is normally my firewall so I checked that and no it wasn't blocking it. So it had to be the wireless router (which is actually wired in this case) between the two. So I went to login to the router. You can see where this is going now. I probably haven't logged into that router in 2 years. I have no idea wtf the password is. Worse I don't even know if I used as the account name. Normally I send myself some piece of email to use as a vague reminder in cases like this. No sign of any email in this case. I tried account/password combinations for probably an hour. I'd have hard reset it by now except I remember I had some strange problem in getting the router setup the first time and didn't want to do it again. After trying to think of possible passwords most of today I see a hard reset in my future...
Sep 28 2006, 02:22:56 PM EDT Permalink
Wednesday September 27, 2006 So my wife and I went to NYC for a long weekend this past weekend. This was actually a Christmas present I gave her last year, a three day weekend in New York and tickets to The Daily Show. We were supposed to go last April but things got screwed up with the tickets.
Getting the tickets is kind of strange. You request tickets by sending an email and then eventually you get an email saying that you have tickets. You don't really have tickets though what you get at first is a note saying that they will send you ticket confirmation 2 weeks prior to the show. When you get that confirmation then you immediately have to reply to that email and if you are fast enough you get the tickets. Not that you are then assures of getting in anyway.
Well back when we were going in April the second email they sent 2 weeks prior to the show was determined to be spam by spamassassin running on my home server and thrown out. By the time I realized that it was too late and we couldn't go. So we had to ask for tickets again and start the whole process over. We asked for Sept. 25 as our 1st choice and Sept. 18 as our second choice. Bill Clinton was the guest on the 18th and Pat Buchanan was the guest on the 25th so it was unfortunate we didn't get our second choice!
They tell you to line up 1-1.5 hours before the doors open at 4:45pm and that you may not get out until 7:30pm. We got there about 75 minutes before hand and were 175th in line. The studio holds somewhere around 250 so it was good we weren't much later.
Security seemed to be more than I'd have expected for going to a TV show and once we were inside and the taping was about to begin Jon Stewart let us know the the guest on Tues. was Pres. Musharraf and that security had been checking out the place all day.
It was surprising to see how low rent the set appears in person. Considering this is the new improved set it hard to imagine what the old one looked like. The other surprising thing was how fast the whole show seemed. Seemed much faster than when you see it at home even though at the commercial breaks everytthing stops for about the same time as the real commercials. Sort of like TV timeouts when you are at a football game. All in all we enjoyed it immensely.
Sep 27 2006, 11:30:59 AM EDT Permalink