Jitter Buffer

  • I am relaying a T1 over ethernet, using an Adtran MX408e.

    Since it is a TDM interface packets must be received prior to the jitter buffer on the MX408e exhausting.  The MX408e only has a max  jitter buffer of 100ms.  The jitter on my present connection is ~300ms.

    Has someone done this with traffic shaping or dummynet?  I have been playing with queues to no avail.

    It is not VOIP traffic so a short delay will not pose any problems.

  • I'm not entirely privy to T1 terminology, so I may make some incorrect assumptions.

    My question is do you know why the jitter is so incredibly high? T1s are rated for 1-5ms of jitter and Ethernet is typically in the microseconds. You're talking about latencies 100x greater that normal. While the max buffer may be 100ms, you shouldn't be filling a buffer on a synchronous connection.

  • Netgate

    Are you relaying a T1 over "ethernet" or ethernet then the internet.  A good switch should be able to forward frames with latency measured in microseconds, not 300 milliseconds.

  • The set up looks like this:

    +–----+          +--------+
        T1+--+MX408e++ETHERNET+-+PFSENSE |+----+
              +------+          +--------+    |
              MOBILE CONNECTION/OPENVPN        |
      |  +-------+          +------+
          +-------+          +------+

    The T1s are either end are used for relaying telemetry data from two arcane pieces of equipment between power plants a delay of under 2 seconds end to end is acceptable.

    The jitter comes when the connection is piped over the mobile connection.  Asterisk and FreeSwitch seemed to have some jitter buffering capabilities, but I am not sure how to implement..

    The buffer would work like this (assume 1 packet per millisecond):
    -Wait and capture 300 packets–->Send 1 packet every millisecond.

  • I might be confused but wouldn't the 100ms buffer on the mx408e always be the limiting factor in the above scenario?

  • Netgate

    I think you're going to have a hell of a time trying to get a TDM circuit transported over a 300ms RTT VPN link.  No amount of traffic shaping is going to make that any better.  SIP trunking would probably be better, but 300ms is a lot for that too.