Back on Ground

It was very tiring but one of the best days in my entire life so far. As said earlier, I went to Superior Wisconsin, which is in a North West corner of Wisconsin and couple of miles south of Downtown Duluth MN. This picturesque small town is situated on the shores of lake superior, the biggest fresh water lake in the world.

I started my trip from Rochester at 945AM Sunday morning. Karoline and Alain joined me on my trip. It was actually a surprise to me as I was supposed to drive by myself to Duluth. Never the less it was a pleasant surprise, their company made my trip little less tiring.

We stopped at Forest Lake, MN and had a nice latte, to keep everybody awake, though it didn't work that well. But no worries as I didn't sleep which was most important considering the fact that I was driving.

After a 2hr drive from Forest lake we finally reached Sky dive Superior at 2 PM sharp, and that's exactly what I had planned for. Once we reached there, it was all business.

The lady at the desk started with my paper work. I started filling the forms and in process waived all ( if any) rights to sue the sky dive office and should anything happen to me, which obviously didn't happen. I then watched the training video, which made me both excited, and little nervous. Luckily the manager of that place, Mark had his birthday on Sunday so the cake helped me feel better. All the nervousness and anxiety had gone only excitement lingered around, which was good. After waiting for almost an hour for my turn to come, I suited my self up for the jump.

Then I put on my red jump suit, which I actually liked. They gave me some brief instructions about body positions and equipment handling which was followed with a brief one on one training while I waited for my instructor to land. He was already up in air doing tandem jump with some other people. Once he landed , he took some time off and then came to me and checked my jump suit, harness and the different body positions I was taught. Once he felt comfortable, we mocked the jump from the plane ( which was grounded ). Then it was time to go. Go up in the air.

This is when Mark took over, he started shooting my video. He did a brief interview and asked me to make funny gestures for his video. After the interview, we made one last mock jump, but this time all geared up with the instructor. Then it was 1-2-3 and go....

We sat in this small plane, I don't know what kind it was, I think it was Cessna. But that didn't bother much. The plane wasn't in a great shape as it was modified/stripped down to bare minimum. Me my instructor Dean, the camera man Mark, the pilot and one solo jumper Mike we all boarded the plane and took off. I tell you, flying in a Boeing or airbus is sure a luxury compared to this craft. But the kind of view you can get from these small planes is just amazing there is nothing that comes close. We started ascending at about 1200ft a minute. We circled around downtown Duluth, went over Lake Superior for a while and when we reached the altitude of about 12000 ft or say after about a 10 minute flight, my instructor asked the pilot to take us to a suitable position to do the jump.

The door opened, and he gave us a thumbs up to jump, and we acknowledged him with a thumbs up. The solo jumper without taking any time was out in a flash. Mark my camera guy, clung on to the wings and positioned himself to shoot me jumping out.

At this moment, we moved forward to the door, and positioned ourselves to jump, and for one last time I looked at the plane. Airplane flying at 12,000 ft with its door open, it is enough to make anybody nervous/panic, but I felt very serene. When the door opened I heard the sudden gush of wind, may be a 100th of a second I thought what the heck am I doing, but once I reached the door and looked outside all my fear and anxiety was gone, it was such a serene feeling, it was like 'Lets do it' . Dean put his foot out holding the plane with one hand, then he asked me to put my right in front of him, and at this moment I was 80% out of the airplane with only my left leg in the airplane.

It took me a second or two to position myself, and one last second in front of the camera and here we jumped and I was in the free fall. The first thing I remember is the sudden and huge blast of wind on my face. For may be 5 seconds I was unable to breath. But then I started breathing normally and it all felt such wildly wonderful. The free fall as opposed to what the word says doesn't' really feel like a fall at all. you don't feel like you are falling down or something. It feels like you are standing in front of a big, really big fan blowing really high speed wind at you. It all lasted for about 45 seconds, and during this time we had already descended from 12000ft to 5 or 6 thousand feet. At this time my instructor pulled the ripcord of the parachute. I realized it only after it opened completely and I felt a jolt. After that, it was such a nice feeling, it was all calm and quiet. We went on small ride of our own for a while. Dean was giving me instructions how to control the speed, direction and stuff like that.

