Loading ...
Sorry, an error occurred while loading the content.
 

Re: BPQ APRS IGate Issue

Expand Messages
  • ae5pl
    Thank you for your analysis. If I was seeing a commonality of entry points for the IGates having this issue, I would immediately zero in on that server s
    Message 1 of 3 , Jun 30, 2012
      Thank you for your analysis. If I was seeing a commonality of entry points for the IGates having this issue, I would immediately zero in on that server's configuration but I am not seeing that. This appears to be a very rare and specific issue which appears to be happening independent of the server the IGate is connected to. Nonetheless, I will also continue to pursue this from the server side to see if there could be an overrun occurring there.

      If it was at the server, I would think I would be seeing this across more IGates/servers and it would be of a more random nature. One of the IGates currently having the issue (an aprsD IGate) is connected to second.aprs.net which has hundreds of connections, supply packets at a very high rate so I would think I would see this on at least one other IGate/server connected to second but I am not. That is why I focused in on the individual clients. Of course, aprsD is on Linux while BPQ32 is on Windows so they are using 2 completely different stacks.

      Question: do you disable the Nagle algorithm (set TCPNODELAY) for your feed? You should to prevent buffering in the stack beyond a single packet. APRS-IS servers disable Nagle on their end to help improve near-real-time performance.

      I will continue to pursue this from the server angle as well. If you find anything on your end, please let me know so I can see if we can have the aprsD sysops do something to their configurations. Thanks.

      73,

      Pete AE5PL

      --- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
      >
      > Hi Pete.
      >
      > Welcome to the group.
      >
      > BPQ32 doesn't have to use KISS TNCs (it can work with the UZ7HO soundmodem,
      > or a SCS Tracker in host mode), but if configured for a KISS TNC, it will
      > ignore any non=KISS packets. Also it doesn't need packets to be terminated
      > by CR LF or either.
      >
      > From the one example you've quoted, it looks more like the packets are being
      > merged after being converted to APRS-IS format - the two qAR's in the packet
      > seem to suggest that. Also the first packet has been truncated. My first
      > thought that it is the code is not correctly handling an EWOULDBLOCK on the
      > send of the first packet. If the stack had accepted part of the packet, and
      > the code didn't correctly resend the unsent data we would see that effect.
      > While this doesn't seem very likely, as the volume of traffic is pretty low,
      > and the microsoft stack can normally take a lot of data without blocking,
      > maybe with some network loading conditions it could happen. Anyway, I'll
      > have a look at that code, and see what I can find.
    Your message has been successfully submitted and would be delivered to recipients shortly.