Yili Gong's Workspace

2008-06-20T12:12:00.000-04:00

On writing

Yale N. Patt

I remember a quote, attributed to Thornton Jenkins, the original Headmaster of the public high school I attended. I guess they felt calling the Principal a Headmaster would in some way compensate for everything that was wrong with the place. "What a man (today we would say man or woman) knows or what a man thinks is lost if he can not express it through oratory or writing."

Although I usually focus on how computers work and what we can do to make them work more effectively in the future, I recognize the importance of writing to getting our ideas across. Unfortunately, too many of us were taught too many bad "rules" along the way that need to be unlearned. In that light, and as a start, I offer the following:

Technical writing is for the benefit of the reader, not the writer. As a writer, it is worth taking the time to focus first on what your readers will bring to the table when they try to read what you write. If you keep your readers always in mind while you are writing, they will have a better chance of understanding what you have to say.
Short sentences are better than long.
Small words are better than big. The only 5 syllable word I use is "delicatessen."
The verb is the most important word in the sentence.
There are plenty of good, usable, legitimate verbs already out there. It is not not necessary to stick "ize" at the end of any random noun and invent a new one.
Active is better than passive.
It is okay to end a sentence with a preposition. Better that than an awkward sentence. Better still to rework the sentence so it does not come out awkward and does not end with a preposition.
It is okay to use the same word again in the same paragraph. A thesaurus can be put to better use propping up the small leg of a four-legged table than providing a word that means almost the same thing as the word you really want to use for the second time in that paragraph.
It is not okay to make spelling mistakes. A pocket dictionary next to your desk is an absolute must. If the word is not in the pocket dictionary, you probably shouldn't be using it in the first place. Spellcheck will not ketch awl mistakes.

2008-06-20T12:06:00.003-04:00

My Ten Commandments for Good Teaching

Yale N. Patt

1. Know the material:

The purpose of teaching is for students to learn. To help a student who is having trouble understanding the material, you need to know (a) where the student is having a problem, and (b) how to explain it differently the second time. Both require that you know deeply the material you are teaching. It is not good enough to be "one page ahead" of the class, or to have memorized the material well enough to write it on the blackboard without making any mistakes.

2. Want to teach:

When you walk into a classroom, you should want to be there. Very little is as infectious to the student as an instructor who is genuinely happy to be there. The students can tell the difference. If the instructor is excited about the course, the student is likely to be also.

3. Genuinely respect your students and show it:

You are in the classroom for the benefit of the students, not vice-versa. Your ability to help them understand concepts that they currently do not understand is enhanced enormously if you connect with them. No one wants to be treated like a dummy or talked down to. Connecting means giving them credit for having a brain, willing to use it and caring enough to do what it takes to get it. AND, conveying that -- not verbally, but through your body language. That means respecting them.

4. Set the bar high; students will measure up:

Good students are there to learn and they know it won't happen automatically. My experience is that if you set the bar high, and do NOT waste the students' time with tedious work that serves no learning purpose, they will work as hard as they can to measure up to it. The myth that students want an easy course is just that, a myth. Some of them may complain and moan at the moment over some very tough homework. But at the end of the course, I generally am thanked profusely for setting the bar high. "Thank you, I never thought I could learn so much in one semester" is a comment I often get at the end of the course.

5. Emphasize understanding; de-emphasize memorization:

Memorizing is not understanding. Unfortunately, many students have gotten by for a very long time on the basis of a sharp memory, and have never had to really think. Memorization may work for the moment, but after graduation when they are faced with new challenges, it is their ability to think and to understand that will carry the day, not their ability to memorize. I have seen too many examples of students who can memorize almost anything, yet cannot think through a simple extension of what they have memorized. I suggest they will not be prepared for what lies ahead after graduation, in work or in life.

6. Take responsibility for what is covered:

Too many instructors have been lulled into this new pedagogical notion that the students should decide what gets taught in the classroom. Not in my classroom. I have been around longer, have seen techniques come and go, and because of that, I believe I know better than they what is important for them to know to be successful after they leave my course. Ergo, I decide what gets covered. I am very concerned about this fashionable notion of letting the students decide. Many students want instant gratification -- a technique they can use today, whether or not it will be useful downstream. It is up to instructors to take charge of what goes on in their classrooms.

7. Don't even try to cover the material:

