Temporal Latency

http://spreadsheets.google.com/ccc?key=0AjbHDjXctNgDdDhpWEIzT3JLVnB5WkpZUnRrSlRsWnc&hl=en

This is the average ping between a peer and its neighbors in milliseconds.

To Do - 1/28

I can't believe January is almost over!

Yesterday, didn't get as much done as I wished, as family visited me at work and took the train back with me. So the To Do list is quite similar:

• Try to run with a larger dataset (nodes63), and see if you can get the non-waiting ssh to return immediate errors anyway.
• This seems to be working http://spreadsheets.google.com/ccc?key=0AjbHDjXctNgDdEVPYnp5d1Vna0tfZ0UzbU5zRzRIVGc&hl=en but still has strange issues... why do some nodes not reply with a port? UDP packet shaping? Annoying. Also, some peers aren't writing their file out, implying a crash. I have a mind to just remove this consistently misbehaving servers; were it random, I'd really need to look further, but as I'm just trying to scale and get data, I should probably just remove those servers from my slice/nodelist. In fact:
• Extend the worker to run in 'test' mode, which tests a server for viability. If it fails to accomplish all of the pieces, reject it.
• Make the QUIT command broadcast to all a peer's neighbors
• Start varying the inputs (number of peers) and see what changes

A wee bit of analysis

Looking at the data has provided me a world of insight into what my network is really doing:

• Even though the computers are supposed to be ticking every .1s, and hence writing data out, some computers are only ticking every .5s, implying that the work required in the algorithm takes longer than 100ms (this is surprising... those computers must be rather slow). This means I should at least run with -O3 optimized versions, rather than my current -O0 unoptimized builds. If this is still a problem, I need to work on improving the efficiency of the code.

To Do - 1/27

• Try to run with a larger dataset (nodes63), and see if you can get the non-waiting ssh to return immediate errors anyway.
• Start varying the inputs (number of peers) and see what changes

To Do - 1/26

Ah, real data. Here's a longer dataset: http://spreadsheets.google.com/ccc?key=0AjbHDjXctNgDdFBVSzFWNmNWbDc3bkxlcklHWnp1T0E&hl=en

• √Find out why bad data is getting written out... even though there are asserts!
• make sure udp messages are working correctly by sending two messages to a worker, and testing that two reads happen...
• √Run the workers repeatedly, trying to identify some of the malformed output errors.
• Done, and fixed.
• √Modify analyzer to spit out unprocessed data as a spreadsheet (peer x time), so as to graph the raw data, rather than just the processed data.
• Start varying the inputs (number of peers) and see what changes

Actual Data!

Got through all of my asserts! Woot!

I have actual data on my machine.. this is terribly exciting. I'm able to parse the data without hitting any asserts, implying that my raw data makes some kind of sense. My current analysis techniques are a bit lacking, though, so I'm not going to put up my final data just as of yet. I'm going to work now on the analyzer, and make it spew out a spreadsheet-like data format first... I'll put it online @ google spreadsheets and put a link here when I do this. Done: http://spreadsheets.google.com/ccc?key=0AjbHDjXctNgDdG8zbVd6LTJtdDdQaDdjQmdXU3ZSa3c&hl=en

To Do - 1/25

Ah... good weekend. Back to work!

• Find out why bad data is getting written out... even though there are asserts!
• √Add this sanity checking to the writing of the data in worker. Add a flag to enable it. Put the functionality for it in an inline function in shader.h
• try running the worker in some kind of test mode on each server
• make sure udp messages are working correctly by sending two messages to a worker, and testing that two reads happen...
• Run the workers repeatedly, trying to identify some of the malformed output errors.
• Modify analyzer to spit out unprocessed data as a spreadsheet (peer x time), so as to graph the raw data, rather than just the processed data.