Believe it or not, this methods works reasonable well (I tested successfully with one Bridged, LLC/SNAP RFC-1483/2684 connection (overhead 32 bytes), and several PPPOE, LLC, (overhead 40) connections (from ADSL1 @ 3008/512 to ADSL2+ @ 16402/2558)). But it takes relative long time to measure the ping train especially at the higher rates… and it requires ping time stamps with decent resolution (which rules out windows) and my naive data acquisition scripts creates really large raw data files. I guess I should post the code somewhere so others can test and improve it.
	Fred I would be delighted to get a data set from your connection, to test a known different encapsulation. 

> TYPICAL OVERHEADS
>        The following values are typical for different adsl scenarios (based on
>        [1] and [2]):
> 
>        LLC based:
>            PPPoA - 14 (PPP - 2, ATM - 12)
>            PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding)
>            Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)
>            IPoA - 16 (ATM - 16)
> 
>        VC Mux based:
>            PPPoA - 10 (PPP - 2, ATM - 8)
>            PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding)
>            Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding)
>            IPoA - 8 (ATM - 8)
> 
> 
> For VC Mux based PPPoA, I am currently using an overhead of 18 for the PPPoE setting in ceroWRT.

	Yeah we could put this list into the wiki, but how shall a typical user figure out which encapsulation is used? And good luck in figuring out whether the frame check sequence (FCS) is included or not…
BTW 18, I predict that if PPPoE is only used between cerowrt and the "modem' or gateway your effective overhead should be 10 bytes; I would love if you could run the following against your link at night (also attached