When one sits in the office in August and plans the syllabus for the Fall semester, optimism runs very high. The instructor often lays out the course outline, assuming that every student gets every point the first time, that every explanation is brilliant, and that no student needs to ask a question. Not too many classes into the semester reality sets in. The fact is that some days the explanations are bad. And, some days the students don't get it the first time. Ergo, if one insists on covering the material, the only one left standing at the end of the course is the instructor (maybe). I believe the following. First, there is always far more material than can be covered adequately in a semester. BUT, only a core body of material needs to be covered. So, in August when everything is coming out roses, sure -- assume the best. But, as the semester moves along, and reality sets in, do not be afraid to stop and cover again the same point a second or third time, bringing in different perspectives and examples to get it across. Answer questions, even if it means totally blowing the schedule. That is, do not even try to cover the material. Certainly, one has to cover the core body necessary to move on to the next semester. But that usually represents half the material, or so. Anything beyond that is a bonus, and has no place in the course if the student failed to learn the core material.

8. Encourage interruptions; don't be afraid to digress:

This is a consequence of the one just above. The point is that the reason for the course is for the student to learn. If the student is not learning, it it irrelevant how much material is being covered. Therefore encourage interruptions. It means the student is thinking. And, if the student is thinking, he/she has a chance of getting it. Digress when it seems useful. Digressions can add meaning to the understanding of a concept. Anecdotes from the instructor's experience can make the material more alive. It can provide just the twist that allows the student to get it.

9. Don't forget those three little words:

The three little words are "I don't know." The biggest thing about a classroom that makes learning work or not work is the connection between the instructor and the students. Many of the items above relate to establishing that connection. Nothing will destroy that connection as quickly as the instructor speaking nonsense. It only takes one student in the class to know that the instructor is bs-ing, and credibility has been lost for good. And, if the instructor loses credibility, he/she has nothing. Students will tune out. AND, it is okay to not know. The instructor can not be expected to know everything. That is the nature of humans. Never pretend to know. Just say, "I don"t know," move on, and if possible try to find out before the next class and answer the question then.

10. Reserved for future use:

Many have observed that this last one is not a commandment at all, and that therefore there are really only nine. Wrong! This tenth one is my way of saying you should make allowances for contingencies. Things will often not go as planned. Be prepared to adapt to dynamic situations, as they unfold.

2007-12-04T10:06:00.000-05:00

Word Wrap in Eclipse
Eclipse without wordwrap function sometimes is a nuisance. Find a plugin to solve it.
http://ahtik.com/blog/2006/06/18/first-alpha-of-eclipse-word-wrap-released/

In Eclipse, Help -> Software Updates -> Find and Install -> Search for new features to install -> New Remote Site -> Name: Wordwrap; URL: http://ahtik.com/eclipse-update/, then click OK -> click Finish.

In the right-click manu, choose Virtual Word Wrap. Done!

2007-08-23T11:48:00.000-04:00

A JAXB Problem
JAXBContext jc = JAXBContext.newInstance("edu.iu.cgl.gpir");
Unmarshaller u = jc.createUnmarshaller();
ResourceStatic rs = (ResourceStatic)u.unmarshal(new StreamSource(new StringReader(rslt)));

The above method works fine for GPIR while got an error for QBETS:
Exception in thread "main" java.lang.ClassCastException: javax.xml.bind.JAXBElement cannot be cast to edu.ucsb.cs.nws.MachinesType

I debugged and found that the returned value of unmarshal() is JAXBElement, but don't know why it can't be cast to the type I expect.

Found the solution at http://www.velocityreviews.com/forums/t298335-javalangclasscastexception-javaxxmlbindjaxbelement.html

Use
MachinesType machines = (MachinesType)((JAXBElement)u.unmarshal(new StreamSource(new StringReader(rslt)))).getValue();

It works.

2007-07-20T17:18:00.000-04:00

JAXB 2.1 and JDK 6
I'm trying to use JAXB to generate corresponding Java class file from the xsd file.
When I ran xjc.sh, an error popped:
"Exception in thread "main" java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI (from jar:file:/globalhome/yiligong/software/jaxb-ri-20070125/lib/jaxb-impl.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.5.0/docs/guide/standards/)"

The solutions might be:
1. Use Java endorsed mechanism to override whats in Java platform. See http://java.sun.com/j2se/1.5.0/docs/guide/standards/ for more details on Endorsed Standards Override Mechanism.
2. Simply copy jaxb-api.jar to

