What I should do in the future
Prefix all my C functions with nsc_ so I don’t pollute the global namespace.
Move NSC into a shared library that is loaded dynamically by ns-2.
Prefix all my C functions with nsc_ so I don’t pollute the global namespace.
Move NSC into a shared library that is loaded dynamically by ns-2.
Starting to move kernel-specific stuff into support2.c. Work progressing slowly, not all of the stuff is particularly clear cut. Still, its coming along and sim_support.cpp is somewhat cleaner now.
Though on the whole things are nastier and will be for some time prolly
Hopefully in the long run things will be much better.
Making progress with sim_support.cpp. I’m actually getting some stuff sorted out that I had been meaning to change for ages: timers.cpp was a C++ file with 2 lines that weren’t in an extern “C” – even though they should have been! It is fixed now though.
I wish cvs had the ability to move a file. I’ve had to delete timers.cpp and create timers.c. How stupid. Maybe it’s time to move to subversion.
Arg. Tried to finish of the performance section, but got nowhere. I just didn’t know what to concluce from my results. They didn’t make too much sense.
So well… I decided to port to Linux. I really wanted to get it finished today. I am hoping I will be able to use Valgrind and fix any remaining bugs. I will then be able to hopefully be able to use gprof – either because its just stuffed on FreeBSD or because the bugfixes allow it to magically work.
Well, that is the idea. Of course, porting to Linux is no simple thing…
The afternoon is gone and the all the kernel code compiles and most of my support code compiles.
Difficulties appear with libc. Basically, I can’t use FreeBSD kernel code type stuff and have it coexist happily with stuff that relies on libc if that libc is to be glibc. So I need a very real separation of kernel-reliant code and plain ANSI-C/C++ code. That requires some big changes, however: the main problem is support/sim_support.c, though a couple of other smaller files pose some problems as well.
Oh well, this requires a bit more thought and work.
Related work done. Performance section mostly done.
make wordcount Approximate word count: 1692
Introduction largely done. Related work section outlined. Just need to write more now, its coming along slowly. Short day today. Cold day today. Make up time elsewhen this week.
make wordcount Approximate word count: 733
What I saw yesterday I am fairly sure was basically random loss. I modified NS-2 so I could run simulations like what is presented in Sally Floyd’s paper, but they weren’t interesting at all. I actually think the description of the setup in the paper is quite bad.
A bit more work writing stuff for my paper, I now know what is going in the intro. Should prolly write this and methodology section, these wont take too long I believe.
Took me a long time to find out how to use a normal distribution and how to delay packets with said distribution. I’m doing that now and the results look good, even though the simulation is far from what I had originally intended. More on this later I guess. There seems to be quite a difference between NS-2 and FreeBSD, but maybe I’m just hitting the same sort of behaviour as random loss…
The Advances in Network Simulation article I have a pdf for somewhere is actually in the IEEE Computer magazine in 2000 – of which we have a copy in our lab. That’s useful. It had a good quote or two on it.
Did a little more on my research proposal. Almost finished.
Need to sort out my performance tests at some point…
Research proposal almost finished. More papers read. Got results from performance measurements. More on this all later…
Got a bit of work done today. I’ve turned my eye towards completing those performance measurements at last. But, of course, they take a while to run and I can’t do anything else on the computer when I’m waiting for them. So that is what I am doing right now.
Waiting.
I’m also upgrading my home FreeBSD box to 5.2.1. This means waiting for buildworld to complete before I can do anything useful. The load average is currently at 14 or so. For some reason my last count put it at 14 cc1 processes. That shouldn’t be the case for a make -j4. Hmm….
Tony sent me notice of a possible journal: Internet Performance and Control of Network Systems.
Updated the auto graph thing to be a little more useful. Wrote more of my paper outline. Really needs more work. More results would also be great: doing that one mentioned in the S. Floyd paper on my desk would be a good idea… varying latency: haven’t done that yet.
Made my graphs PHP script able to auto generate some graphs, so I can see them being created as the simulation runs. This is especially important when I’m working from home, as I don’t really want to X forward gnuplot from Uni.
My newest graph is where I graph packet loss rate vs. throughput. This was done in the paper RR-TCP: A Reordering-Robust TCP with DSACK. That paper is showing NS-2 SACK vs. their SACK, but I thought the idea was a good one. If only FreeBSD had sack so I could show how it performed in comparison… At any rate, the graph can be found here.
Next: Write a paper. Write an outline at least in the coming week.
Do some better performance measurements.
Spend 1/3 to 1/2 a column on the implementation: mention algorithmic transformation and the major issues: initialisation, etc.
Maybe talk about the implementation at a later date in Software Practice and Experience journal.
I’ve found there is greater difference in the 1% random loss simulation than in the 5% random loss simulation.
There is a difference of rougly 14% for the 5% packet loss simulation, while there is a difference of 18% for the 1% loss simulation. I tested all the different variants of TCP NS-2 has to offer, and they all do similar stuff; if anything the other TCP variants just are further away from NSC (which is what I expected, but it was worth checking).
So. It is interesting there is more difference with 1% loss. Should investigate a little more.
The IEEE/ACM Transactions on Networking looks like a possibility. Bi-monthly journal. I think this probably fits into its scope, it is fairly broad.
SIGCOMM would have been ideal, but paper submission was due February 6, 2004. INFOCOM happens March 7-11 2004, paper submission was due July 1, 2003, 24:00 PDT. ISCC 2004 – THE NINTH IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS – deadline was 5 December 2003, conference is June 29 – July 1, 2004. ICNP – 12th IEEE International Conference on Network Protocols – Paper deadline May 7th, 2004. Looks like it might fit in its call for papers.
Hacked Wordpress so now text I put in < pre > isn’t double-spaced. It was adding extra < br / > to all my preformatted text, which doesn’t need to extra spacing.
ACM Computer Communication Review INFOCOM ACM Computer IEEE/ACM Transactions in Networking (bi-monthly journal)
… and more …
Setting up an emulation for the 5% random packet loss scenario. IPFW lines as follows:
machine4:~ $ ipfw pipe 1 config bw 2Mbit/sec queue 10 delay 100ms plr 0.05 machine4:~ $ ipfw pipe 2 config bw 2Mbit/sec queue 10 delay 100ms plr 0.05
Note: I initially forgot the delay 100ms in the lines above! Had me confused for some time
This makes pipe 1 and pipe 2 have a packet loss rate of 5%. These work on the following rules:
machine4:~ $ ipfw show 00010 270 20168 allow ip from 192.168.2.1 to any 00020 143 14380 allow ip from any to 192.168.2.1 01000 0 0 pipe 2 ip from 192.168.3.2 to any out 01100 0 0 pipe 1 ip from 192.168.6.2 to any out 65000 16 880 allow ip from any to any 65535 0 0 deny ip from any to any
Hopefully this works correctly. There was difference in results between ns-2 and nsc, more on that later and results from emulation perhaps…
Check out this graph. I think it is 5% packet loss or something. I may be wrong… It needs more investigation: The graph itself
NB: This graph had 5% loss in one direction and 10% in the other (ack) direction. Not interesting really…
Powered by WordPress