pppd between two two modules with extreme latency?

XBee & XBee Gateway XBee - Zigbee
1

Hello,
I’ve got two Xbee Pro series 2 devices, one as a coordinator and one as a router/end device. I have them talking together on the same network, and I can pass data back and forth using a terminal emulator. (One is on a USB Xbee explorer from sparkfun and the other is on a Arduino Xbee shield)

I’m using linux on both ends to establish a ppp connection in an effort to pass tcp/ip data between them. Sounds good right? Well it does “work” as in I can ping between them, but after a second or two the latency goes up through the roof. I can see the actual modules sending AND receiving the packets (by looking at the LED’s). But for some reason the packets are not received in software. I’ve tried all sorts of combinations of Baud rate and flow control, but I’m not sure what is happening.

I’ve left all of the settings for the xbees at defaults except for BD and NI.

The ping times go like this:
64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=61.5 ms
64 bytes from 192.168.5.2: icmp_seq=2 ttl=64 time=35.4 ms
64 bytes from 192.168.5.2: icmp_seq=3 ttl=64 time=43.3 ms
64 bytes from 192.168.5.2: icmp_seq=4 ttl=64 time=51.2 ms
64 bytes from 192.168.5.2: icmp_seq=5 ttl=64 time=43.0 ms
64 bytes from 192.168.5.2: icmp_seq=6 ttl=64 time=50.1 ms
64 bytes from 192.168.5.2: icmp_seq=7 ttl=64 time=42.0 ms
64 bytes from 192.168.5.2: icmp_seq=8 ttl=64 time=49.6 ms
64 bytes from 192.168.5.2: icmp_seq=9 ttl=64 time=5079 ms
64 bytes from 192.168.5.2: icmp_seq=10 ttl=64 time=4112 ms
64 bytes from 192.168.5.2: icmp_seq=11 ttl=64 time=3112 ms
64 bytes from 192.168.5.2: icmp_seq=18 ttl=64 time=2558 ms
64 bytes from 192.168.5.2: icmp_seq=21 ttl=64 time=6482 ms

Any idea what might be going on? Some sort of buffer issue?

Kyle

2

What a fun experiement…but definitely not a recommended network configuration for poor little ZigBee devices!

If you have left the radios in their default configuration then the DH and DL parameters will be set for their default configuration which is to broadcast to the entire PAN rather than to unicast it point-to-point between each radio. If you set DH and DL of each radio to be the SH and SL (respectively) of their peer I would wager you would see a more stable exchange when performing the experiment above.

Broadcasting is bad when using ZigBee because each transmitted packet (which will be only one small piece of a PPP-encapsulated ICMP TCP/IP frame) will be retransmitted three times. This amounts to the creation of a “broadcast storm” which will have increasingly negative effects on the throughput of your network.

Good luck and report back with your results!

Jordan

3

Wow what an improvement, thanks!
Here is what my pings look like now:
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=74.3 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=34.1 ms
64 bytes from 192.168.5.1: icmp_seq=3 ttl=64 time=41.1 ms
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=33.2 ms
64 bytes from 192.168.5.1: icmp_seq=5 ttl=64 time=73.2 ms
64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=33.3 ms
64 bytes from 192.168.5.1: icmp_seq=7 ttl=64 time=41.3 ms
64 bytes from 192.168.5.1: icmp_seq=8 ttl=64 time=32.4 ms
64 bytes from 192.168.5.1: icmp_seq=9 ttl=64 time=40.5 ms
64 bytes from 192.168.5.1: icmp_seq=10 ttl=64 time=48.5 ms

But its still not quite as fast as I would like.

If flood the link with as many packets as I can, the link locks up and nothing gets passed. If I turn off pppd and open up terminals, it looks like something strange is happening: The sender of the packets can no longer send, and if I send some characters on the receiver end, leftover characters from the icmp flood start showing up, then the characters I’m typing show up. Some sort of buffer issue? (Something to do with RO?)

Now if I turn on software flow control it seems better, and the ping flood stays at about 50-60k.

Now there are a bunch of posts about reaching 115200, do you think that is an issue here if I’m using ftdi serial-usb converters on both of these?

Kyle

4

A few questions:

  1. Have you tried this using hardware flow control?

  2. Have you tried this using a baud rate lower than 115200?

  3. Do you plan on adding more than two nodes to this network?

  4. What are you measuring when you say, “the ping flood stays at about 50-60k?”

5

  1. Unfortunately the pins are not wired on the arduino shield that I am using, and eventually I plan on putting these on wrt54gl’s which also do not have the pin, so I would like to exclude hardware flow control from this experiment.

  2. I can certainly try a lower bitrate, but I am going for speed, I guess I can try the next one down.

  3. No, just two nodes p2p. (But more would be interesting wouldn’t it? Some sort of OSI layer 2 implementation on the api level? I wonder if that exists already?)

  4. I do a ping flood and I measure the bitrate passing through the ppp interface at 50-60kbs. (Combined input and output)