TxBuf

[olliw42]

there had been plenty of discussions around this topic, which is spread now over many places. This discussion thread is intended to centralize the efforts in one place, namely, here :)

the last place of such discussion was in #47.

[brad112358]

However, I didn't liked your suggestion since it can then happen that a stroke of many messages are injected, and this to me doesn't make sense. So one would need some state machine to prevent that

Yes, that would be bad, but it can't happen because you already have a state machine and the first time it happens, you change states so it can't repeat for at least 100ms (actually longer because the buffer has to drain first)

I guess I then don't unerstand the change you want to make :)

I'm not sure how else to explain it so I worked up a PR to show what I mean. It also includes changes to the bounds, expanding on what I suggested for BURST_HIGH. #62

I have attached before and after logs for tests run at 57600 baud with the default settings of QGC and sr_parms set to 50
before.log
after.log

Note the improved rate recovery time after parameter download completes

[olliw42]

@brad112358

many thx for this, but I must admit I'm getting somewhat frustrated, as I don't see how that ever can converge.

It seems obvious that the idea of BURST and BURST_HIGH was not grasped, and the mechanism has been broken by turning it into a simple two-level response. I don't know for how often more I should have to tell that it's not sufficient to have a mechanism working only for the most simplest setup of a FC and a GCS only. MAVLink allows for much richer setups, and it is in fact one of the main benefits and use cases of MAVLink that it does. Our goals do not appear to coincide in this matter.

Additionally, I doubt that your two logs have been recorded for comparable situations. First off, I have never seen that many high_burst (and yes, I also tried QGC). And it just does not make any sense that with "my" code the system is constantly fighting to shut off the params and slowdown streams dropping txbuf = 0 like hell while with your code it easily gets along only having to occasionally drop a txbuf = 0, if the situations were comparable. I very much doubt the data and experiments.
(and the claimed "improved rate recovery time after parameter download" is really just a corollary and not a feature at all)

I certainly like your experiments with this, I really do, but I also really suggest you put that under the option "brad". I understand that this name for that option you may not find optimal, and we should change it to something better. We also may want to advertise this option better in the docs, to encourage folks to try it out.

What I do read off from your tests is that the issue with the previous ardu_1 mechanism, that it could too easily fail (lots of message loss due to buf overflow), as you've pointed out, does not happen anymore that easily. I thus for moment consider it "mission ackomplished".

Not sure that makes somewhat sense, but I hope it does.

[brad112358]

Olli, I'm sorry you are frustrated, but I'll admit I'm confused and frustrated by your response. We shouldn't be adversaries. I think our goals do coincide.. One of us just seems to be missing something. I hope it's not me, but perhaps it is. I think it might be productive to have a video chat again. I'm busy for the next 3 hours, but I should be available after that and for most of my day tomorrow.

Unless I messed something up, PR 62 just changes some of the bounds and eliminates some possible delays. I can't see any reason it won't converge.

I did this PR because you said you didn't understand what I was suggesting in the last part of our discussion in #47. I'm not assuming you will adopt it. I'm just showing you what I tried and what I saw and I certainly didn't fabricate the data as you seem to suggest!

[brad112358]

@olliw42

I switched to a more modern FC and updated to the latest released Ardupilot, Copter-4.3.4 (The logs I sent were with my old Pixhawk and V4.3.3). I still see the same behavior as in before.log. At the risk of stating the obvious; Are you running an unmodified Ardupilot release? Or do you, perhaps have your 1/3 bandwidth fix included which I don't have? What do you have SRx_PARAMS set too? Have you considered buffering and latency?

Since I have SR1_PARAMS set to 50, I believe Ardupilot should be attempting to send 5 parameters 50 times per second which would more than fill the 5760 bytes/sec capacity of the serial link. This means the ardupilot serial output buffer will be near full all of the time which causes buffering latency. In addition there is a small latency to stop parameter flow due to serial port transmission time of the radio status message. Also since the released version of Ardupilot tries to buffer 5 parameters at a time, the check for txbuf <=50 effectively happens only every 5 parameter messages.

All of the above mean that we shouldn't always expect parameters to immediately stop the instant we send txbuf=50. Thus, the behavior I see in before.log should be expected! The logs show it is common with my setup for more than 400 bytes (likely mostly buffered parameters) to be received after we try to stop parameter flow by sending txbuf=50. This is why it makes sense to set the "high" threshold to be larger than the burst threshold as I have done.

If you are not seeing the buffer grow after entering burst mode, your FC must not be sending parameters as fast as mine is. Note that both buffer and serial transmission latency should be reduced at higher baud rates which might help in this example.

Does this clear things up at all?

I'd still like to have a call to chat about this and one or two other things if you have time.

[brad112358]

the option "brad". I understand that this name for that option you may not find optimal, and we should change it to something better.

Indeed. How about "Other" or "Alternate" or just "method2"?

[olliw42]

@brad112358

I do run both Ardu4.3.4/5 (no 1/3 correction) and Ardu4.4.0-dev (has 1/3 correction included). Concerning before I just could repeat what I said. My experience and understanding is very different. I find txbuf = 50 to cut of params essentially immediately (except of 5 or so which had been buffered, but 5x37 = 185).

we sure can have a chat, I respond to the PM in the other thread :)