« On cell phones and swiss cheese | Main | Can that thing measure a New York Minute? 'cause Jimmy could be walking through that door any minute. And this is New York Ci »

We're the pros from Dover

I heard Bjork on the radio on the way in this morning. You don't hear her stuff much on the radio anymore.

The movie MASH was on TV yesterday, and I watched part of it from my hotel room. MASH has to be one of the funniest movies of all time. Ever wonder where Hot Lips got her name? You gotta watch the movie to find out.

"Goddamn Army jeep!"

I think the football segment of the movie has got to be one of the best football movies ever. "I think their ringer just made our ringer."

I continue to have less and less hope in the current myrinet code. It seems to be a sinking morass of race conditions. I fix one, and another one appears. The next one inevitably shows up in an innocuous single test failing in the test suite. After tracing it down, it typically turns into a conglomeration of events that ends up in some memory location being used twice. <sigh>

This is completely the fault of stealing from the TCP RPI -- the myrinet RPI reflects many of the same assumptions that the TCP RPI reflects, most of which aren't necessary when using gm for communication. The central assumption that has caused the most Badness is that when you read() from or write() to a TCP socket, you may or may not transfer all the data that you expect to transfer.

Since most of the time you're not allowed to block, you have to have extensive bookkeeping to remember exactly where you were in reading/writing a given message. The next time you enter the state machine, you have to try to continue reading/writing from where you left off.

Hence, each socket has some state associated with it -- pointers for the current message being read/written, and how many bytes are left. This stuff is all redundant in myrinet, because it doesn't send/receive partial messages. Hence, when you send, it's sent. When you read, it's read in its entirety. However, the current code still uses these pointers that are associated with each "socket" (actually, we call it a "process"). It dawned on me while I was walking in that this could be the root of much Badness in the myrinet RPI. I'll spend the rest of today investigating getting rid of all of that stuff and see if I can send/receive directly from the MPI request in question rather than use all these temporary pointers/bookkeeping that is attached to each process.

T-5 days left on my current army tour.

I have to spend some quality time with my beret tonight and get it into shape.

I spent an hour on hold with Network Solutions yesterday before I finally got someone. Fortunately, the guy that I got was actually fairly cluefull. We managed to get the top-level DNS servers for lam-mpi.org|net|com changed to the IU servers.

The change apparently went in at 5am this morning; it'll take a day or three to propagate around the world. No domain that I have access to can see this change in DNS yet (LBL, MCS/ANL, ND, GATech, Telocity), so I hope it's propagating... I guess that was only about 6.5 hours ago, so it may not have been picked up by any of the respective local DNSs yet.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on June 17, 2001 10:30 AM.

The previous post in this blog was On cell phones and swiss cheese.

The next post in this blog is Can that thing measure a New York Minute? 'cause Jimmy could be walking through that door any minute. And this is New York Ci.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34