/lib/endorsed.
3. Since I have no root privilege, I added "-Djava.endorsed.dirs=/globalhome/yiligong/software/jaxb-ri-20070125/lib" into the last line of xjc.sh, i.e. exec "$JAVA" $XJC_OPTS -Djava.endorsed.dirs=/globalhome/yiligong/software/jaxb-ri-20070125/lib -jar "$JAXB_HOME/lib/jaxb-xjc.jar" "$@".

A JAXB 2.1 tutorial:
http://www.javaworld.com/javaworld/jw-06-2006/jw-0626-jaxb.html?page=1

2007-07-04T23:48:00.000-04:00

Total Copy
I was trying to copy a .iso file (6.22G) from one one computer to another.

Found Total Copy online and it worked perfect.
http://ranvik.net/totalcopy/

2007-06-21T10:05:00.000-04:00

Thinkpad T60 Memory Installation

http://www-307.ibm.com/pc/support/site.wss/MIGR-62825.html
Easy!

2007-06-20T13:19:00.000-04:00

TeraGrid Related Stuff
Java-based GSI-SSH Term:
http://grid.ncsa.uiuc.edu/gsi-sshterm/

Single Sign-On on TeraGrid:
http://www.teragrid.org/userinfo/access/index.php

2007-06-15T09:36:00.000-04:00

Zebra sent me a video on Youtube. Following it I found this website: http://www.ted.com/. A lot of new and funny stuff inside.

Lili sent me this for my laptop update use: http://www.cpuid.com/cpuz.php.

2007-06-14T22:41:00.000-04:00

gnuplot
Haven't used gnuplot for a long time and reheat it now.
gnuplot 4.2: http://www.gnuplot.info/
a good start tutorial: http://www-128.ibm.com/developerworks/library/l-gnuplot/
Some complicated plots here: http://mos.stanford.edu/papers/Plotting.pdf

2007-06-05T21:22:00.000-04:00

How to construct a histogram in Excel (without Data Analysis Toolpak)

http://www.geocities.com/calculatorhelp/excel_histograms.htm

This example uses the following simple data set (quiz scores for twenty students): 5, 7, 8, 3, 7, 7, 1, 9, 6, 8, 5, 6, 7, 8, 7, 9, 6, 8, 6, 6. To construct a histogram with five bars:
Type numbers in column A, starting at A1. Press ENTER after each number.
In column B, starting at B1 type 2, 4, 6, 8. Note that it is not necessary to write 0 or 10.
Because the histogram will have 5 separate bins, select 5 contiguous cells, for example c3:c7.
Click in the formula bar (the long white bar with the equals sign) and type =frequency(a1:a20, b1:b4). The first array contains the data; the second array contains the bin separators.
Press Control-Shift-Enter simultaneously. You will see an array of 5 numbers.
To draw the graph, you can use the chart wizard: Highlight the number in column C. Click on the chart icon at the top of the page. Choose columns. Click on "next". A bar graph will appear in the window. To make the graph comprehensible to others, add some titles by clicking on "next". For titles, type "histogram of quiz scores". For category, type "quiz score". For value on the y axis, type "quiz score frequency". Click "finish".
The graph that you see now is technically a bar graph, NOT a histogram, because there are spaces between all the bars. Histograms should not have spaces between the bars unless there are categories that have no observations. To rectify this, double click on one of the bars. Another window will appear. Click on "options" and change the gap width to 0. Then click "OK". Now it’s a legitimate histogram.

2007-04-10T09:50:00.000-04:00

Usage of RDTSC
rdtsc is a VC call and implemented in assembly. It gets the current ticks of CPU.

1) header files

#include

#pragma intrinsic(__rdtsc)

#include

2) body

LARGE_INTEGER m_largeint;

QueryPerformanceFrequency(&m_largeint); //get the clock frequency of CPU in HZ

unsigned __int64 i = __rdtsc(); // get the current CPU ticks
int c = my_write_packet_to_queuepSendQueue,tLibnet); // the code you want to measure
unsigned __int64 j = __rdtsc(); // get the current CPU ticks

int m = (j - i)/m_largeint.QuadPart; // the running time in seconds

2007-01-28T22:00:00.000-05:00

What Is Web 2.0
Design Patterns and Business Models for the Next Generation of Software
by Tim O'Reilly
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=1

