(noting a fresh reply to this thread, i recalled i didn't answer this one from wayback)
On May 17, 2010, at 1:10 PM, Tim Durack wrote: > What is PLCP? Short for "physical layer conformance protocol" -- basically, "yet more phy-specific headers" that are prepended, appended, or concatenated with 'user datagrams' on various networks. Depending on how these 'framers' operate on the providers $mystery_transport gear, various sorts of 'broken' can emerge. For example, a badly written PLCP framer could miss-interpret user datagram bits for it's own, slicing frames in half or causing all sorts of funk. > 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. Seems like 64 byte frames at high rate triggered/exposed the negative behavior in your follow-up post; this seems like something was indeed 'frame aware' -- and then when they switched to 'transparent' mode, became less so (given that it now works properly). Do we know that the previous 'less-than-transparent mode' wasn't always frame-aware and stat-muxed with other users' data, into some sort of VC/VT over a sonet-like transport piece? Lastly, knowing something about the drop rate/frequency and intervals of the drops (during your high-rate 64 byte frame tests) could perhaps expose a drop/loss process which could indicate a FIFO somewhere in the previous config. -Tk _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
