Custom Query (104 matches)

Hello,

A lot of client on our ntripcaster professional (version 2.031) observed a lot of disconnection during 20 minutes. On the different log of the ntripcaster we saw only many disconnections (but not all the connections, maybe 60% of disconnections). There is no more connections from clients or sources which let thinking to a saturation of the 2101 port. We thinking on an attack but the analyses done by the network team said that there was no attack. A system analysis was done also, but the différent limits wasn't reach by the system. So we suspect an issue on the ntripcaster, Have you ever seen this behavior ?

Hi. We have seen an issue with Galileo week rollover when we use BNC (2.12.10) to log the RTCM v3 straight to RINEX. We are getting message types 1045 and 1046 for Galileo, and for both we see in the RINEX files written by BNC that some messages received just after the week rollover (i.e. early on Sunday morning) have week number increment by 1 but the toe is still a high number (e.g. 604000) and the toc jumps forward by 1 week. I attach an example file when you can see this for E01, E05, E15 and others. From what I can tell, the receiver manufacturer is simply putting the week number of the message (i.e. when it was received) in the WN field in 1045 and 1046 and expecting that the user of the RTCM data will modify this as necessary (allowing for rollover) to derive the reference week number of the toe and toc, but this does not seem to be happening. Can you check how you are using the WN field in the 1045 and 1046 messages and confirm the correct interpretation of the RTCM standards? Thank you.

We have run into an issue with relays reconnecting to sources that go away and then come back. Our relevant configuration is:

relay pull -i u:p -m /RTCM3EPH products.igs-ip.net:2101/RTCM3EPH

max_clients 10000 max_clients_per_source 1000 max_sources 40 max_admins 2 throttle 0

max_ip_connections 1000

I'm going through the code trying to understand how timeouts to read connections like this would be applied. Is there some configuration we're missing that could help us recover quickly?

We had a recent outage where our BKG relay did not recover after a relay source went down for 15 minutes - the BKG relay stayed down for 2 hours, while our other caster (a SNIP) recovered the stream after 15 minutes.

Any advice in debugging this would be very appreciated. I'm thinking about adding a setsockopt call with SOL_TCP and TCP_USER_TIMEOUT on the sockets to improve timeouts.