create new tag
view all tags

NetScale Blog

The NetScale blog is maintained by Prof. Striegel and his students commenting on various issues related to computer science, networking (particularly wireless networking), content distribution, and security.

Topics by focus area:

Maker Wireless

2014-08-26 - NAKFI Mid-Year Grant Meeting

NAKFI-Interview.JPG This past Friday, several of our research entourage went to Chicago for the mid-cycle meeting associated with our grant award by NAKFI (National Academy / Keck Futures Initiative). As part of the process, three of the PIs were interviewed on our grant effort as part of NAKFI's ten year anniversary. Needless to say, it was a bit of a trip with Jeff Liew, David Hachen, and myself sitting down with bright lights, makeup, and a full dose of professional gear for the interview. Fun process indeed and I hopefully came off a bit more coherent than the first few times I have done interviews on TV.

Interesting enough with three of us sitting down, both Jeff and David were instructed to look one way while I ended up looking a different way.

A few interesting tidbits from the mid-year grant meeting:

  • Paul Atchley and David Strayer had fascinating work on the mental effects of nature / hiking. Pretty sweet gig if you can get it but the takeaway was that hiking minus electronics showed a 50% gain in creativity and has been repeated multiple times. Very cool work with regards to determining the mechanism and the gains versus meditation or working out, dosage, etc.
  • Neat work out of Syracuse on using drawings to assist with learning gains by MOOCs. Basically, have students work together to draw things, iterate on it, and hopefully both improve their own learning by virtue of creating a drawing as well as that of others who gain via iterating / observing the drawing itself.

2014-08-26 - created by Aaron Striegel

2014-07-25 - On Candidate Job Talks

As promised a bit earlier this year, I wanted to offer a bit of insight on the faculty interview process, particularly based on observations from this most recent hiring cycle. For this post, I wanted to focus on the candidate talk and offer a few pieces of advice / commentary.

The "job talk" is one of the more challenging parts of the visit. You are tasked with presenting a complex topic that you have toiled on for the past N years over the course of an hour. In some sense, the hour for the presentation is both a blessing and a curse. You now have the time to properly cover your research but the longer time makes it tempting to try to cover too much or to lose focus over the course of your talk. You need to convince us that your research is both difficult but yet make it accessible enough that we appreciate it.

Depending on the size of the institution, the job talk may be the only chance for a candidate to get face time with large portions of the faculty body. While one could argue whether or not the job talk perhaps receive is overly emphasized with regards to the evaluation of candidates, my anecdotal experience has been that the talk serves a fairly good proxy for the candidate. If I can grok (understand for the non-CS folks) what the candidate is talking about and be excited about the work, there is a fairly good chance that grant agencies and reviewers will also be excited. For an institution such as my own at Notre Dame with a critical emphasis on teaching quality, it also tends to serve as a strong indicator of future teacher evaluations.

The job talk is your time to shine or your time to sink. Make the most of it. No pressure, right?

I might be a bit of an anomaly but I look forward to both giving and attending job talks. Great faculty speakers / visitors are wonderful, giving me bits of wisdom or insight that would have been quite time consuming for me to gather otherwise. It is truly a delight to see a great talk. For a few of the talks though, one sometimes appreciate the newfound digital gadgetry as a means of escape. There is a great comic from Ph.D comics on identifying faculty / student status by virtue of what one does at a seminar.

