Subject: Re: [sip-clf] New CLF Syntax draft (text with index)

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jun 2009 14:50:28 -0400

Howdy,
Sorry for being late in draft comments.  Ingenious concept to encode it in ascii, and all, but I do wonder about the overhead in all this.  Personally I don't care that much about how much work it will be for the decoder/tool to read a CLF file, as much as I care how much overhead it is for a SIP device to generate the CLF.  A few extra instructions overall to help the reader-tool out is ok, but extra instructions/work per field is pushing it.  So my comments will probably seem obvious:

1) Encoding the field contents with terminating TAB characters is not only an extra instruction per field content, but also involves an entire scan of each field content to replace real TAB's with spaces/whatever.  At least if the goal of the encoding is to make it usable by text-parsing tools, without taking the length values into account. (is that the goal?)  This was exactly the type of thing we were trying to avoid by using binary encoding to begin with, I thought: not having to search the received on-the-wire header content for the "special" character we use for separation, to escape/replace it.

2) Encoding the pointers/lengths in hex-ascii is an extra itoa(val,16) type of function per length/ptr field.  I have no idea how much real work that is, but it's work that I don't have to do.  It also makes the file larger, since a 2-byte value is taking 4-bytes to encode.

3) This is sorta a nit, but the entire record length can be ~280 Terabytes, if I'm doing the math right.  Obviously it's up to the logger if it ever wants to record that much, but I have a hard time really imagining the need for anything beyond 4GB (ie, a 32-bit value).  So if we can encode binary as binary, the record length field could reasonably be 32-bits instead of this 48-bit thing.

IANAE, but I think most systems these days are memory-constrained for performance, rather than instruction-contrained (i.e., accessing memory is the bottleneck, not instruction cycles).  So I don't know how much of the work above is really noticeable work for systems, except for the scanning of content issue.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adam Roach
> Sent: Thursday, May 07, 2009 2:56 PM
> To: [email-masked]
> Subject: [sip-clf] New CLF Syntax draft (text with index)
> 
> This version defines a text format in which each record is composed of
> two lines in a log file. The first line is primarily pointers into the
> second line. The second line contains the actual logged fields,
> separated by tab characters.
> 
> This approach retains the fast-search capabilities that I've been
> advocating, while allowing the use of simple, text-based tools, as Vijay
> has been promoting. This hybrid approach does come with a slight
> increase in log file size; for example, writing out the same 100,000 log
> entries in each of the three formats proposed so far:
> 
>    - Text:   25 Mb
>    - Binary: 29 Mb
>    - Hybrid: 37 Mb
> 
> This is about a 20% premium over the binary format, and a 48% premium
> over the text format. Speed of generation should be on the same order of
> speed as the other two versions, and speed of processing should be
> approximately the same as processing binary.
> 
> The new version of the document can be found here:
> 
> http://tools.ietf.org/html/draft-roach-sipping-clf-syntax-01
> 
> /a
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf