Fri 30 Jun 2017 10:46:42 AM UTC, original submission:
Hello.
Maybe, I've got the problem described in TODO like Reading AISHub data via UDP confuses xgps with short writes).
I've got a custom NMEA generator, that runs on embedded device.
Device has Atom CPU, Debian Wheezy 64 bit and gpsd_3.6-4+deb7u1_amd64.deb.
NMEA generator sends NMEA-strings (RMC, GGA and a little bit custom and strange PTNTHTM) to gpsd via UDP.
It sends 3 NMEA-stings line by line in one UDP-packet.
Packets freq is 5 Hz.
Clients read data from standard GPSD TCP-socket with gpspipe (for testing purpose) or libgps.
And I've got the problem: sometimes data stops to come to client with a minute or less.
I've seen a problem with my client alone (libgps-based). And with running only 'gpspipe -r' too.
So, I think it's not a specific client issue.
In GPSD stdout/err i see (dump_gpsd_run8.txt, line 12806):
gpsd:INFO: short write disconnecting client(1)
gpsd:INFO: detaching 127.0.0.1 (sub 1, fd 10) in detach_client
After a minute or less data stream recovers with no warnings.
I've tried to put netcat+tee between generator and gpsd. And I've got dump dump_netcat_run8.txt. It shows generator sends all data (and I'm sure it does it non-stop).
But in gpspipe (dump_pipe_run8.txt, lines 7619-7621) I can see, that system time between two packets moved immediately for a minute (kind of freeze). Than after this freeze suddenly old (buffered) packets began to process without stops (lines 7621-7651). Than I see one RMC and than only GGA strings (lines 7651-7821). Than all strings which were generated in 24 seconds missed (7821-7822, like some buffer was full and packets were dropped). And than everything restored.
I'm very sorry, but I had to correct the coordinates in logs (commercial classified information and bla bla :( ).
What kills me:
I don't have access to that device now and I can't reproduce a problem.
I've tried:
- Debian Wheezy and other OS and versions of GPSD;
- Sending 3-lines UDP packets with 5Hz, much slower and much faster;
- Tried place more than 3 lines per UDP packet (but I'm sure original generator doesn't do it), 1Kb UDP-message can kill GPSD (BUFSIZ overflow?), but never reproduces 'short write';
- Tried to do rare reads in client and even reduce SO_RCVBUF of gps_fd;
- Tried to put sleeps in gpsd_poll() (year, terrible things) and reduce SO_RCVBUF of device UDP socket.
I can't reproduce it by logs, I don't know why.
I hope later in this month I will have access to that device, what to do then? Run gpsd with maximum debug level. What else?
I don't know from which area this problem can be?
Where (in what part of GPSD?) to look for its solution?
|