[c-nsp] GigE woes

[Anton Kapela]

(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