While in the next post I will focus on a few of the do's with respect to the job talk, there were a few glaring cases that stood out from our spring round of interviews that serve as good pieces of advice on what not to do:

  1. Go over time: Going over time is a cardinal sin for the job talk and a surefire way to doom your prospective job candidacy. It implies a lack of focus and a lack of preparation for the talk that tends to overshadow whatever fantastic work you might have done. For a conference or workshop talk where one is squeezed into 15-20 minutes, sure, a bit of overage is frowned upon but it is not catastrophic. For the hour-long job talk, catastrophe. Knowing that you have a full hour and significant time to prepare, it implies a lack of respect for faculty time and a distinct lack of practice. You should have your talk down to the minute and be able to vary your cadence / speed as questions and circumstances dictate.
  2. Lack of focus: For many young aspiring faculty candidates, you have a treasure trove of research available for your talk. After all, it was your research and CV that distinguished you enough to land you the interview and having a reasonable accumulation of publications was a necessary pre-condition. That being said, we don't need to see all of your research. Pick a topic (or two if you are brave) and give us a spectacular talk and vision related to that talk. Anything with three or more topics tends to be far too shallow. Moreover, having three or more topics is a surefire way to make sure you go over time.
  3. Too much ra ra, not enough research: One of the new trends that I noticed this year was that a few talks ramped up the salesmanship. While most of us are not experts in your particular area, we are in a reasonably close technical field. Hence, glossy overselling that might work for press releases, tends not to work as well for a faculty audience. While some salesmanship is a necessity these days, one should carefully aim to achieve a good balance of technical goodness with overt salesmanship / vision. Roughly 5 to 10 minutes seems to be reasonable with anything more than that tending to be negatively perceived by the faculty.

Next post, I will offer a few pieces of advice as do's for job talks.

2014-07-25 - created by Aaron Striegel

2014-07-13 - Zotac / Ubuntu

A few years back, we had picked up a few of the Zotac systems to see if they could work downtown as part of our WeHab efforts. The systems themselves were not bad, sporting an Intel Atom processor though a bit underpowered graphically. Unfortunately while the systems would not have been bad for the home setting where you have AC, the mobile cart nature of WeHab meant that the Zotacs were a bit sub-optimal. As such, I had one sitting at home to do a bit of data analysis / local Linux box testing. I had put on Fedora a while back but had meant to migrate to Ubuntu some time along the way.

The upgrade process was, shall we say, just a bit challenging to get the Zotac to recognize the USB drive.

Fortunately, the Internet is awesome.

How to Get the Zotact to Boot from a USB Stick

The missing ingredient I needed was tweaking the BIOS from an Auto setting for the USB disk to a hard drive. After that, voila, flawless installation with our cache analytics software (part of our new Whirlwind project) and the FMNC test server will soon be running shortly.

2014-07-13 - created by Aaron Striegel

2014-07-11 - FMNC - Data First Glance

A verbatim dump of the FMNC XML output that arises from a connection.

In short:

  • MeasureSetup captures packets during the initial three-way handshake, FIN, and FIN-ACK interactions
  • MeasureRcvd captures packet timing as received from the client during the test sequence
  • MeasureSent captures packet timing as sent by the server during the test sequence

Typically, a one to one mapping would be expected in terms of packets sent from the server and packets received from the client by virtue of the forced ACK behavior due to TCP Sting rearrangement. In this case, a dummy HTML file (our original HotPlanet webpage) is served up (roughly 5k) at slices of 100 bytes giving roughly 52 measurement opportunities. This all happens in under 75 ms from the original ACK through the completion of the measurements on campus WiFi.

<ConnectionTCPSlice CreationTime="1405108019.623149" SessionID="2" ClientIP="" ServerIP="" SrcPort="51661" DestPort="80" PktsTx="52" PktsRx="56" BytesTx="7932" BytesRx="3722" >
<MeasureSetup Count="9">
<PktSYN Time="1405108019.623149"  TTL="61" TOS="0" IPLength="64" ID="0x33"  OpLen="24" Options="" ClientSN="906125842" />
<PktTCP Time="1405108019.623149" Meta="SynAck" TTL="61" TOS="0" IPLength="40" ID="0x33" SN="1000000" AN="906125843" Flags="AS"  />
<PktTCP Time="1405108019.629880" Meta="Ack3Way" TTL="61" TOS="0" IPLength="40" ID="0x188E" SN="906125843" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.634726" Meta="DataIn" TTL="61" TOS="0" IPLength="408" ID="0x981A" SN="906125843" AN="1000001" Flags="AP" >
<Payload>GET / HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D167 Safari/9537.53
Accept-Language: en-us
Cache-Control: max-age=0
Connection: keep-alive

