On Mon, May 17, 2010 at 12:31 PM, <[email protected]> wrote: > Tim, > > Assuming the Rx counters on your side(s) are all zeros, then we could move to > consider perhaps their equipment has a layer 1.5 or PLCP issue -- failing to > transport small and non-line-rate frames could be related to:
What is PLCP? > -slightly broken Rx pll or ifg detection in their rx path; whereby it locks > "better" for longer/more frequent payloads than it will for small. > > -"near Rx threshold condition" at the receiver on either side of your link, > whereby FEC and block interleave codes "fail" with smaller frames, but can > operate with larger, low entropy data. That's the kind of information I'm looking for. > Since this case is so odd, I also suggest you try ping with more "random" > data -- ascii doesn't really involve that many bits in each byte. Perhaps > this can tease out further detail after testing whether payload content has > any bearing on success. Having a hard time coming up with a convincing test, especially with test sets targetted at linerate rather than low bitrate tests. Haven't tried varying patterns yet. Maybe that will turn something over. Thanks, -- Tim:> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
