To clone the parallelized ns-3 branch you can type the following: hg clone http://code.nsnam.org/pfeifer/ns-3-para # after some days you can update the repository via hg pull http://code.nsnam.org/pfeifer/ns-3-para # and update the local copy hg update BTW: to push the changes upstream type: hg -v push ssh://[email protected]//home/pfeifer/repositories/pfeifer/ns-3-para
Because of massive flaming I reintroduced the TCP Option to netsend again. But this time not via the normal commandline options (this SHOULD be implemented as well), in opposite I introduced a new option “-O “. The “O” option (like Output) is introduced to replace the current machine parseable output. The advantages are clear: the current machine output use a fixed standard format that cannot be reordered or shrinked because of backward compatibility....
Netsend supports now the MD5 socket option (TCP_MD5SIG) for TCP based sockets. This options was introduced to protect long running TCP sessions like BGP RFC 2385. The exchanged digest are introduced to hold a shared secret and prevent spoofing attacks. Only several applications utilize this option - netsend nowadays do also! ;)
today in the evening I received the following bug report for libhashish (especially the bloom filter implementation): [...] ../include/libhashish.h:116: syntax error before "pthread\_rwlock\_t" ../include/libhashish.h:116: warning: no semicolon at end of struct or union [...] Looks pretty forward, but hold on! One line above in the spotted code are some tricky compiler forward declarations so we checked this first with some older GCC versions - no success. After that we focused on glibc and their threading support for older versions and voilà: some today really outdated glibc versions (especially the linuxthread ones, the NPTL predecessor) require to define a additional constant....
Libhashish is a hash library for UNIX witch support nearly all functionality seen in other hash table implementations. Furthermore, libhashish implement a lot of different ideas beside the normal hash list chaining strategy. It implement array chaining, list and array chaining with reordering functionality (most often referred elements first) and double key hashing (to lower O(n) complexity in the hash key compare function (normally strcmp()). Yesterday I added mutex lock support so that the library is now thread clean!...
Netsend RX and TX code-paths for the DCCP and TIPC protocols are now re-implemented. They where adjusted because of the new parser engine within netsend. svn diff -r 177:178 https://svn.berlios.de/svnroot/repos/netsend/trunk For the small patch.
I reworked the netsend commandline parsing code. It now support a more network specific user input. See the following screenshot for netsend help: Usage: netsend [OPTIONS] PROTOCOL MODE { COMMAND | HELP } OPTIONS := { -T FORMAT | -6 | -4 | -n | -d | -r RTTPROBE | -P SCHED-POLICY | -N level -m MEM-ADVISORY | -V[version] | -v[erbose] LEVEL | -h[elp] | -a[ll-options] } PROTOCOL := { tcp | udp | dccp | tipc | sctp | udplite } MODE := { receive | transmit } FORMAT := { human | machine } RTTPROBE := { 10n,10d,10m,10f } MEM-ADVISORY := { normal | sequential | random | willneed | dontneed | noreuse } SCHED-POLICY := { sched_rr | sched_fifo | sched_batch | sched_other } priority LEVEL := { quitscent | gentle | loudish | stressful }
We removed the rdtscll instruction support in netsend: userland header files doesn’t define the macro anymore (sanitized header files) functional aspect is limited (ACPI modes and the increased time/cycle time) nobody used it ;-)
Through some additional performance measurements I realize some interesting plateau. Two points are of interest, first at ~200 byte and the seconds at 600 byte (the x scale is denoted as DWORD size (uint32_t) Also quit interesting: the long duration to “warm” the cache, tlb, etc .. (BTW: we talk about microseconds)
New measurements for the mentioned, increased latency if you lock pages physically. As you can see, the violet line (without memory locking) reflect a superior latency behavior (lesser is better). On the other side, there is one negative peek with mlockall() - but it shouldn’t. After all: mlockall() prevent worst case scenario - the principal task for real-time application. On the other hand, it introduces a small overhead - but why?...