RX buffer has overflowed #141
Comments
|
Same message in TX side : TX buffer has overflowed ........ |
|
I'm getting the TX buffer overflow on DStar on a daily basis. The DVmega |
|
On monitoring this more closely, what I am getting is an overflow in the "D-Star RF queue". MMDVMHost is still responding to and reporting network voice headers and end of tx etc, but hangs going into idle until the network watchdog times out, when it does indeed go into idle. I'm just wondering if there's a way to "flush" the buffer when this happens - possibly the next time an end of tx is received and before the next header is rx? If this is possible, I'm not sure how flushing a buffer during reception of data will behave! I'm not sure if this is the same issue that Adrian and Daniele are experiencing, if so I'll open another issue. |
|
Example from my logs. D: 2016-09-20 02:01:50.388 D-Star, audio sequence no. 8, errs: 0/48 |
|
I've been monitoring this one for a while hoping to figure it out - I think I have a theory, which I will be testing in more depth over the coming days however, if I could ask Jonathan to answer something, it would help me understand this and maybe I can suggest a fix .... I just rebooted MMDVMHost and ircDDBgateway, so they are both in a fresh state. I then proceeded to connect and disconnect the D-Star reflectors via the android remote app. This obviously causes ircDDBGateaay to issue a voice notification. Coincidentally, the modem (dvmega in my case) was mid DMR QSO so not expecting D-Star. It reacted as expected and threw the error that it had received D-Star data in mode 2 (DMR?) My theory is that although it recognises this, it is still pushing the data to the D-Star ringbuffer which is unable to empty itself by sending the data to the modem for tx. My question is, is this possible, and if so, a simple trap to not write to the buffer when this error is thrown? (I'm just booting up my PC to have a look at the code!) |
|
Just looking at the code, the situation outlined above should be impossible. I now have another theory having managed to force an overflow on a couple of occasions ... could the data from a voice announcement generated by ircDDBGateway on connection to a reflector AND an data from ongoing D-Star QSO data combine to overflow the ringbuffer??? This is what seems to be happening in the log below ... M: 2016-09-20 19:54:46.436 MMDVMHost-20160816 is running |
|
Another overflow .... M: 2016-09-20 20:01:49.676 D-Star, received network header from KE2UK /DVAP to CQCQCQ via REF001 C |
Attempt to recover from ring buffer overflows (#141)
|
I've not eliminated the overflows, but I've managed to get the host to recover fairly gracefully by clearing the buffer when it detects an overflow. PR submitted, merged by Jon and is working for me on my DMR/D-Star setup here. I've never seen overflows in the other modes, so we'll cross those bridges as we come to them! |
|
The fix is getting a good smoke test on REF001C with this D-Star QSO party that's ongoing! Plenty of overflows due to bad network/multiple ops tx at once (and it's recovered from each one very nicely!) |
|
Not fixed with #156! See my comment below ... |
|
Over 3 hours of REF001C QSOs beating the heck out of it and it never failed. |
|
On Mon, Sep 26, 2016 at 8:10 PM Nonya notifications@github.com wrote:
I'm still getting a lot of overflows in the various buffers on D-Star. Yes I am also getting a lot of audio problems in D-Star which seem to accompany I am starting to collect some logs together (I don't normally log unless As commented in the Yahoo group, I'm not so sure the D-Star side of life is My next step once I've collected some logs is to revert my DVMega's I'm also wondering if this could be processing speed related? RPi B+ Tony Log follows (piped through grep -v "audio seq" with comments in between!) I: 2016-09-26 19:41:30.378 This software is for use on amateur radio The "cumulative error" can be forced by changing reflectors with the remote M: 2016-09-26 19:50:13.377 D-Star, received network header from KC2RXV Restarting the host resets the error to "expected 17, received 0" E: 2016-09-26 20:06:10.765 D-Star, overflow in the D-Star RF queue |
|
Using DVMEGA with firm 2.29 & Raspberry got the same issue but on DMR operation. Buffer overflow but why? I had never so this until i updated to last version of MMDVMHOST... Now... updating to firmware 3.05 the issue is still there... no fixed... What can i do? a lot of packet loss and buffer overflows on TS2.... |
|
DVMega or MMDVM? It would be handy to know ... If DVMega, there is a fix to the firmware due out tomorrow evening. Could On Wed, 28 Sep 2016, 19:26 ea8cwb, notifications@github.com wrote:
A J Corbett G0WFV |
|
DVMega firmware 3.05 is out now. Not seeing any errors so far?
On firmware 3.05 and latest commit of MMDVMHost. |
|
Now on DVMega FW v3.05 and I am still getting lots of RingBuffer overflows still and bad audio in D-Star. However - I'm noticing a pattern ..... If I dump all the logging and watch it (without paying any attention to the actual text) I can tell which streams are going to be garbled and which are going to be fine as the audio sequence debug output "pulses" - yeah I know, hard to explain. On closer inspection of the actual output when it's "pulsing", it seems as though we are receiving a packet quickly followed 1 or 2 milliseconds later by another packet followed 10-15ms later by another followed by another 1 or 2ms later again (and repeat). I'm wondering if either the spacing of the packets in time is screwing the decode in the host, or the packets are somehow being duplicated as I am getting repeated audio very frequently when it is able to decode a chunk into intelligible speech? What I would like to do is trap the data in the packet and compare it with the previous packet's data before writing it to the modem - unfortunately I've run out of time this evening, so that's a job for tomorrow ... if I can figure out how to do it. The duplication of packet data may explain the overflowing buffers though! Hey ho, we have some leads to go on .... |
|
I'd be very interested in seeing the log of one of these bad sessions with Debug=1 in the [Modem] section. The solution may well be simpler than you imagine, certainly a brute force duplicate removal should be the last resort. |
|
I'll post one when I get home this evening ... |
|
Jon, Log below .... Restart the Host then RF connect request (fine) followed by voice announcement (broken audio) followed by a couple of overs (also broken and repeated audio). I have once again reverted from v3.05 to v2.29 of the DVMega firmware due to instability experienced. |
|
Errrm ... found the problem ... It's the scrolling text on the HD44780 slowing the loop down just enough to screw things up! I disabled the display and the audio was fine and packet timings were fine. I then went into the code in HD44780.cpp and disabled the scrolling completely so I could at least have some LCD functionality - still fine! So there you go ... problem found. I think the solution may be to remove (or disable) the scrolling code for now. It would be interesting to see if this code running on the faster RPi 2 or 3 is still subject to the same issue - I've only been able to run it on a RPi 1 B and B+ |
|
Time to upgrayyyeddd! |
|
Indeed! I am back on v3.05 and monitoring the RingBuffers now the audio issues have been pinned down .... |
|
As for upgrading the hardware .... Nah! Lowest common denominator - RPi 1 with slow(er) CPU and HD44780 LCD with its slow write speed - the Skoda of the MMDVM world! I think the XYL would crucify me if I bought the Rolls-Royce solution (RPi 3 + Nextion) "just because" - I've spent enough on Arduino stuff lately (developing stuff for my other hobby!) The Zero + Nextion should be fine - it still won't be running the slow HD44780 code. My standalone RPi 1 B in the car without a screen has no issues which I just put down to the fact it doesn't get updated as often as the home-based RPi 1 B+ and was running older code without a recent problem introduced - now we know different! |
|
OK, so audio is fixed, but still getting buffer overflows ..... I'm back on v2.29 of the DVMega firmware again as, in addition to the buffer overflows, the v.3.05 FW crashes with modem loss problems at random intervals for me :( |
|
I think the overflow is related to the mmdvmhost version. With earlier versions I am not experimentating overflows or packet loss in receiving data from bm... Un saludo, Eduardo Díaz.
|
Well, it works on Pi Zero with a Nextion display. Took forever to compile it from source though. |
|
How's this performing for you now? |
|
The problem was resolved on advice from Colin G4EML, whom explained clearly the cause of RX Buffer overflow, allowing corrective action, turning of debugging in Host & FW. |
|
I don't think it's a good idea to clear the buffer when got overflowed. It's maybe a workaround the RF overflow issue, but the root cause is not there, and the change the behavior of a common class may cause unexpected side effects. |
RX buffer has overflowed
Seems to occur regardless of configuration, leaving one confused if there is an issue or not?
The text was updated successfully, but these errors were encountered: