Custom Query (105 matches)

Hi,

I noticed that old GNSS week and TOE is provided for many BeiDou satellites and also for Galileo PRN8.

See log as an attachment.

Best regards, Altti Jokinen

Bug report from Jun Shih (Jun.Shih@…)

=========== first message =================== I have seen the following ntrip server reset condition in my log: [02/Nov/2010:21:26:43] [22:Source Thread] add_chunk: hex [], read=21 [02/Nov/2010:21:26:43] [22:Source Thread] add_chunk: http chunk left=0 [02/Nov/2010:21:26:43] [22:Source Thread] DEBUG: Source received 0 bytes in try 2, total 0, errno: 0 [02/Nov/2010:21:26:43] [22:Source Thread] Didn't receive data from source after 800 milliseconds, assuming it died...

A bit debugging found that this caused by the "http chunk left=0" condition, the recv will return 0 because recv length parameter is zero (con->http_chunk->left - read_bytes =0) in source.c:663

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes, 0);

when len=0, subsequently maxread=0 as well. These cause the while loop to terminate on line 737 or 744. I believe this code is the same as 2.0.14.

=========== second message =================== But in my case connection is not shutdown (I can see from wireshark). Note that recv returns 0 if the length parameter is zero (which is not undocumented in the manual) and it does not return -1 in this case. I have attached a sample program to demonstrate that, to test “ telnet localhost 5000” and type some chars and a return from another terminal.

[jshih@ntriptest tcp_server]$ make tcp_recv cc tcp_recv.c -o tcp_recv [jshih@ntriptest tcp_server]$ ./tcp_recv

TCPServer Waiting for client on port 5000 got a connection from (127.0.0.1 , 43891)bytes_recieved 0 errno 0 bytes_recieved 0 errno 0 bytes_recieved 0 errno 0

I know my server is continuously sending but with inserted delay test. Further I changed the code to demonstrate that, there are data in the pipe in my case:

if (con->http_chunk->left < SOURCE_READSIZE) {

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes, 0); xa_debug (4, "Recv LEN1: recv left=%d read=%d len:%d errno:%d", con->http_chunk->left, read_bytes,len, errno);

if (len == 0)

{

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes+1, 0); xa_debug (4, "Recv LEN2: recv left=%d read=%d len:%d errno:%d", con->http_chunk->left, read_bytes,len, errno);

len = 0;

}

maxread = (int)(0.5 * con->http_chunk->left);

Below is the log capture:

[03/Nov/2010:15:53:08] [6:Source Thread] add_chunk: hex [], read=21

[03/Nov/2010:15:53:08] [6:Source Thread] add_chunk: http chunk left=0 [03/Nov/2010:15:53:08] [6:Source Thread] Recv LEN1: recv left=0 read=0 len:0 errno:0 [03/Nov/2010:15:53:08] [6:Source Thread] Recv LEN2: recv left=0 read=0 len:1 errno:0

As you can see if I immediately give a length parameter=1, I successfully recv’ed 1 byte. So there are data.

Also I made a change to source.c (see attached). I run for hours without connection drop (previously was dropping every a few minutes), please review the changes to see if this is a right solution.

changes in source.c =

736c736 < } else if (len == 0) { ---

} else if (len == 0 && con->http_chunk->left) {

744c744 < } while ((read_bytes < maxread) && (tries < source_read_tries)); ---

} while ((con->http_chunk->left==0

read_bytes < maxread) && (tries < source_read_tries));

======================

Dear BKG staff, we are running BKG Ntripcaster v 2.0.21, and monitoring RTCM3 streaming latencies with BNC Client 2.10 (log latency set to every 5 minutes).

We probably found a bug (or something we could not explain) in one of the modules of the BKG Ntripcaster software.

The module src/source.c has a variable named READ_RETRY_DELAY

The value for this is set to 400. Leaving this value, we observe an unexpected high latencies on all of our data streams. If we change the variable to a lower value (we are currently using READ_RETRY_DELAY value of 50), latencies measured by BNC Client decrease systematically by about 0.5 seconds.

The figure attached shows an example for AUCK_RTCM streaming. Red values are the one with READ_RETRY_DELAY set as default (400), whereas green values has this value set to 50. Any comments/suggestions from you would be really appreciated!

Thanks,

Elisabetta D'Anastasio GNS Science - Te Pu Ao