<PktTCP Time="1405108019.634726" Meta="DataAck" TTL="61" TOS="0" IPLength="40" ID="0x981A" SN="1000001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.947549" Meta="FIN-Server" TTL="61" TOS="0" IPLength="40" ID="0x33" SN="1005125" AN="906126211" Flags="AF"  />
<PktTCP Time="1405108019.952073" Meta="FIN-Client" TTL="61" TOS="0" IPLength="40" ID="0x4256" SN="906126211" AN="1005126" Flags="AF"  />
<PktTCP Time="1405108019.958594" Meta="ACK-Client-FIN" TTL="61" TOS="0" IPLength="40" ID="0x33" SN="1005125" AN="906126212" Flags="A"  />
<PktTCP Time="1405108019.958597" Meta="FIN-Server" TTL="61" TOS="0" IPLength="40" ID="0x33" SN="1005125" AN="906126212" Flags="AF"  />
<MeasureRcvd Count="53">
<PktTCP Time="1405108019.646892" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xEC34" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.647523" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x4E43" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.648913" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xED6D" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.650092" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xFC2" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.653819" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x58B4" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.653821" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xCD13" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.653897" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xE823" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.654378" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x98B5" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.655997" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x38DD" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.659003" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xA058" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.659005" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x3D26" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.659074" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x42DD" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.661238" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xACFD" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.661240" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x9CDB" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.662596" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x38C7" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.663084" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x3BD8" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.664554" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x885F" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.665796" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x2C2E" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.667790" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xE0E7" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.667859" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x313" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.669220" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x5DDA" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.669222" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x840F" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.669957" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x2BA0" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.670697" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x8B7" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.671333" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x28FE" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.673275" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xF203" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.675067" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xE66E" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.675069" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x3E1B" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.675665" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xAA0D" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.678026" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x58B2" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.678028" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xF7CA" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.679737" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xA033" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.680289" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x4D0C" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.682273" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xBD10" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.684457" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x4381" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.684459" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x373F" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.684460" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x3231" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.686765" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x805A" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.688974" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x7F5A" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.688975" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0xFB4D" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.689223" Meta="ACTIVE" TTL="61" TOS="0" IPLength="40" ID="0x76DA" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.692211" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x847" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.692213" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0xADEE" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.692385" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x8E76" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.694873" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x3D9A" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.695540" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0xDE90" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.695541" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0xBEC" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.696609" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x6343" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.697781" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0xE02" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.699648" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x5C7" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.700680" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x5760" SN="906126211" AN="1000001" Flags="A"  />
<PktTCP Time="1405108019.701775" Meta="SEQ-DONE" TTL="61" TOS="0" IPLength="40" ID="0x491C" SN="906126211" AN="1005125" Flags="A"  />
<PktTCP Time="1405108019.950890"  TTL="61" TOS="0" IPLength="40" ID="0x45DA" SN="906126211" AN="1005126" Flags="A"  />
<MeasureSent Count="52">
<PktTCP Time="1405108019.643845"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000101" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.644894"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000201" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.645947"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000301" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.646999"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000401" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.648056"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000501" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.649099"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000601" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.650149"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000701" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.651196"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000801" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.652245"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000901" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.653295"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.654343"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001101" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.655397"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001201" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.656452"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001301" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.657501"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001401" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.658548"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001501" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.659603"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001601" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.660651"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001701" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.661760"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001801" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.662797"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1001901" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.663847"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.664893"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002101" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.665943"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002201" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.666989"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002301" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.668034"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002401" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.669088"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002501" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.670141"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002601" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.671188"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002701" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.672238"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002801" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.673289"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1002901" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.674340"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.675388"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003101" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.676435"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003201" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.677492"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003301" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.678548"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003401" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.679594"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003501" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.680646"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003601" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.681700"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003701" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.682759"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003801" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.683830"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1003901" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.684866"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.685967"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004101" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.687024"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004201" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.688059"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004301" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.689106"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004401" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.690160"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004501" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.691207"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004601" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.692256"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004701" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.693308"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004801" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.694360"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1004901" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.695407"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1005001" AN="906126211" Flags="A"  />
<PktTCP Time="1405108019.696465"  TTL="61" TOS="0" IPLength="64" ID="0x33" SN="1005101" AN="906126211" Flags="AP"  />
<PktTCP Time="1405108019.697515"  TTL="61" TOS="0" IPLength="140" ID="0x33" SN="1000001" AN="906126211" Flags="A"  />
<TestSequence SeqLength="52" SliceSize="100" SliceSpace="0.1000"><Config><Predefined Setting="3" /></Config></TestSequence>

