live api input buffering ? / strange latency issue

Hello Everyone / anyone , hope all is well.

I have been working with a new system that involves a teensy code that is encoding a mixture of boolean and float data from varius sensors as an array of different osc messages and sending at 50hz over a 5g network and received via the udp-receive object in max, the messages are then unpacked with OSC-route and sent to various other amxd's maybe around 50 or so throughout my set, the messages in most cases are then mapped into live via the live api.

the problem is that the input data seems to be buffering , the system in total has 2x the teensy and 5g tx feeding 2 seperate udp objects , with a total of around 50 inputs of a mixture of the boolean and floating, the floating inputs are the ones that generally cause the issue, though after the problem starts the booleans are also effected.

i have been experimenting with different maxqueuesize arguments , as my college who wrote the code suggested that in an ideal situation we dont want any queuing and from a design perspective we would sooner see dropped packets for this application.

so ive been working with a maxqueuesize of 15 , this did improve slightly , but the problem still persists.

for example i have one of the accelerometer axis mapped to a dial in an actual ableton plugin for example beat repeat via the api objects , and after some time of running the set with transport playing and constantly running all inputs at once the input begins to lag and after i stop the physical movement stops with the accelerometer , the dial still shows the remainder of the *buffered packets as they come threw .... and in worse cases , the input continues to be buffered untill it shows no refresh at all in locks up and becomes unusable , also if i turn off one of the systems feeding either one of the udp objects the problem also disappears , it seems to be the combination of the 2 systems data that is causing this queuing / buffering, as if i was to run one system from the start its impossible to create this issue.

although i have the queue on nearly nothing , and note this still happens with a maxqueuesize of 1

so it seems maybe there is some secondary buffering going on within the api objects , or something similar ?, i can only assume that because live does not support OSC and was engineered to deal with consumer midi input devices and that this midi protocol is based on some kind of max input rate ?

The reason i say this is because im able to pretty much eradicate the issue by adding a speedlim 50 on the accelerometer data line just after the accel/ argument is unpacked , on one of the teensy systems , inputs but i know this is kind of bad practice and id really like to have my code working / designed to suit what im trying to interface with in this case the live api.

so my question is, is there any secondary buffering or am i just completely making this up in my head .. am i missing something here ? if there is any limitation on the speed that the data can hit the live api , can someone please direct me to this information or explain it to me ive really been looking everywhere.....
and if i was to change my codes send rate of 50hz on the floating inputs to something slower would this help solve the problem ? (im going to try this today)

also i have been looking for the scheduler settings for amxd's ? namely event interval refresh rate and etc , as ive been told to look into these settings if the issue was something solely in max , not m4l.

another side note is i usedto have this same issue with my old system with completely different hardware and firmata for similar tasks sent over 2.4 xbee.

apologies if my terminology is not so great , and thanks so much anyone willing to give me some advice here !!

thanks for your time.