[Ns-bugs] [Bug 933] Flushing ostream and files on abnormal program exit (ASSERT, ABORT and FATAL_ERROR)

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=933





--- Comment #21 from Craig Dowell <craigdo at gmail.com>  2010-06-04 13:18:16 EDT ---
I'll make a few final comments and then fade back into the background.

1) There is a generic problem with trace file flushing that appears in several
contexts.  The most troubling case to me is when a memory leak in a completely
unrelated area prevents pcap logging from working correctly.  It would be good
to deal with all of these contexts in one go.

2) Simply always flushing all of the streams all of the time is too simplistic
and raises performance issues; but when we want the streams flushed, we are
debugging a problem of one form or another.  So it seems reasonable to have a
simple switch to flip to force the streams to be flushed to give us more
information when we decide the performance impact is less important than the
data.

3) Adding an explicit flush to our trace code deals with the problem in all
cases including signals like control-C and memory leak.

4) Adding exception handlers to flush the streams addresses the problems in a
case-by-case basis, but doesn't cover all of the cases (memory leak case
especially).

5) When I am debugging a crash, I don't want the system running around trying
to salvage things before it stops.  I want it to simply stop without changing
anything and let me see exactly what state things were in.  I don't have any
problem with throwing a segmentation violation, BTW.

I think that explicit flushes with an on/off switch as a global variable is the
most straightforward way to address the issue; and trying to do the work in an
exception handler is more complicated than necessary and doesn't address all of
the cases.  The same treatment as the flush on write could be easily applied to
ascii traces if we decide they are equally important to have flushed.

My $.02

---------- Benchmark Data ----------

I did some benchmarks involving examples/csma-star which is our example that
uses tracing the most.  There is a roughly 20% increase in execution time when
a pcap flush bit is turned on there (about a half-second difference on my
machine from 3 to 3.5 seconds to run the example).  This isn't an intolerable
time if it lets one see previously lost data, IMO.  However, this is a humanly
noticeable difference, so we shouldn't just leave the flush bit on all the time
(although I could appreciate a case for leaving it on in debug code).

I also did micro-benchmarks looking at the effect of the flush on packet
writing.  I wrote a thousand packets to a pcap file looking for how long it
took; repeated this 50 times to get a good minimum; and looked at 100-byte and
1500-byte packets.

The answer, of course, varies with the average packet size.  not buffering
small packets causes much more of a problem than large.

Flushing on every 1500-byte packet takes about 48% more time (in the pcap write
method) than letting the buffer cache work.

Flushing on every 100-byte packet takes about 7 times as long as just letting
the buffer cache work.

This indicates that a flush control bit is needed -- the performance impacts
are, as expected, not small enough to ignore completely.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.