A few other observations:

  • The TTL and ID fields are set post-measurement in the current loop. For sent packets, these are not terribly exciting.
  • Spacing was 1 ms (1000 microseconds) - see the Test Sequence at the end of the file
  • Currently, a loss in the sequence adds a healthy degree of uncertainty with regards to packet matching.

In the next week or so, we will be adding in a few tweaked pieces of functionality:

  • Dedicated FMNC web page that serves up partial results to the client
  • Relative time and sequence numbers in the XML to reduce space (slightly)
  • Minor analysis blocks - embedded analytics at the tail end of the XML file
  • Bandwidth detection rather than congestion detection via different payload sizes
  • The ability to request a different objects with different behaviors (ex. GIF 1 gives you a 10k object with 2 ms spacing)

Otherwise enjoy and feel free to drop us a note if you have any questions.

2014-07-11 - created by Aaron Striegel

2014-07-11 - FMNC Is Stylin' and Profilin'

To quote the inimitable Ric Flair, WOOOOO!

Finally, managed to figure out the quirky issues as to why the TCP connections on the server side were having issues crossing the finish line. As always, it was not just a simple fix but a few little issues which fit together to make things a wee bit more difficult to debug. On the plus side, the underlying code received a fair amount of robustness while debugging the wrong things. Future programmers tweaking the code will be highly appreciative I am hoping.

At the end, it boiled down to a few relatively minor things:

  • Make sure your memory is initialized: The primary issue was with the last segment that we were sending via TCP in that things would mostly work but the ACK would fail, i.e. the stack on the other side would ACK everything but the last bit. Very odd, things generally looked OK after a few explorations of captures via the Wireshark GUI. Well, after adapting things a bit for less packets to troubleshoot, I finally decided to recheck the checksums again (that had previously been OK). Upon more careful examination, the last packet had a bad TCP checksum. Triple checked the algorithm which was correct. However, the part that I had not checked was the zero padding. For the core sliced packets, things were just fine as those packets were the "biggest" packets in the bunch. For the last packet which represented the last chunk (less than how things were sliced), the overlap between the 32-bit boundaries was decidedly not zero. Sigh. Zero padding and voila, problem fixed.
  • HTML and ampersands do not play nice: The web page even when downloaded would always freeze on a particular line, rendering on some browsers but not others. Given the previous issue, I had largely written this off as being a quirk of the last packet issue. Of course, I ignored the fact that the occurred in the same place regardless of slice sizing (see an earlier post on this whole slicing business). Tweak the ampersand correctly which was reported with a line number after I fixed the prior TCP issue and poof, good to go.

With those two issues, a bit of dancing with the FIN / ACK sequence for a proper handshake and tada, things are all set.

You can even try it out here if you would like provided that the server is up and functional. Next week, the goal is to tweak things for reporting the actual sampled data (to the webpage) but that requires a healthy bit of finishing the TCP stack which is currently a bit lacking at the moment. The TCP pseudo-stack the server uses (if you can even call it that) needs the ability to avoid terminating the connection immediately after the test as well as an ability to send data without that is not being measured.

More in a post shortly showing a few intermediate results.

2014-07-11 - created by Aaron Striegel

2014-06-26 - FMNC Server - It's Alive!