Quote:
Core Competencies of Web 2.0 Companies
In exploring the seven principles above, we've highlighted some of the principal features of Web 2.0. Each of the examples we've explored demonstrates one or more of those key principles, but may miss others. Let's close, therefore, by summarizing what we believe to be the core competencies of Web 2.0 companies:
* Services, not packaged software, with cost-effective scalability
* Control over unique, hard-to-recreate data sources that get richer as more people use them
* Trusting users as co-developers
* Harnessing collective intelligence
* Leveraging the long tail through customer self-service
* Software above the level of a single device
* Lightweight user interfaces, development models, AND business models

End of quote

2006-12-14T13:14:00.000-05:00

Try Something New -- Desktoptwo
Desktoptwo is a free web-based desktop that mimics the look, feel and functionality of a local computer, all contained within one browser window and fully accessible from any Internet-connected device.
http://desktoptwo.com/

2006-12-13T16:03:00.000-05:00

Some Papers on Workflow in Grids

SIGMOD Record: Special Section on Scientific Workflows
Sept. 2005
http://www.sigmod.org/sigmod/record/issues/0509/

SC'06
http://sc06.supercomp.org/techprogram/papers.php

WORKS'06 : The Workshop on Workflows in Support of Large-Scale Science
In conjunction with HPDC 2006, June 19-23, Paris, France
www.isi.edu/works06

GCE'06
http://www.cogkit.org/GCE06/GCE06/Program.html

2006-12-11T17:03:00.000-05:00

How to Increase the Chances Your Paper is Accepted at ACM SIGCOMM (ZT)
by Craig Partridge

This note is some informal and personal advice about ways authors can increase the chance that a paper they submit to ACM SIGCOMM will be accepted. My dual purpose in writing this note is to help authors submit better papers and help the SIGCOMM conference, by improving the quality of papers it receives.

My dubious qualifications to write this note are that I've served on the SIGCOMM Program Committee every year since 1989 and was Co-Program Chair in 1994 and that I've had two papers accepted, and several papers rejected, by ACM SIGCOMM.

I. THE PAPER EVALUATION PROCESS

It is useful to start by describing what happens to a paper after it is submitted to ACM SIGCOMM. It is important to keep in mind that SIGCOMM runs a double-blind reviewing process. By double-blind we mean that authors don't know who their reviewers are, and reviewers don't know who the authors are. Personally, I'm a big fan of double-blind reviewing. Double-blind reviewing focusses attention on the papers, rather than who wrote the papers. And every year there are some surprises p; SIGCOMM accepts an outstanding paper from previously unknown authors.

We leave it up to individual authors to decide how widely to distribute their papers over the Internet before the program committee meeting. Even in the case when the identity of the authors is known to the reviewers, we believe that double-blind reviewing is of value as a symbolic reminder to the reviewers to review the paper itself and not the authors or the authors' reputations.

The first step in the evaluation process is that the program chairs circulate the title and abstract of each paper, and ask the program committee members to indicate which papers they are qualified to review. Based on the feedback from the program committee members, the program chairs then assign the papers to committee members for review. Observe that this process usually ensures that a paper is reviewed by someone who feels well-qualified in the paper's field.

In some years, each paper has initially been given to two reviewers, in other years each paper has been given to three reviewers. The program committee members are expected to read all their assigned papers themselves (though they may also solicit additional reviews from qualified colleagues).

Each reviewer rates the paper on a 1 to 5 scale, with a rating of 3 or above indicating the paper is acceptable. Each reviewer also writes a text review indicating what she or he sees as the strengths and weaknesses of the paper.

The program chairs collate all the ratings about two weeks before the program committee meeting. At this time, papers that have a wide range of ratings (such as a 1 and 5 from two reviewers) will be assigned to additional program committee members for review before the meeting. In years that only two reviewers initially review a paper, all papers that are candidates for acceptance also get a third review during this period.

The program committee meeting's purpose is to pick the best 24 to 30 papers for SIGCOMM from the 250-odd papers that are submitted. Inevitably there's a bit of randomness in the process (how a paper fares depends in part on which reviewers it is assigned to). But the process is intended to try to minimize the randomness. In particular, it is generally the case that every paper that received at least one rating of 3 or higher is discussed by the program committee. So the committee as a group is looking at a fairly large chunk of the papers (typically about half of them) to find the 10% of the papers it wants to accept.

