There is a tool called SCNMPlot which, like jPlot, is an xplot replacement written in Java. This time, it features the ability to overlay multiple xplot plots. So it can overlay a couple of graphs generated by tcptrace! Wish I had found this earlier.
It’s a bit slow – unsuprising for a Java GUI app – but seems to work well enough.
Thesis writing links:
I’ve read a few thesis introductions now. Read a few on Friday and browsed a couple this morning. There seem to be a few different approaches taken. Mostly introductions look to be the least formal (as expected) and often include a subsection on the contribution the research makes to the area.
Started looking into thesis writing. Need to read other peoples introductions next. Working on preparing something to commit to subversion that has latex styles set up correctly and so on. Prolly worth getting this right now.
I have measured traces from a Windows XP SP2 box connecting to both a FreeBSD 5.3 and a Linux 2.4.27 box.
A few of the SACK blocks in Linux looked weird; there were sack blocks below the acknowledgement line: this does make sense, however, it is the D-SACK algorithm working.
FreeBSD, however, does something weird: it has a selective ack block from below the acknowledgement number to far above it (like, 80% of the window or something). This looks like broken behaviour to me. If it can selectively ack that region, from below the ack line, then it should be able to do a full ack for that region! Why doesn’t it? I wonder if I’m missing something here.
And yes, windows is still sending lots of packets outside of the receivers advertised window, no matter the receiver. Crazy. Crazy crazy crazy crazy.
NB: Windows as a receiver looks fine. No big suprises there; all the TCP complexity is on the sender side anyway.
Pam submitted, Linux 2.6.10 random loss test seems to show that it is in a good state.
Now I’m back to needed to decide exactly what to do. Blast.
There is a minor timer fix needed for Linux 2.6 in simulation. Should do that before I forget.
I guess I should continue running emulations to get a better feel for what windows is doing. Also, attempting to see why tcpperf gets so weird numbers would be a good idea.
winxp, iperf:
Number of data points: 50 sum: 6865
Five number summary: 89.900000 124.000000 137.314000 150.000000 191.000000
Standard deviation: 21.670878
winxp, large windows, iperf:
Number of data points: 100 sum: 14340
Five number summary: 94.200000 129.000000 143.402000 159.000000 187.000000
Standard deviation: 19.095263
Using iperf, WinXP:
Number of data points: 50 sum: 51198
Five number summary: 906.000000 982.000000 1023.960000 1060.000000 1152.000000
Standard deviation: 58.515988
Need to validate our other results with iperf. Doing that with freebsd 5.3 now.
FreeBSD 5.3, iperf:
Number of data points: 50 sum: 62083
Five number summary: 1128.000000 1198.000000 1241.660000 1272.000000 1366.000000
Standard deviation: 52.834207
I’m seeing Windows XP do some crazy things. I have some traces where winxp is sending packets outside of the receivers advertised window! Yet it all seems to work OK. I can’t explain that one…
It also does weird things with packet sizes; I’ve seen it send strange small packets at times I can’t understand. Windows XP w/ Service Pack 2 doesn’t do TCP timestamps. Huh. Never would have guessed that one. It might be that it supports them, but defaults to having the option turned off, but if so, I can’t see any registry setting to enable them.
tcpperf and iperf seems to get somewhat different results on my reverse path congestion test. Not sure why? I have set the socket buffer size with both of them to be about the same thing. Using iperf now; it gets somewhat more throughput and is somewhat more trustworthy than tcpperf.
I do think tcpperf is mostly good, though, I did calibrate it against iperf in other cases. Will need to do a few further tests and note whatever conclusion I come to. Should really get these results correct.
So now that it is building quite happily, I guess I can say I’ve updated to 2.6.10. It will need testing of course. There is always the possibility of some small change having nasty side effects. But things should probably be as they were for 2.6.9. Hopefully I can conclude this as another happy upgrade.
Updated parser to support asm syntax fully. Had to brush up on my grammar design once again. Seems to work well without any shift/reduce conflicts now.
Here’s an interesting one. Given that same code fragment again:
/* how to get the current stack pointer from C */
register unsigned long current_stack_pointer asm("esp") __attribute_used__;
The parser will turn it into:
typedef register unsigned long _GLOBAL_24_T; _GLOBAL_24_T current_stack_pointer asm ( "esp" ) ;
That is invalid code. Apparently it must be:
typedef unsigned long _GLOBAL_24_T; register _GLOBAL_24_T current_stack_pointer asm ( "esp" ) ;
The register cannot be part of the typedef. OK, sure. But that has some nasty ramifications. Handling of storage class specifiers to make them part of the declaration and not the typedef will not be fun. I could perhaps gloss over the issue, but I’d like a robust solution. Hmm. We’ll see…
No, I’m wrong. I had, of course, already added support for the other storage class specifiers (static, extern, etc.). I just added register to the list. For some reason, register isn’t in the stogage_class_specifier rule in the grammar, though. It’s a type_qualifier instead. I wonder if there is a reason for this? Oh well, it works now, so no reason to change it.
After getting screenfulls of error messages, I went back and remembered to initialise the property which marks a node as “register”. Now it looks like it is working.
Here’s some annoying code:
/* how to get the current stack pointer from C */
register unsigned long current_stack_pointer asm("esp") __attribute_used__;
asm on the line of a variable declaration. Huh. Didn’t know you could do that! My parser doesn’t understand this correctly. It uh, treats asm as whitespace. Heh.
I’m not quite sure how asm should be parsed – I guess in this case it is the same as gcc attributes, where otherwise it is a statement. This makes parsing not as simple as it could be. Ahh well. Working on the parser is always…. something. Fun? I dunno.
Linux does do PR-SCTP after all. Might be worth looking into simulating this.
Maybe. Need to sort out priorities.
I guess fixing up Linux 2.6 should still be the goal for the short term.
Now running: * WinXP with larger windows (64k) * Linux 2.4.27 again (to validate new emulation machines vs. old) * FreeBSD 5.3 with iperf (to validate tcpperf)
Guess it is going to take a while to run these tests. On to something else now.
Still unsure about iperf’s reporting of the default window. The code looks fine, but it reports values that don’t quite seem to match up with what I expect often. Might have to do some further research at some point…
Update
Ahh, so the sizes returned by getsockopt with SO_SNDBUF and SO_RCVBUF can be different after accepting a connection or similar. I guess they should really only be printed out after a connection is established. Note that this will happen when connecting back to localhost certainly; in that case you get around an extra 8k on FreeBSD 5.3. Not sure if it changes otherwise yet, looks pretty good…
Results from the emulations mentioned in the previous article:
* FreeBSD 5.3-Release
Number of data points: 100 sum: 17620
Five number summary: 136.774000 165.301000 176.202190 188.130000 225.006000
Standard deviation: 17.116080
* Windows XP Service Pack 2
Number of data points: 100 sum: 9349
Five number summary: 53.922000 86.562000 93.490110 104.718000 131.880000
Standard deviation: 15.123545
* Linux 2.6
Number of data points: 100 sum: 21398
Five number summary: 164.379000 198.228000 213.983090 228.130000 287.674000
Standard deviation: 22.754653
After a lot of stuffing around, I finally have tests running. 3 in tandem. * FreeBSD 5.3 * Linux 2.6 * Windows XP SP2
Looks like FreeBSD has made a gain with 5.3 and sack, not sure about 2.6 just yet, but looks good so far, and Windows gets terrible performance.
Really need to do some work in the weekend to continue with further testing. Wonder if I should bother with solaris 9? Might be a bit of a mission. And it really should be on powerboard machines.
Got windows xp going alright on the emulation network.
Debugged the cygwin networking code to be sure that tcpperf is working how it should. It all looks reasonable to me, cygwin doesn’t do any particular magic for sockets.
Improved tcpperf so it can output the size of SO_SNDBUF and SO_RCVBUF. It seems that Windows XP service pack 2 defaults to TCP buffer sizes of 8k. That is tiny!
Fixed tcpnorm to actually normalise time again.
Ran winxp tests and analysed tcp traces somewhat. Looks like TCP now. Maybe closer to BSD than Linux is. Not sure. That is just a hunch. At any rate, I have started real tests on the emulation network for the bidirectional loss scenario.
Looks like Windows XP is going to be the loser. At it’s defaults with the small buffer sizes it seems to get around 80kb/s (compare Linux 2.4.27 with 207kb/s). With larger windows it seems to get around 113kb/s. Still lower than OpenBSD, our previous loser. These are only preliminary results though, I’ve have something more conclusive after the weekend hopefully.
Also, I am about to begin running these tests with FreeBSD 5.3. Need to remember to turn SACK on. Actually, it is on by default.
Oh yeah, when I ran my initial tests with windows on the emulation network on a normal 100Mbit/sec link going through freebsd firewalls, with tcpperf I was only getting 7.7Mbit/sec and the connection looked like it was in stop-and-wait according to the graph in tcptrace. Looked much better with iperf. Was this due to send window size? Receive window as obviously ok. I tried upping the buffer sizes in tcpperf, but it didn’t seem to make a difference. I don’t know. Things are looking ok now on 2Mbit/sec networks. Maybe the machines just needed rebooting?
Managed to cut down my abstract to 4 pages. That meant removing a lot of content. Maybe I can re-use that stuff somewhere else or something.
Only 1500 words left in the abstract. That’s tiny!
I might do some more tests on the emulation network, I can at least report what windows does.
I’ll have to put my simulations on the backburner for a little bit. Got a reminder about PAM yesterday, I have 1 week today to get everything sorted. Realistically, it shouldn’t take too long, but I should do this earlier rather than later. So the process goes like this: * Read over old draft, convert to new formatting, decide how much space I have * Try and identify what stuff should stay/go * Decide what more tests, if any, to run on the emulation network (I think I should just go an test windows XP ASAP, if nothing else)
Wonder if it is worth updating my tests to use the newest versions of everything? Software moves too fast.
There is something very wrong at the moment. I’ve done some basic tests with iperf and sometimes tcpperf on the emulation network and compared to simulation. Everything is quite different and I’m not sure why just yet.
With Linux 2.4.27 on the emulation network using tcpperf and I found that the receivers advertised window is quite a bit larger in emulation. This results in a bit of loss at the start of the connection. In simulation it seems to be limited by the receivers advertised window, which is quite small (26k or so?). I think it was 40k or so im emulation.
With Linux 2.6, in simulation, there is loss every 2 seconds or so due to congestion. In emulation, there is the initial bout of loss then it seems to just send at a fairly constant rate. It doesn’t look to be limited by the receivers advertised window, it is perhaps send window limited or something? Maybe it is iperf’s fault. I should go check that now.
Yeah, iperf had set the sender window to 16k or something. Why would it do that? Anyway, they look somewhat closer now; both get periodic bits of loss. However, they are still significantly different I think. This may well be because the emulation model of the network is not close enough; this looks reasonably likely at this point. More analysis of this can follow tomorrow.
Powered by WordPress