[nos-bbs] trace files

[George [ham] VerDuin]

You are asking good questions Michael.


On 09/22/2010 04:00 PM, Michael Fox - N6MEF wrote:
> Thanks Skip.
>
> I was also just told by someone else that JNOS buffers before writing to the
> file and that it will eventually write.  But how long/much does it buffer,
> who knows?  And for what possible purpose?
The purpose is to reduce the I/O workload.  A flurry of trace data put 
out to the file one packet at a time [requires a physical read & write & 
read-back for verification] kills slow [think old] computers dead.  
Trust me? -- you really do want some form of buffering.  Not too long 
ago I bought a DOS based computer with software that did unbuffered 
[think minimal like one record] reads and the 9600B interface never hit 
anything higher than 17 characters per second.  That was a project killer.

> I sent several pings, waited a
> minute or so, and still no output.  That makes it impossible to diagnose a
> problem that's occurring in real time.
>    
Well you and I may not see this in the same light.  I've seen too many 
important packets tumble off the top of the page before I have a chance 
to review and think thru what is happening below.  Real time can be 
useful, but please think thru the options before you reject buffered I/O.

> You say below that Linux buffers the output.  But other linux logs don't
> seem to be delayed like the JNOS log. Other logs I review show the events as
> they happen.  How do you know it is Linux that's delaying the write and can
> it be controlled (reduced to 0 or a small value)?
>    
I do know Linux can be told not to wait at the source code level.  As I 
recall, not-waiting is not-default behavior and no-wait takes a little 
more effort.  I have not looked at the source, but my experience tells 
me that the buffer is fairly large, certainly longer than a few pings in 
a few minutes time.  If you are dedicated to this issue, you probably 
can adjust buffer size and eliminate wait with re-programming or 
re-configuration.

You mention other logs -- good subject.  Logs like syslog need to record 
to file quickly in the event of an OS failure.  I suggest that JNOS 
doesn't need such quick performance because the OS is not crashing when 
JNOS gives up the ghost.  While the OS handles the termination of the 
JNOS task, it writes all buffers to file allowing a pretty good 
postmortem short of gdb.  NOW!  It is worth comparing my statement to 
experience -- so let me know if you find I'm off base.

> I see no value in delaying the write to the file output - only problems.
>    
Are you not a convert?

> <<SNIP>>
>
> Michael
> N6MEF
>