[Orca-dev] Couple of minor updates - make sure I'm not smokin'something

[Sean O'Neill]

Blair Zajac wrote:
> Sean O'Neill wrote:
> 
>>Curious if folks could qualify my assumptions for some modifications
>>I've made to the orcallator.se script.
>>
>>TCP per Packet "Data" Size:
>>http://www.seanoneill.info/orca/o_gauge_tcp_InDt_per_p,o_gauge_tcp_OutDt_per_p-hourly.html
>>
> 
> 
> Hi Sean,
> 
> This link is broken.  In fact, the entire site has broken links.
> The home page has broken image links.

Yeah, I haven't rebuilt my web page total since moving back to the DC area.

> 
> This looks like good stuff.
> 
> 
>>This attempts to show how big the data payload is for each TCP packet
>>both for incoming and outgoing.  This isn't computed with the time
>>interval in mind.  This is purely taking the amount of data
>>received/transmitted during the time interval and dividing that by
>>number of packets received/transmitted.  This only shows data payload.
>>It doesn't include the 40 bytes of IP and TCP header.
>>
>>With this in mind, it is very possible to see the TCP Bits/Sec graph
>>showing 0 or very close to 0 bits/sec *but* this graph (and the graph
>>below) showing data.
>>
>>This graph computes data as:
>>
>>TCP Incoming Data Payload size = tcp_InDataBytes / tcp_InDataSegs
>>TCP Outgoing Data Payload size = tcp_OutDataBytes / tcp_OutDataSegs
>>
>>TCP per Packet Header Overhead (%):
>>http://www.seanoneill.info/orca/o_gauge_tcp_InOvH_pct,o_gauge_tcp_OutOvH_pct-hourly.html
>>
>>This graph takes the payloads computed above and figures out how much of
>>the packet was "overhead".  So:
>>
>>TCP In Overhead = 100 * 40 / ("TCP Incoming Data Payload size" + 40)
>>TCP Out Overhead = 100 * 40 / ("TCP Outgoing Data Payload size" + 40)
> 
> 
> I would probably calculate this using the original data instead of
> the "> TCP Incoming Data Payload size" and it's a little clearer.
> 
> TCP In Overhead = 100 * (40*tcp_InDataSegs/(40*tcp_InDataSegs+tcp_InDataBytes))
> 

Hair splitting but no problem - I'll tweak it.

> 
>>This may be useful for those cases where a server is servicing an
>>application but you don't really know how but the data payload is and
>>how much of those packets of overhead.  For instance, a chat service or
>>  SSH service is generall going to have a small data payload with a lot
>>of packet overhead.  An FTP service would generally be the opposite -
>>max data payload and very small overhead.
> 
> 
> Yes definitely.
> 
> What also would be interesting are these statistics on a per port
> basis.  This would be harder data to gather, unless we could get
> per port data from orcallator.se.
> 

Yep, already thinking about that.  Just wanted to get a comment or two 
on the logic and then apply the same to the interface code.

I think that code would be added to orcallator.se in the measure_net() 
function and an Orca specific p_netstat_class.se script would need to be 
added to lib/SE/[23].[32] directories.  I need to look at the 
p_netstat_class.se code a bit.

At the interface level, it only collects packet in/out and bits in/out 
without qualifying the protocols but this would still be very useful 
data - IMHO.

> And also, of course, you could do this with UDP also.
> 

Well, not really.  The mib.se code doesn't provide a lot of information 
relating to UDP.  All I saw in /opt/RICHPse/include/mib.se is for the 
following for UDP:

mib struct mib2_udp_t {
   uint  udpInDatagrams;  // # of UDP datagrams sent upstream { udp 1 }
   uint  udpInErrors;     // # of recv'd dg's not dlvrable (other) { udp 3 }
   uint  udpOutDatagrams; // # of dg's sent       { udp 4 }
   int   udpEntrySize;    // { udp 5 }
};

Curious if anyone knows what udpEntrySize means ?

/usr/include/inet/mib2.h shows basically the same structure for udp 
statistics - nada mucho.

> Do you have the patches available for review?
> 

Well, let me tweak based on your suggestion and add in the interface 
code then I'll submit for review.

Sean