The program committee meeting is an intense process, lasting all day and often into the night. Controversial papers are often given to additional people to review during the course of the meeting, and while the average paper's fate is decided in a minute or two, the last few decisions often take 20 or 30 minutes each.

It is also worth noting that program committees typically do not try to shape the program. That is, there's no attempt to ensure that a hot topic has papers accepted, or that there's a balance of theory and systems papers. Rather the goal is to take the best SIGCOMM-related papers that can be found, regardless of topic. Indeed, the program often accepts papers on topics known to be obscure or appealing to a small community on the grounds that the technical work is outstanding and deserves circulation to the broader community.

II. GENERAL ADVICE

This section gives general advice about how to improve your submission to SIGCOMM. The next section gives detailed advice about particular topics and types of papers.

II.1 Start Writing Early

One cannot stress enough the importance of making sure your paper is well-written. Because SIGCOMM is double-blind, the reviewers often have no idea who wrote the paper. So they cannot make allowances for your reputation and, for instance, say to themselves "Joe can easily fix this paper up." If the writing is sloppy or the presentation is bad, the paper probably will not be accepted. SIGCOMM does accept two or three papers each year on the condition that a program committee member oversees the revision of the paper. But these revisions are typically for technical content, not presentation.

I often tell prospective authors that they should aim to have a first draft of their paper done three to four weeks before the SIGCOMM submission deadline, solicit a few reviews from colleagues and friends, and then revise the paper before submitting it to the conference. This advice is doubly strong for authors for whom English is not their native language.

II.2 Properly Cite and Summarize Prior Work

A surprising number of papers fail to cite relevant prior work, or worse disparage or misrepresent the prior work to make the paper's contribution look better. Reviewers who are trying to assess a paper's contribution tend to get annoyed when that contribution is exaggerated or, worse, is a reinvention of prior work.

A corollary to this comment, is that the authors should make the readers aware of the limitations of the work in the paper. Doing so typically strengthens rather than weakens the paper. The reviewers generally are quite good at assessing the work's limitations, and if these points are not conceded/discussed, then the reviewers become concerned that (1) the authors fail to see the big picture, (2) claims made in the paper may not have been assessed objectively, and (3) if the paper is accepted, others reading it will also miss these limitations. Because the program committee usually does not have any way to ensure that the authors will revise their paper to fairly assess the shortcomings of the work, they will typically err on the side of caution and reject submissions that fail to do so.

II.3 Keep Within the Page Limits .

Reviewers have to do a lot of reading. Overlength papers do not win friends.

II.4 But Be Complete

Sometimes authors, struggling to stay within page limits, leave out crucial details. A classic example is the paper that omits some proofs for brevity.

Don't leave out a critical detail. Find a way to fit it into the paper.

If there's a useful proof that won't fit in the main paper, or the paper relies on a prior work of yours that you cannot cite due to anonymity, consider attaching the proof or relevant piece of the (anonymized) paper in an appendix and referencing the appendix in the main body of the paper. This approach has the double advantage of keeping the reviewer informed and showing that the author knows how to edit his or her work down to size. A short appendix of this sort will not count against the page limits.

II.5 Write a Good Abstract .

Reviewers choose what papers to read based on the abstract. So make sure that the abstract indicates what type of paper the reviewer may expect. Each year there's usually a paper whose abstract makes it look like a systems paper, but is actually a theory paper p; causing systems people to work through the math. To their credit, the systems folks usually work through the math carefully (and vice-versa, the theory folks will read a systems paper with care) but it still means a review with less confidence behind it. Reviews with less confidence are a concern because, to be accepted, a paper often needs someone on the program committee to argue strongly for acceptance. If none of the paper's reviewers are confident of their reviews, they are less likely to argue strenuously in favor.

One long-time program committee member suggests writing your abstract to be be of interest to the committee members you believe are best qualified to review your paper.

II.6 Avoid Needless Buzzwords .

Every year seems to have a new buzzword or hot term. Sometimes authors think that having the hot buzzwords in their paper increases the chance of acceptance. Generally buzzwords don't help; and sometimes hurt. At more than one SIGCOMM PC meeting, certain buzzwords have rapidly become swear words in response to their overuse.

III. SPECIFIC ADVICE

SIGCOMM deals with certain types of papers very frequently. In this section, I give some guidance to authors of certain popular types of papers.

III.1 TCP Performance Papers

TCP performance is a well-trod ground and so the standards for getting a TCP paper accepted are now quite high.

