Hi,
I ran into a problem when adding more variables to a log group. It seems I ran into a maximum number of such variables, since I had to remove others to get the new ones transferred to the cfclient.
So the question is:
* Should we increase the maximum number of variables that can be logged? - Can that be done by adjusting LOG_MAX_OPS and/or LOG_MAX_BLOCKS in log.c? - And if so, which problems could we run into wrt. transfer bandwidths/capacities?
* Could we rather have a minimum set of LOG variables enabled at all times, and other LOG variables should be disabled by default (on compile time)? - If so, which existing ones should be disabled by default?
Are there similar limits in the PARAM system (presumably very small amounts of data are transferred here)?
How to work around the maximum limit for log variables
Re: How to work around the maximum limit for log variables
Hi,
There is only one limitation to the number of log variable that I know off: the reported number of log table of content (TOC) element is 1 byte, so we can have a maximum of 255 log variables (I really should have made it 2 of 4 bytes, this is another case of "640K ought to be enough for anybody"). Are you reaching this limit?
Otherwise you are hitting a bug. Log and param are designed in such a way that there should not be any hard limitation on the number of variable, however there is a limitation on the amount of variable we can send in real time (the log blocks should be contained in a single 31bytes packet).
LOG_MAX_OPS and LOG_MAX_BLOCKS only define limits for the real-time logging. The log TOC is completely static so it is not affected by that.
I would rather fix the bug than limiting the number of log variable, they do not add so much overhead during the connection (mostly because the python client is caching the log and param TOC). But having lots of loggable variable is good for hacking.
Can you share an example file that triggers the variable-per-group limit?
There is only one limitation to the number of log variable that I know off: the reported number of log table of content (TOC) element is 1 byte, so we can have a maximum of 255 log variables (I really should have made it 2 of 4 bytes, this is another case of "640K ought to be enough for anybody"). Are you reaching this limit?
Otherwise you are hitting a bug. Log and param are designed in such a way that there should not be any hard limitation on the number of variable, however there is a limitation on the amount of variable we can send in real time (the log blocks should be contained in a single 31bytes packet).
LOG_MAX_OPS and LOG_MAX_BLOCKS only define limits for the real-time logging. The log TOC is completely static so it is not affected by that.
I would rather fix the bug than limiting the number of log variable, they do not add so much overhead during the connection (mostly because the python client is caching the log and param TOC). But having lots of loggable variable is good for hacking.
Can you share an example file that triggers the variable-per-group limit?
Re: How to work around the maximum limit for log variables
Hi, thanks for the explanation.
Nope, I am nowhere near that.There is only one limitation to the number of log variable that I know off: the reported number of log table of content (TOC) element is 1 byte, so we can have a maximum of 255 log variables (I really should have made it 2 of 4 bytes, this is another case of "640K ought to be enough for anybody"). Are you reaching this limit?
OK, then there is some bug I'm triggering. However I need somewhat more time to see what is actually triggering this, since it does not appear to be 100% reproducible. I'll come back with more info when / if I have something that can actually be debugged.Otherwise you are hitting a bug. Log and param are designed in such a way that there should not be any hard limitation on the number of variable, however there is a limitation on the amount of variable we can send in real time (the log blocks should be contained in a single 31bytes packet).