Finally, success on getting the FMNC back end to start working. While I had done a fair amount of work a while back with our RIPPS project that involved TCP payload rearrangement, it has been a while since I have been working with our ScaleBox code base. The issue in particular I had been wrestling was the TCP header construction for the out of order packet delivery, particularly following the three-way handshake and the first data packet from the client (ex. say a web client).

The TCP three-way handshake is fairly well defined:

  • The client sends a TCP packet with the SYN flag set and an initial sequence number of X. This is the Initial Sequence Number (ISN) for the client.
  • The server responds with a packet with the TCP packet with the SYN and ACK flags set (aka the SYN-ACK). The ISN for the server is denoted by Y which is sequence number for the newly responded packet. The Acknowledgment Number is set as X+1.
  • The client then respond with a pure ACK (typically) with the Acknowledgment Number set to Y+1. While it is technically possible to include data in that third part of the three-way handshake, most of the time it is a pure ACK. A "pure ACK" is a packet whose sole responsibility is to ACK a received packet which is denoted by a packet that contains a zero byte TCP payload.

From there, it is off to the data races. My client for this case had been curl as I was mimicking a web request. The issue that I had was that despite the fact that I sent a pure ACK back from my FMNC server to the Mac OS X client, my subsequent data packets were not being received correctly. I banged my head against this issue for a day as I was trying to figure out what was going on. The debug richness for the FMNC server and packet sending in ScaleBox got a considerable boost while trying to figure what was happening.

Well, after running things through Wireshark (which by the way does not detect this) and making my eyes go bonkers comparing various hex symbols, I thought, hey, why not just force the ACK flag and put in a good ACK even if we aren't really ACK'ing anything of importance. My muddled thinking was that why should I set the ACK if I am not ACK'ing anything, lest I convey / trigger Fast Retransmit (ACK with the same number three times in a row, trigger a quick retransmission) since the Fast Retransmit hat is what we are basing part of FMNC on via TCP Sting. Of course, had I bothered to dive a bit deeper into the standard rather than working from how I thought it should work, I would have seen that yes of course, the ACK flag needs to be set on all packets post-SYN. One minor tweak later and voila, tcpdump no longer grumps about sequence number marking and curl is a happy camper. facepalm.jpg

I did learn a few interesting things:

  • Evidently Wireshark thinks that if you don't have the ACK bit set, your ACK value should be zero. Would have been really nice for it to flag and note that any packet post-SYN for a TCP session should have its ACK flag set.
  • The -vvv option when doing a write to disk via the -w option for tcpdump tells you how many packets you have captured. Cool.
  • tcpdump was smart enough to figure out that I was hosing things up (not doing relative sequencing) but inconveniently would not point out where I was messing up. I was about an hour or so away from opening up the tcpdump source code on relative sequence number computations.

You are welcome to live on the bleeding edge with ScaleBox and can grab Subversion access for download here.

Look for some early results next week hopefully with some spiffy d3js graphs.

2014-06-26 - created by Aaron Striegel

2014-06-21 - ICNP Reviewing

Whew, finished my ICNP reviews this weekend. A few observations from the reviewing pile:

  • The quality overall was excellent: Either my pile was a bit out of sorts but if your paper does not make it into ICNP, do not feel too bad. Nearly all of the papers in my stack were very well written which was nice.
  • Quality papers means tons of time reviewing: Twelve papers times nearly twelve pages each (only one was less than twelve pages) meant it slammed a ton of time. That was a bit rough to say the least, particularly as many of the papers were well written and really had some nice aspects to dive into. It was actually a treat to read most of them, particularly as the theory was not overwhelming in most of them.
  • There was some overselling: There were a couple of papers that went a bit overboard in the selling of the paper. I am all for motivation and a well-done motivation can go well but overselling tends to get caught reasonably quick by at least one reviewer. There was at least one paper in the pile where the authors tried to bury the related work at the end. Not cool, especially when you get caught.
  • Better wireless energy data: There were quite a few works citing energy info from circa-2009 papers. We need some better / more recent data such that folks can stop citing those works.