To be accepted at SIGCOMM, a TCP performance paper should demonstrate that the proposed performance improvements have been thoroughly tested. For instance, any changes to TCP flow control should be tested over heavily loaded multi-hop topologies with cross traffic. Furthermore, the analysis should show not only that the enhanced TCP performs better, but also show the effects of the enhanced TCP on non-enhanced traffic. Note that TCP performance papers are often measurement papers and so the discussion of measurement papers in the next section applies.

III.2 Measurement Papers

Writing good measurement papers is very hard. It requires careful network monitoring, using good statistical techniques. A good monitoring paper should explain how the data was taken, why the data is believable (i.e., what statistical measures were taken to ensure the data was sound), and then analyze the data carefully with good charts and graphs and discussion that indicates the data was thoroughly analyzed and contemplated. Probably more than any other type of paper, measurement papers benefit from extra time for the author to refine the paper. Start writing early!

III.3 Systems Papers

SIGCOMM very much wants to publish systems papers. At the same time, SIGCOMM is conciously struggling with some difficulties in handling systems papers. (These problems are not unique to SIGCOMM; several journals also seem to have similar challenges). This subsection is a guide to the problems and pitfalls that may trap an unwary author.

The classic systems paper presents an implementation or planned implementation. The implementation can be in software or hardware or both. The implementation's contribution is usually that it either achieves some new function, never before achieved, or it realizes an existing function more efficiently or effectively than previously (and not just as a result of applying Moore's Law!).

It is often hard to describe an entire system completely in ten single-spaced pages. Make a strong effort to be as complete as possible. A number of systems papers get rejected because reviewers feel key details of the system are missing, details that in most (but not all) cases the authors could have provided.

Another way to express this idea is that small systems papers often fare better than large systems paper. By small systems paper, I mean a paper that tackles a modest problem and usually has a contribution that can be described in one sentence. A big systems paper is trying to accomplish a larger set of goals, and often has three or four important contributions. It is much harder to completely describe a large system.

Make sure the relevance to networking is clear. For instance, in a paper describing a wonderful new protocol verification language, it is very easy to get wrapped up in details of language syntax. Remember that SIGCOMM is a networking conference, not a language conference, and ensure that how the language improves the state of networking is made very clear.

SIGCOMM program committees have varied from year to year in how willing they are to accept preliminary papers (papers on systems still being built vs. papers on systems that have been completed). There's a tension between presenting interesting new ideas to the community as soon as possible and the danger of presenting ideas that will prove duds after a bit more testing. There is no concensus on this issue and authors considering submitting work on incomplete systems are advised to talk with the program chairs to learn the current year's leanings.

Be extra careful to cite relevant work. A common mistake in systems papers is to start with a blank sheet when designing a system. There's lots of prior experience about how to solve a wide range of systems' problems. Make sure the paper describes how it takes us to a new part of the solution space, rather than just blindly repeating prior work.

III.4 Modelling and Queueing Theory Papers

SIGCOMM believes it is very open-minded about modelling and queueing theory papers, provided their relevance to networking is clear. The first self-similarity paper was published at SIGCOMM, when other conferences found it too startling to publish. Furthermore, SIGCOMM is often willing to publish innovative work that tries to tackle hard problems, even if the resulting solution is incomplete. That said, there are three problems that frequently afflict modelling and queueing theory papers.

First, the problem being modelled or analyzed is often so abstracted from the reality of how networks operate that the results have little or no real relevance to networking. As one expert put it, too many papers look for a way to redefine a networking problem into a solvable math problem rather than actually solving the networking problem. A lesser version of this behavior is that papers often present the problem so formally that they never state how they actually contribute to networking. Don't leave the application of your work to the imagination of a tired reviewer who has already read ten papers this week.

The second problem, which is related to the first problem, is that some theory papers are really mathematics papers, masquerading as networking papers. A classic sign of such as paper is an introduction, explaining that the paper's topic has relevance to some problem in networking and then no further mention of networks until the conclusion.

Third, the traffic models are often unrealistic. It is now widely recognized that network traffic is almost never i.i.d. Yet astonishing number of papers still use i.i.d. models to analyze performance (esp. for switch performance). Unless the result is a negative one ( i.e., this switch allocation scheme doesn't work, even for i.i.d traffic), or this work is the first time anyone has even attempted to analyze a very hard problem, use a realistic traffic model.

III.5 Architectural Papers

SIGCOMM occasionally publishes architectural papers; papers that attempt to get us to think about networking in a new way. Examples of such papers are the 1990 ALF paper and the 1992 paper on Integrated Services.

The best papers present both new architectural thinking and an example of how the new way of thinking enables us to do new things, or radically reconsider existing work. For example, the ALF paper had performance numbers for combining multi-layer functions in an application.

IV. Final Comments

ACM SIGCOMM now accepts about 1 paper in 10, making it three times more competitive than the average ACM or IEEE journal. Furthermore, unlike the journal process, where authors get a chance to improve their papers and have them re-reviewed, the SIGCOMM process has just one accept/reject cycle. So it is very important that a submitted paper be the best possible paper it can be.

Finally, there's no stigma to having a SIGCOMM paper rejected. Some of my best journal papers were first rejected by ACM SIGCOMM (usually because I didn't have enough time to fix one of the problems noted above). If you've got a good idea, please send it in. The purpose of this note is not to cause you to avoid submitting a paper, but rather to help you make your paper the best it can be. Good luck!

2006-12-06T23:13:00.000-05:00

Globecom'06
Attended Globecom'06 at San Francisco from Nov. 27 to Dec. 1.
The website of the conference is http://www.ieee-globecom.org/.
The program is at http://www.ieee-globecom.org/papers.html.
I got the CD of the proceedings. Any buddy in our lab wants them, just let me know.

2006-11-10T14:31:00.000-05:00

Screen Recording Software

http://www.camstudio.org/
CamStudio is able to record all screen and audio activity on your computer and create industry-standard AVI video files.
It's free!

http://www.techsmith.com/
Better than CamStudio, while only free trial for 30 days.

2006-11-08T19:26:00.000-05:00

Putty SSH Timeouts (ZT)

If your SSH Session disconnect even if you enabled “Sending of null packets to keep session active” and “Enable TCP keepalives (SO_KEEPALIVE option)” you might want to try this:

From the Putty FAQ:
On Windows NT, 2000, or XP, the registry key to create or change is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpipParameters\TcpMaxDataRetransmissions
and it must be of type DWORD. (See MS Knowledge Base articles 120642 and 314053 for more information.)
Set the key's value to something like 10. This will cause Windows to try harder to keep connections alive instead of abandoning them.

Description of the registry key:

TcpMaxConnectRetransmissions
Key: Tcpip\Parameters
Value Type: REG_DWORD - Number
Valid Range: 0 - 0xFFFFFFFF
Default: 3 (in Windows NT)
Default: 2 (in Windows 2000)
Description: This parameter determines the number of times TCP will retransmit a connect request (SYN) before aborting the attempt. The retransmission timeout is doubled with each successive retransmission in a given connect attempt. The initial timeout value is three seconds.

If this does not work for you, you could start for example top (top –d 2, delay 2s) which should have more or less the same result.

2006-10-11T17:48:00.000-04:00

CondorTest.java
The program to query the collector to get the address of the scheduler of Condor.

import condor.*;
import birdbath.*;
import java.rmi.*;
import java.io.*;
import java.net.*;
import javax.xml.rpc.*;

class CondorTest
{
public static void main(String[] arguments)
throws RemoteException, ServiceException, MalformedURLException, IOException
{
URL collectorLocation = new URL("http://gridfarm001.ucs.indiana.edu:9618");
CondorCollectorLocator collectorLocator = new CondorCollectorLocator();
CondorCollectorPortType collector = collectorLocator.getcondorCollector(collectorLocation);
ClassAdStructArray casArray = collector.queryScheddAds("HasSOAPInterface=?=TRUE");
ClassAdStruct[] casArr = casArray.getItem();
String scheddLocationStr = new String();
int i = 0;
for(i=0; i
ClassAdStructAttr[] casAttrArr = casArr[i].getItem();
for (int j=0; j
ClassAdStructAttr casAttr = casAttrArr[j];
if(casAttr.getName().equals("ScheddIpAddr")) {
scheddLocationStr=casAttr.getValue();
System.out.println(scheddLocationStr);
}
}
}
String tmpStr="http://" + scheddLocationStr.substring(1, scheddLocationStr.length()-1);
URL scheddLocation = new URL(tmpStr);
CondorScheddLocator scheddLocator = new CondorScheddLocator();
CondorScheddPortType schedd = scheddLocator.getcondorSchedd(scheddLocation);
}
}