TCP over UMTS — looks like some technical report (420 type thing?). Actually, Masters thesis. They compare TCP versions of ns-2 over some UMTS model (doesn’t seem to be the one normally included in ns2). Might be fun to reproduce some of their simulations. In the future they say that the code will be on the website (July perhaps).
Right, so my optical simulation stuff is basically going.
In an attempt to debug it, I thought I would generate a NAM trace. Due to the high bandwidths encountered, the NAM trace ended up being 2GB for just 5 seconds of traffic.
I fixed NAM so it understood nanoseconds first. Then tried using it. Not much use. The output window was hopelessly cluttered by the buggy LAN drawing. So I thought, “I’ll hack the file so it just draws normal nodes, instead of special LAN stuff.”
The problem: I need to edit a 2GB text file. I tried in this order:
vim, emacs, nedit, nano, kedit
They all failed, to cut a long story short. I think the way to do this is extract the part of the file you care about, edit it, then compose the original file back together somehow. In the end I tried using sed, which kind of worked, but was too much hassle to use to do the editing I wanted.
When simulating with the LAN stuff in ns-2 (the wireless stuff uses some of the same structure too), the physical layer is simulated with the Phy class. This had a bandwidth_ field which I naturally assumed was the bandwidth for the physical layer!
Nope. Looks like the actual bandwidth_ used is in the Mac class. I spent quite some time playing around with the bandwidth stuff in my new physical layer and was wondering why it wasn’t effecting the simulation at all. Put in quite some debug code and went about chasing red herrings.
Thank you ns-2.
Seems to be like the bandwidth should be in the Phy. I’m going to have to make my own Mac sometime soon anyway, so I have the choice which bandwidth parameter to use!
Wavelength striping and reassembly is working in Phy/SwiftPhy. The logic used to do reaasembly will need revisiting, need to check how this works in the real thing.
Delay set in the newSwift function or via SwiftNode set delay_ foo sets the delay_ variable of the LL (link layer). The delay_ in the Channel (or really Channel/SwiftChannel) seems to be 0.
Mac/Simple is possibly what we want to begin with. It just sends a packet if it can and receives a packet if it can. Basically, it handles serialising the packet and dropping any packets that come in when in the process of serialising. This is worth revisiting at a later point, but it sounds good so far.
Changing MAC from Mac/802_3 to Mac/Simple increased the RTT by a couple of ms. That shouldn’t happen! …….. Mac/Simple sucks, it adds a huge jitter in when sending to try and avoid collisions – it was over a millisecond on my 1Gb or 800Mb link, not sure which. Even when hacked to have no jitter, it is still 500us slower than Mac/802_3. Haven’t investigated why yet, and I see no reason to – I might as well go ahead and start implementing my own MAC (was going to eventually anyway). To begin with it will be even simpler than Mac/Simple. Actually, just simple Mac will do for now.
Why isn’t Phy::recv virtual?!?!?!?
I’m going to have to hack it so it is.
I needed some way to organise my notes again. So I turned back to my trusty blog. Since I’m working on optical networking related stuff, I thought I’d even call the category Optical Networking.
At the moment I’m looking over a journal publication titled, “Labeled Optical Burst Switching for IP-over-WDM Integration.” This was written back in 2000. It states “one major challenge is the current lack of optical random access memory.” You can say that again! In fact, we are looking at a completely bufferless network in the work I’m doing.
The next challenge is stated so: “Another major challenge is the stringest requirement for synchronization, both between multiple packets arriving at different input ports of an optical switching fabric, and between a packet’s header and its payload.”
I write this sitting on the couch in my flat in Cambridge under the influence of some real jetlag. Feeling pretty damned tired right now. Mostly been good today, so can’t complain too much though. I did go to sleep around this time – 8:30pm – last night. That was mostly because I hadn’t slept in a bed for about 3 days.
Perry pointed me to the Hamilton Institutes high speed TCP testing stuff.
Need to make up some slides before next week. And figure out my phone number for the call to NZ.
Powered by WordPress