This is a syntax highlight test.
#include <stdlib .h>
int main(int argc, char *argv)
{
/* This is a comment */
printf("Hello world!n");
for(int i = 0; i < 10; i++) {
printf("i=%dn", i);
}
}
import sys
# Comment.
if __name__ == "__main__":
main()
def main():
print "hello world!"
for i in range(0, 10):
print "%d" % (i)
sys.exit(1)
Just a test < of some text>
in a <>pre
Open source TCP Implementations:
Other things of note:
Perhaps look around on what stack goes in next.
I don’t know if the current situation is perfect or anything, but it is probably “good enough” to move on. So I need to decide what stack goes in next. NetBSD? It was used for that land-speed record, after all. Consider other options. Check what will be easiest to move into simulation.
Up until packet 1000 (or just before, maybe 985) things are pretty much as good as they are gonna get. I think the remaining problem is probably to do with my induced loss, I imagine there is still a bug in which packet is being picked to be lost somehow.
I’m not worried about that, though. I did another test without packet loss and it wasn’t too bad. I need to just check numbers now to be sure that I’m close enough to really not worry. Seems fine.
Been getting weird inconsitent results from emulation today. No idea what is up!
There still seem to be problems… Around packet 1000 or so. It looked like a loss in the ack direction was stuffing things up. I don’t see how this can be wrong though.
Rebooting router machine now… Let’s see what happens.
Upgraded to WordPress 1.2 just now.
Also changed the style a lot. Things look quite different now! Not sure if I like it or not.
The new color scheme is based off the excellent color scheme I use in Vim: desert.vim.
I’d still like a plugin or something for WordPress that allows me to put code in my posts and for WordPress to not try and intepret the tags in this code. It would also be cool if I could get it to automatically do syntax highlighting on the code or something (an external program could possibly be called to do this… though that does sound quite inneficient).
The large differences are fixed up as this graph shows.
The perl code I use to extract which packets to drop from the nam trace was wrong slightly. The new code follows below.
Also I had to re-run the simulation because my current nam file was wrong. “Bug fix 1″ was before I re-ran the simulation. “Bug fix 2″ was afterwards.
open(SAM,"<out .nam");
@lines=<SAM>;
close SAM;
#@fwd_drops = [];
#@rvs_drops = [];
$forward = 0;
$reverse = 0;
foreach $line (@lines)
{
if( $line =~ /^d.* -s 1 -d 2 / ) {
# Drop in the forward path
$forward++;
push @fwd_drops, $forward;
} elsif( $line =~ /^d.* -s 2 -d 1 / ) {
# Drop in the reverse path
$reverse++;
push @rvs_drops, $reverse;
} elsif( $line =~ /^+.* -s 1 -d 2 / ) {
# A normal packet in the fwd path
$forward++;
} elsif( $line =~ /^+.* -s 2 -d 1 / ) {
# A normal packet in the reverse path
$reverse++;
}
}
print "int fwd_drops[] = {n";
foreach $i (@fwd_drops)
{
print "$i, ";
}
print "n};n";
print "int rvs_drops[] = {n";
foreach $i (@rvs_drops)
{
print "$i, ";
}
print "n};n";
The first big difference happens where we see 2 packets in simulation and only one in emulation. I just need to figure out why this difference is happening. Should check the packet trace on the sender (that was measuring from the receivers point of view) and see what is going on now also. This happens between seconds 10 and 12, at packet number 142 or so.
Time to figure out why things get out of sync. Is it the sequence of packet loss? Or something else? It is hard to imagine anything else effecting it, as the first 10 seconds of traffic are just fine.
I ran the longer test again and got pretty much exactly the same results!
Time to investigate why the line looks like it does.
Should check the exact sequence of packet loss in simulation vs. emulation now. The graph in the previous post does kinda look like something changed there…
I should also run that experiment again and see if we get similar results.
Here’s a bad graph made in gnumeric2.
I couldn’t get gnumeric to put anything useful on the x-axis. Suffice to say that it shows about a minute of traffic, the first 1000 or so packets. The y-axis is in seconds. Simulation is quite a lot faster here. But look how it changes, this comes completely unexpected. Not quite sure what to conclude from this graph just yet, but it is certainly an important bit of information.
I analysed the first difference in the graph above and produced this. I wonder if this sort of difference is indicative of something out of the ordinary happening…
Preceeding this period the graph looks like this. Note that there is not a huge downward trend. There is a downward trend, but it is small. Things look as expected here, I wonder why it changes in the graph in the paragraph above.
Most of my current investigation has been into if there IS a problem and/or why such a problem exists. Looking at the first 100 packets or so shows around 30ms difference. Notable, but not huge. In fact, the trend looks like it isn’t going to get much worse.
Looking at over 1000 packets reminded me that is still gets entire seconds out of sync. And it doesn’t get out of sync in a linear trend or anything, it is fairly chaotic. After looking at that graph I have to conclude that something is wrong. How can it be any other way?
But… What? I still don’t have any leads on what it might be. I need to somehow concentrate on an avenue which will put me in the right direction to answer this question. I do still think its worth spending some time on. Getting this sorted would be very nice.
NB: Is simulation faster now? By how much? Should get some raw bandwidth measurements out and compare to what I had when I published my paper.
Emulation machine 23
reset tcp_timer_rexmt: 2100 ticks at 43893 43893 : 1085363035.202492 reset tcp_timer_rexmt: 566 ticks at 44034 44034 : 1085363035.404549 reset tcp_timer_rexmt: 576 ticks at 44248 44248 : 1085363035.709392 reset tcp_timer_rexmt: 575 ticks at 44462 44462 : 1085363036.015226 fire tcp_timer_rexmt: 45037 45037 : 1085363036.836703
Normalisating the above gives us:
ticks: time: duration
0: 0.000: 2100
141: 0.202: 566
355: 0.507: 576
569: 0.813: 575
1144: 1.634: fire
Simulation stack 1
ticks: time: duration
1: 0.001: 2100
142: 0.203: 563
355: 0.507: 573
504: 0.720: 503
1007: 1.439: fire
Gotta instrument the kernel to tell me how long the retransmission timer was set for. Need to get the same info out of simulation.
My latest graph follows. I have run it in the opposite direction so the machines are switch around. I’ve been rerunning HZ=100 quite a lot, there seems to be quite huge amounts of jitter in this case.
Machines upgraded to 5.2.1 sucessfully. Gnub is better for this change. Serial on machine4 was broken until I got the ACPI module working correctly again — how incredibly random!
Running on a different machine seems to show quite different results, at least with respect to HZ=500 and the delayed ack timer.
Next:
I don’t seem to see the strange 500HZ delayed ack difference when I do things in the reverse direction. That is when there is the other machine doing the delayed ack timing. This is quite an important result. Some of the bad timing may be due to the machine being crap. Need to investigate this more.
To my knowledge in the HZ=500 case, the timer gets set at the right time and goes off 50 ticks later. Which should be 100ms. But when we look at the packet timestampts, this is not the case. Instrumenting the kernel did seem to produce different results, but they were even worse — 100ms turned into 180ms or 160ms or something. I dunno.
But check out my new and updated graph.
As far as I can tell, the results there are pretty chaotic.
TODO:
Powered by WordPress
