[asterisk-dev] TDMoE timing

[Tony Mountifield]

Hi,

I'm fighting with TDMoE trying to get it working, and would be grateful
for any comments. It's not a configuration issue, but concerns the code
and kernel environment, which why I'm posting here and not in -users.

I know TDMoE ideally should have its own ethernet port, but there's
nothing in theory stopping it sharing the main port, and that should be
adequate for small-scale testing.

One of my systems has kernel 2.4.22 and a X101P card. I have defined one
dynamic span with 24 channels. Initial testing is not using Asterisk,
just zaptel, with another machine using tcpdump to log packets with the
TDMoE protocol ID, 0xd00d.

The X101P card is being set in zaptel as the master span, and so the
TDMoE timing is slaved to that, with zaptel calling
zt_dynamic_ioctl(0,0) from within zt_receive on the X101P span.

When I start up zaptel, with wcfxo, ztd-eth, ztdynamic and zaptel
loaded, my monitoring machine initially sees one TDMoE packet per
millisecond, as expected. After between 75 and 90 packets, there is
suddenly a pause for anything from 80ms to 800ms, after which the next
packet in sequence is sent, followed in rapid succession by the next 18
packets spaced about 20us apart. Then another big pause followed by
another burst of 18 or 19 packets. At the second pause, there is a
discontinuity in the TDMoE sequence number, indicating some packets have
been lost.

Next, based on an idea by Fabio Ferrari, I separated out the generation
of TDMoE packets from the queuing of them into the driver. This made no
difference to the timing.

In order to see whether it was a zaptel issue, I enhanced the TDMoE
packet format to include two struct timeval timestamps after the
sequence number.  I filled in one timestamp using do_gettimeofday() at
the time the message was generated, and the second just before queuing
the packet to the driver with dev_queue_xmit(). Looking at the packets
on the monitoring machine on either side of the first pause, I can see
that they were still generated exactly 1000 or 1001 microseconds apart,
and queued no more tha 1us later.  So the pause is happening to the
packet AFTER it was queued with dev_queue_xmit.

This suggests that it might be a kernel issue, rather than zaptel, but
the possibility exists that zaptel or ztd-eth is doing something in a
not quite correct way.

If I also run tcpdump on the machine sourcing the TDMoE packets, I can
see the pause there, too, followed by a burst of packets only 1us apart.
In this log, there are no dropped packets. So, the delay is happening to
the packets somewhere between dev_queue_xmit and the point where tcpdump
sees them (which I haven't yet tracked down). However, the dropped
packets are getting discarded after the point where tcpdump sees them.

I'll continue investigating, but wanted to see if anyone else might have
any ideas.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org