After brief maneuvering lessons we were ready to land. I positioned my legs in bent knee fashion and we were ready to land. I suddenly felt the ground rush, which Dean said was normal, and before I knew we had landed. The moment he landed I put my feet on the ground and that caused him to loose his balance a little bit and we stumbled, but hey we didn't fall this time we already had fallen some 6000 ft doing our free fall. Mark had a final word with me asked how did it felt. Well what can I say, it was amazing, mind blowing experience after all.

I just uploaded some pics from my ski trip and my skydiving trip. They can be found out here..

Living on the edge

What would you say of life of a person who does water skiing but doesn't know how to swim ?

What would you say of life of a person who goes for skydiving knowing fully well that he doesn't have wings to fly ?

I would say its like walking on a highwire or dancing on thin ice, or simply, he is 'Living on the edge'.

Land - Water - Air

Till yesterday I had no plans whatsoever for the 4th of July long weekend. Well it is not really a long weekend and I am working on Sat and Sun morning and that is other reason why I didn't make any plan.

But things just started falling into places since yesterday afternoon. If every thing works out as planned then on Saturday morning I will be joining my friend David and his GF on their boat and we plan on doing some Jet Ski and Tubing. I cannot swim very well but with life jacket and a life guard on the board I don't mind risking a little bit.

Talking about some risky business, the craziest thing on my mind this weekend is to go for Sky diving in minneapolis. I have been postponning it for way too long. My roomies did it in year 2003 and ever since they have been trying to persuade me to go for it. I think the moment has finally come. I have asked a few friends here at Mayo if they would like to join me for the dive, the answer is negative so far. But I have made up my mind and I am going to do that with company or alone.

Taking off finally

I have been waiting/delaying and waiting my India trip for quite some time, almost 3 years now. But finally I bought my ticket last week and yesterday confirmed my flight connections in India. Now it is time to start packing my bags. There is one weird thing, eventhough I am going back home I don't have the excitement I had when I went back the first time.

Fibers

Fibers were added to Windows (in NT 3.51 SP3, IIRC) because some customers (not just SQL server) believed that they could improve the performance of their server applications if they had more control over their threading environment.

But why on earth did these customers want fibers?

Well, it's all about scalability, especially on MP system. On a multitasking system, it's easy to forget that a single processor can only do one thing at a time.

The ramifications of this are actually quite profound. If you've got two tasks currently running on your system, then your operating system will have to switch between each of them. That switch is called a context switch, and it can be expensive (just for the sake of argument, let's say a context switch takes 5000 instructions). In a context switch, the operating system has to (at a minimum):

Enter Kernel Mode
Save all the old threads registers.
Acquire the dispatch spinlock.
Determine the next thread to run (if the next thread is in another process, this can get expensive)
Leave the dispatch spinlock.
Swap the old threads kernel state with the new threads kernel state.
Restore the new threads registers.
Leave Kernel Mode
That's a fair amount of work to perform (not outrageous, but not trivial).

The OS won't do this unless it has to. In general, there are three things that will cause the OS to cause a context switch are (there are others, like page faults, but these are the big ones):

When your thread goes to sleep (either by calling Sleep() or calling WaitFor[Single|Multiple]Object[s])
When your thread calls SwitchToThread() or Sleep(0) (this is a special case of the Sleep() API that is identical to SwitchToThread())
When your thread's quanta elapses.
A thread's quanta is essentially the amount of time that the OS will dedicate to a thread if there's another thread in the system that can also run. A quantum is something like 5-10 ticks on a workstation and 10-15 on server, and each tick is typically somewhere between 10 and 15 milliseconds, depending on the platform. In general, your thread will get its full quanta unless there is a higher priority runnable thread in the system (please note: this is a grotesque simplification, but it's sufficient for the purposes of this discussion).

The thing is, for a highly scalable application, context switches are BAD. They represent CPU time that the application could be spending on working for the customer, but instead is spent doing what is essentially OS bookkeeping. So a highly scalable application REALLY wants to reduce the number of context switches. If you ever have a service that's performing poorly, one of the first things to look for is the number of context switches/second - if it's high (for some value of high), then there's invariably a scalability issue in the application that needs to be addressed.

So why fibers? Because for highly scalable applications, you want each of your threads to get their full quanta - in other words, you want the only reason for a context switch to be reason #3 above.

Remember the first cause of context switches: Calling WaitFor*Object. What that means is that if you call EnterCriticalSection on a critical section with contention, then you're highly likely to cause a context switch. The same thing happens when you wait for an I/O to complete, etc. You absolutely want to avoid calling any Win32 APIs that might block under the covers.

So fibers were created to resolve this issue. A fiber is effectively removes steps 1, 3, 5 and 8 from the context switch steps above, switching from one fiber to another just saves the old register state, and restores the new register state. It's up to the application to determine which fiber runs next, etc. But the application can make its own choices. As a result, a server application could have a dozen or more "tasks" running on each thread, and they'd radically reduce their context switch overhead, because saving and restoring registers is significantly faster than a full context switch. The other thing that fibers allow is the ability to avoid the dispatcher spin lock (see John Vert's comment about context switches being serialized across all processors below). Any global lock hurts your scalability, and fibers allow an application to avoid one of the global locks in the system.

Ok, so why have fibers remained obscure?

They've remained obscure first because of the reasons Raymond mentioned in his fibers caveat - using fibers is an all-or-nothing thing, and it's not possible to use fibers from a shared library. Some of the idiosyncrasies of the fiber APIs have been resolved in the current versions of Windows.

They're also HARD to deal with - you essentially have to write your own scheduler.

Raymond also left off a couple of other gotchas: For example, if you're using fibers to improve your apps scalability, you can't call ANY Win32 APIs that might block (including filesystem APIs) because all the Win32 blocking APIs are also have thread affinity (not surprisingly :)) So if you're running 20 fibers on a single thread, when any of the fibers blocks, your thread blocks (however, the fibers can be run from another thread, because fibers don't have thread affinity, so if you have a spare thread around, that thread can run the fibers).

The other reason that fibers have remained obscure is more fundamental. It has to do with Moore's law .

Back when fibers were first implemented, CPUs were a lot slower. Those 5000 instructions for the context switch (again, this is just a guess) took .05 millisecond (assuming one cycle/instruction) to execute on a 100MHz machine (which would be a pretty fast machine in 1995). Well, on a 2GHz machine, that .05 is .0025 millisecond - it's an order of magnitude smaller. The raw cost of a context switch has gone down dramatically. In addition, there has been a significant amount of work in the base operating system to increase the scalability of the dispatcher spinlock - nowadays, the overhead of the dispatcher lock is essentially nonexistant on many MP machines (you start to see contention issues on machines with a lot of CPUs, for some value of "large").

But there's another aspect of performance that has gone up dramatically, and that's the cost of blowing the CPU cache.

As processors have gotten smarter, the performance of the CPU cache has become more and more critical to their speed - because main memory is painfully slow compared to the speed of the processor, if you're not getting your data from the CPU's cache, you're paying a huge hidden penalty. And fibers don't fix this cost - when you switch from one fiber to another, you're going to blow the CPU cache.

Nowadays, the cost of blowing the cache has leveled the playing field between OS context switches and fibers - these days, you don't get nearly the benefit from fibers that you did ten years ago.

This isn't to say that fibers won't become useful in the future, they might. But they're no longer as useful as they were.

Btw, it's important to note that fibers aren't the ONLY solution to the thread quantization issue mentioned above. I/O completion ports can also be used to limit context switches - the built-in Win32 thread pool uses them (that's also what I used in my earlier post about thread pools). In fact, the recomendation is that instead of spending your time rewriting your app to use fibers (and it IS a rewrite), instead it's better to rearchitect your app to use a "minimal context" model - instead of maintaining the state of your server on the stack, maintain it in a small data structure, and have that structure drive a small one-thread-per-cpu state machine. You'll still have the issue of unexpected blocking points (you call malloc and malloc blocks accessing the heap critical section), but that issue exists regardless of how your app's architected.

If you're designing a scalable application, you need to architect your application to minimize the number of context switches, so it's critical that you not add unnecessary context switches to your app (like queuing a request to a worker thread, then block on the request (which forces the OS to switch to the worker, then back to the original thread)).

--
From one of the internet discussion forums