All in all, a very nice experience being on the ICNP program committee for the first time. Though next time I will actually follow through on aiming to get my reviews done early.

2014-06-21 - created by Aaron Striegel

2014-06-06 - DIY Tennis Ball Machine - Wheel Structure 2

IMG_7771.JPG IMG_7772.JPG IMG_7773.JPG IMG_7774.JPG IMG_7775.JPG IMG_7776.JPG

Version 2.0 of the Tennis Ball Machine wheel.

June 6th, 2014 - created by Aaron Striegel

2014-05-31 - Tennis Ball Machine - Wheel Attempt 1

This is a bit out of date but this was the first attempt at the wheel rigged up for testing. The idea was to have something sufficiently heavy spun by the high speed electric motors.

Parts-wise, we have something like the following in the picture:

The tricky part ended up being how to get from the motor out to the caster wheel. Not being a mechanical engineer, this was just a bit of an adventure. Along the way, I tinkered a bit with 3D printing but unfortunately the ND 3D printer stopped working near the end. The end result was sort of a hodge podge of parts from Actobotics (bought from Sparkfun, love you guys though my credit card does not).

There were basically two problems: (1) Getting from the motor shaft to some sort of an axle and (2) Connecting the axle to the caster wheel. The rest was not too bad.

The first part seemed to have a fairly wide selection of parts and I ended up focusing on the second part, worried a bit about how to connect the 1/2 aluminum pipe to the caster wheel itself. At the time, I was trying to avoid using the custom Acotbotics wheels (though I have gone back to them for round 2). I ended settling on one of the 0.77 to 1.5 adapter plates, driving screws through the 1.5 unthreaded holes into the polyethylene of caster wheel, reasonably aligned by a shaft through the 1/2 (approximately) inner bearing on the wheel. The result was predictably a bit less than stellar. From the inside of the small pocket by the caster wheel, I took out 6-32 threaded screws into a 0.5" clamp that was then clamped onto the 1/2 shaft. This seemed to work a bit better though and seemed to be quite sturdy for keeping the caster wheel on the "axle" of the 0.5 aluminum tube.

With that part down, the next step was getting out from the motor. Seeing as how the BaneBots motor was not one of the kit motors, there were a slew of mounts. After trying three or four, I ended up going with the Actobotics one which was a bit more expensive but spot on. Now that the motor itself could be pinned down, on to transferring the power out from the motor. The guidelines on how to do this are how shall we say, just a wee bit on the unhelpful side. With a slew of axle / shaft adapters in, I whipped through a bunch. The most promising one seemed to go from the motor directly into an aluminum shaft. Bummer was that was a non-starter due to incompatible alignment holes. This is where the 3D printed part would have been excellent but alas, no luck. From there, it was on to clamps where a similar 0.5 clamp (two screw, not the single screw clamp) could adapt. A bit of masking tape to prevent slipping inside the clamp and the motor was on. Add a 0.5 pillow block or two and you see the result attached to MDF.

IMG_7765.JPG IMG_7766.JPG IMG_7767.JPG IMG_7768.JPG IMG_7769.JPG IMG_7770.JPG

The side holes are for mounting to a punched angle steel that I picked up at Home Depot (link coming). Ignore the awful interior cuts for the wheel.

The power itself is controlled by a relatively inexpensive PWM module (roughly $30 from BatterySpace). I ended up going with a 12V battery for around $20 from the same vendor (SLA).

A few thoughts from the operation and the first setup:

* The wheel is definitely heavy enough. It keeps spinning for a really, really long time. * The motor is definitely fast and powerful enough. Unconnected, it will easily flip when not attached to anything (full 12V because hey, gotta test it, right). * Probably too much vibration on this design. The pillow block alignment was not perfect and would need to be redone. * Next time, search better on Google. I ended up getting the original motor via eBay for $30 for both but could have gotten them for $6 each from RobotShop.

For round two, I will be switching over to an different frame and a direct drive to the wheel using a pair of Actobotics wheels. Should be exciting to compare the two.

