Opened 7 weeks ago
Last modified 4 weeks ago
#218 new defect
Technical Support: High RAM usage/data drop issues and mountpoint relay failures in BNC 2.13.2+
| Reported by: | Owned by: | stuerze | |
|---|---|---|---|
| Priority: | normal | Component: | BNC |
| Version: | Keywords: | ||
| Cc: |
Description
Dear BKG BNC Support Team,
We are currently encountering two critical issues after upgrading from BNC version 2.13.1, and we would appreciate your guidance or any suggestions you can provide.
Environment Details:
OS / Environment: Ubuntu 24.04 running inside Docker containers.
Execution: We run BNC in no-window mode using the -nw option (generally launched as /opt/bnc-[version] -nw -conf BNC.ini).
Working Version: 2.13.1 (and v2.13.2 for the relay feature)
Problematic Versions: 2.13.2 & 2.13.4 (RAM issue) / 2.13.4 (Relay issue)
Server Specs: Tested across multiple environments, including a 256 GB RAM / HDD setup.
Issue 1: High RAM Usage and Data Drops (v2.13.2 & v2.13.4)
When running BNC 2.13.2 and 2.13.4, the application begins to ignore incoming data, and its RAM usage climbs exponentially—reaching up to 100 GB on our 256 GB machine.
Here is some information regarding this:
We do not experience this issue in Version 2.13.1 under the exact same load.
We initially thought this might be related to HDD disks not handling the I/O load, but version 2.13.1 works perfectly with the exact same HDD setup.
We have replicated this RAM issue across different machines running the same Ubuntu 24.04 Docker setup.
While it happens consistently with a large number of mountpoints, we have also occasionally experienced it when testing with a low number of mountpoints.
The issue appears significantly more likely to happen if the casters are accessed via a secure port (e.g., 443, 2102).
Has there been a change in how BNC handles internal queuing, threading, or secure port connections in no-window mode within these newer versions that could account for this memory accumulation?
Issue 2: Mountpoint "Relay" Feature in v2.13.4
In version 2.13.1, we successfully used BNC to relay a specific mountpoint to an internal service. Our configuration relied primarily on the following options:
mountPoints
casterPort
miscMount
miscPort
This setup allowed a downstream service (for example, running str2str -in tcpcli://my_server:port/MOUNTPOINT) to successfully listen to and consume the relayed mountpoint.
As of version 2.13.4, this functionality has stopped working for us.
The incoming data works and can be seen in a file if the outFile option is used
Could you please indicate if there was a change to how miscPort / casterPort broadcasting is handled in the latest release, or if we need to adjust our configuration format to achieve the same result?
We would be happy to provide our configuration files (BNC.ini) or bnc log outputs if that helps diagnose the issue. Looking forward to your insights.
Many thanks for the help in advance,
Best regards,
Attachments (2)
Change History (7)
follow-up: 2 comment:1 by , 7 weeks ago
comment:2 by , 7 weeks ago
I have attached the configuration file with all the mountpoints that work ok in 2.13.1 but haven't been working with the latest versions (it has been tested with a reduced (~half) list of mountpoints from the ones present in the config file)
Regarding the relay configuration, I have attached the configuration (BNC_relay.ini) too. I don't understand how these decoder strings should be applied in my configuration; the incoming stream is RTCM, but I should replace this:
mountPoints="redacted:redactedb@euref-ip.be:2102/SUN600SWE0 RTCM_3.0 NON 0 0 no 2s"
by this?
mountPoints="redacted:redactedb@euref-ip.be:2102/SUN600SWE0 ZERO NON 0 0 no 2s"
So it just redirects the raw data? Am I understanding correctly?
Thanks again for the help
comment:3 by , 7 weeks ago
Yes, 'ZERO' redirects the raw data.
W.r.t. your configuration BNC.ini:
- The user 'redacted:redacte' seems to be unauthorized?
- For the pency entries no user and no port is given?
I would recommend to configure bnc in window mode if possible.
I will have to look again at it within the following days. I'm on a jump to a long business travel.
Best regaards, Andrea
comment:4 by , 5 weeks ago
- The user 'redacted:redacte' seems to be unauthorized?
Yes, I have removed my credentials and used "redacted:redacted" before publishing this information here.
- For the pency entries no user and no port is given?
For pency no user:password is needed, it should work as is.
We can't execute in window mode as we are running it inside a docker container.
Thanks for the input, I will try to test out the ZERO option.
comment:5 by , 4 weeks ago
I have checked the source code of BNC regarding memory leaks and we have the latest version running by ourself within longterm applications with permanent access of about 100 RTCM streams. But I cannot confirm such behavior.
Regarding BNCs Ntrip Server Functionality please have a look at
https://software.rtcm-ntrip.org/export/HEAD/ntrip/trunk/BNC/src/bnchelp.html#upraw
In case of any problems it would be helpfull for us to have an example config + raw file
https://software.rtcm-ntrip.org/export/HEAD/ntrip/trunk/BNC/src/bnchelp.html#rawout
to reproduce the miss-behavior.
Best regards, Andrea

Hello,
regarding the RAM consumption it would be great to get the respective configuration to test it with the latest version of BNC.
regarding the "Relay" Feature please have a look at https://software.rtcm-ntrip.org/export/HEAD/ntrip/trunk/BNC/src/bnchelp.html#miscport because there are now two decoder strings
'ZERO' (forward the raw data) or
'ZERO2File' (forward and store the raw data)
available.
Hope this helpts. Otherwise please attach the configuration as well.
Best regards, Andrea