NetTalk Central

The Rest Of NetTalk => The Rest - Ask For Help => Topic started by: Simon Kemp on February 11, 2020, 09:15:06 AM

Title: NetOptions / NET:GETSTATS - information on queued incoming data
Post by: Simon Kemp on February 11, 2020, 09:15:06 AM
Hi Bruce,

Apologies if it's documented somewhere but could you shed some light on two numbers in the typed NET:GETSTATS group :-

qSimpleInData_Bytes and qSimpleInData_Size

Our situation being that we have small packets (maybe 500 bytes at most) streaming in and occasionally a backlog develops then clears. We'd picked on qSimpleInData_Bytes to monitor for more serious problems. It seems to work in 16684 increments (16k + some control information?). Would 10 of these small packets result in 166840, 100 result in 1668400 etc - or is it more complex? I'm trying to get a handle on "how much data is actually queued-up" - these are apps dealing with FX market rates and of course the customer needs everything to be "instantaneous"!

Hope this makes some sense.

Thanks, Simon
   
Title: Re: NetOptions / NET:GETSTATS - information on queued incoming data
Post by: Bruce on February 24, 2020, 10:52:40 PM
Hi Simon,

qSimpleInData_Bytes = = size (qSimpleInData) * records (qSimpleInData)
meaning it's the number of records in the queue, multiplied by the record size of the queue.
Since the record size is currently 16 K, you see what results.

However this number is misleading. Since C5.5 Clarion does runtime-length-encoding on queue strings. So this number is a "worst case" size, not an actual size. It's not like 4 records in the queue consumes 64k of actual Ram.

qSimpleInData_Size returns the number of records in the queue.

So, I'm thinking the qSimpleInData_Size is the useful one to you. This is the "number of transactions waiting to be processed". Given that your transactions are small it's unlikely they will overflow into 2 16K packets.

cheers
Bruce


Title: Re: NetOptions / NET:GETSTATS - information on queued incoming data
Post by: Simon Kemp on March 23, 2020, 12:14:25 AM
Thank you Bruce.