May 31, 2014 - created by Aaron Striegel_

2014-05-29 - Prepping Our Next Paper

We are in the process of wrapping up an invited paper and were originally going to focus on the impact of probe requests from unaffiliated user elements (UEs, aka smartphones). The premise is fairly simple, smartphones tend to be aggressively tuned to pursue WiFi. One way in particular to make WiFi aggressive is to undergo frequent probe requests, aka is anyone out there? The use of a probe request will cause any APs (hidden or visible) to pipe up on a particular channel, thus allowing one to find WiFi faster versus simply waiting for the next beacon.

In short, the UE wakes up its WiFi adapter and rapidly scans the available WiFi space, 2.4 and 5 GHz for most devices (aka 802.11n). Issue a probe request (generic request, any AP), wait a small bit, hop to the next channel, rinse and repeat across all channels. Repeat the same thing for hidden APs (i.e. APs that do not broadcast via beacons and only respond to probe requests). If the UEs find a viable AP, the process stops and the UE proceeds to join the "trusted" or pre-known AP. Various UE software might also prompt the user to join the WiFi network if new APs are found.

While this process can speed up how fast you can find an AP, the flip side is that if there are no nearby APs that you can join, you keep issuing probe requests. When this occurs for only a few smartphones at home, this is not a big deal. However, imagine a dense environment where you have tens, hundreds, or even thousands of WiF devices doing this. Imagine say a stadium environment where you have thousands of APs whose WiFi range overlaps a small WiFi deployment. During scans in the 2.4 range that have plenty of overlapping channels (only 3 orthogonal ones at 1, 6, 11), not only do direct probe requests impact performance but also, probe requests on overlapping channels can also impact performance. The impact is reduced in the 5 GHz band due to there being more channels with less overlap but the problem still remains.

We have done some preliminary explorations on the impact in the 2.4 band via a few older 802.11g routers that we had. Unfortunately, we did not have a chance yet to run the experiments across 802.11n or 802.11ac APs to verify our results. As the impact could vary considerably, we ended up spiking that topic temporarily (saving it for later in the summer).

Hence, we are pivoting on a paper which has come along nicely drawing in particular on the effect of WiFi quality, namely that of the WiFi chipset / configuration on the handset. An overlooked notion for WiFi is the quality of the reception, i.e. how good is the antenna / chipset at the UE? For high end smartphones, we have seen a consistent march towards better quality where now quality is starting to match that of laptops and tablets. For the lower end smartphones, this is a bit more of a problem as cheapening the WiFi is one way to save money on a handset. As our CellNet paper back in 2012 had shown, this can be problematic resulting in flipped curves whereby cellular exceeds WiFi. Our paper is focusing on that particular interplay, exploring how taking the same students from the cohort in the NetSense study and giving them phones with better WiFi (the campus WiFi remained largely unchanged) results in dramatically different WiFi consumption, approaching if not exceeding the two-thirds estimates from prior works. The most interesting part is that consumption tended to continue unabated when on LTE which was quite fascinating.

Hopefully we can toss up an arXiV link soon with the paper as well as a few d3js graphs to show off several of the results that Shu had cooked up before she graduated.

2014-05-29 - Maker Summer Project: DIY Tennis Ball Machine

Near the tail end of the spring semester, I started to do a bit of dabbling into the 3D printer space. Beyond the fact that the CAD programs of today are nothing like AutoCAD from back a while (cough, nearly two decades ago, cough), it was basically programming.

This spring, I had coached my son's tennis team and of course, longed for a tennis ball machine. Now, rather than buying one, this was a perfect excuse to build one with all sorts of embedded and wireless features. A side project of the blog will be to highlight the progress (or regression) of the machine over the course of the summer.

May 23, 2014 : Prof. Aaron Striegel

Example Post: Inaugural Post Blog Template: Blog Template Create new item
Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | More topic actions
Topic revision: r13 - 2014-08-26 - AaronStriegel
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback