H Alan,
On Sep 23, 2014, at 01:02 , Alan Goodman <[email protected]> wrote: > On 22/09/14 20:52, Sebastian Moeller wrote: >>> >This test was ran on a BT Infinity VDSL/FTTC connection with the modem >>> >plugged directly into a CentOS 6 machine which is doing PPPoE. The >>> >connection is synced at 80mbit down and 20mbit up. BT restrict downstream >>> >speed to 77.44Mbps IP traffic. >> Thank you very much this is the first data set on a VDSL line I have >> seen, and clearly me hypothesis that overhead detection on PTM carriers will >> not work with the current code is nicely demonstrated. I need to ponder this >> a bit more and I might not be able to find a nice solution for those links... > > You're welcome. If you need any more data feel free to drop me a line. Thanks for the offer, I might take you up on it ;) (next month I hope to upgrade to VDSL2 so I have an easier time trying new methods...) > >>>> I can run the test on a slower BT connection over the week end if anyone >>>> is interested in the results? >> I would love to see that especially if the other connection is much slower, >> as I see two possible issues with this data set: > > The other connection is actually ADSL2, we probably know what the results > there will be… I assume that this will work reasonably well, for all adel lines I tested 1000 samples per ping size and a range from 16 to 116 worked out well enough to detect quantization and overhead. > I think I shall run the test on a really slow ADSL connection later in the > year to double check my overheads though. I think it is a decent idea to re-check the encapsulation used occasionally, in my case the ISP added VLAN tags (which I neither need nor want) increasing the overhead from 40 bytes to 44 bytes. If that had not caused irregularities in the netperf-wrapper tests I run I would probably not have noted. (If the link is fully saturated the wrong overhead has a strong effect on the link’s latency, but with moderate load that is somewhat hidden so easy to overlook) > It seems like a very useful tool. Glad you like it ;) (I think the idea and method is sound, but those I lifted from Jesper’s thesis, my implementation however is messy) > > Also thanks for providing some example plots of how it should look. That will > allow me to better interpret results in future. > >> 1) Speed: It might be that your line is fast enough to hide the ATM >> quantization below another quantization (like the 4KHz symbol rate of the >> individual carriers) or two many concurrent carriers;) > > Would it be useful if I limited my upload speed with say hfsc to 1mbit and > re-ran the test? First I would try against different hosts, the fact that there is no linear increase of the RTT with increasing packet size is a sign that something is messing with our probe packets and hence the whole thing gets iffy. BUT, I strongly assume your VDSL link is using packet transfer mode (PTM) not ATM and so all my code can show you is that there is no quantization, and since overhead detection currently requires ATM cell quantization the reported numbers are just not useful. The reason to still report these is that I have not determined a proper statistical test to classify the link carrier. Note (I might have explained that earlier, but I am not sure whether that was in this thread): the code tries to find packet sizes at which the RTT increases, or in other words the boundaries of the ATM cells. Once this is done it uses all information it has about pre-payload overhead (ICMP header, IP header…) and finds out how many bytes are missing to fully fill the first (two) ATM cells (these cells are not really shown in the plots), it then reports the previously un-known pre-IP bytes as overhead that needs to be accounted for. > > Given the above comments in Sebastian’s very useful emails how would it be > best to shape these FTTC connections at present? So > Without overhead set or something else? I would just go and account for all overheads I could deduce, so I would guess: 8 bytes PPPoE, 4 byte VLAN tags, 14 bytes ethernet header (note for tc’s stab method one needs to include the ethernet headers in the specified overhead in spite of the man page), I am uncertain about the 4 byte ethernet frame check sequence (it was typically not included on ATM links). So in total 26 bytes; I would specify those, for PTM getting the overhead wrong is not as bad as with ATM so just try to make a good approximation. A trickier question is how to select the shaping rate. In theory all xDSL-modem report some sort of line rates, but unfortunately the standards contain quite a lot slightly different rates the modem manufacturer might decide to report, so guess the best one can do is to guess, then iterate over measure and refine cycles to figure out the “optimal” shaping rates. Rich Brown’s betterspeedtest.sh or netperf-wrapper’s RRUL test (see http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat/ ) are decent ways for the measure part… Best Regards Sebastian Moeller > > Alan _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
