[Bloat] ADSL, ATM drivers, bloat, education & confusion

[Bloat] ADSL, ATM drivers, bloat, education & confusion

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Hi Chaps,

Guess who  :-)  Following on from my probably rash assertion that BT 
here in the UK probably aren't as bad at bufferbloat from them to end 
user due to rate limiting as I think, it has reminded me of my parents' 
situation and efforts to help them.

Scenario is: ADSL very long line (hopefully they've got the copper 
repaired now) so on a good day the ADSL sync is something like 2Mbit 
down, 512kbit up.  I bought them a Netgear DGN3500 which is now running 
OpenWrt CC (+cake) This is not my preferred solution in hardware terms 
but it has a supported built-in ADSL modem so is a one box solution.

The problem I have is setting outbound rate limiting.  I was hoping that 
'cake' without the 'bandwidth' parameter would work on the 
'backpressure' from the ATM(?) driver, sadly this wasn't the case and so 
setting a bandwidth limit (I'm not in a position to test the new 
keywords for ATM encapsulation etc yet) was the only way forward.  
Unfortunately the ADSL link isn't rock solid stable so the negotiated 
rates for in & out flap around a bit.  So a few questions:

1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)
2) Do byte queue limits apply to outbound only?
3) Horrid thought - this probably isn't just the ATM driver as IP is 
provisioned over PPP.  PPP driver needs BQL too?


So another approach is to query the ATM interface on every IF up (which 
should get reflected into the the PPP interface up) for its current 
negotiated sync rates and use those as input into the SQM scripts.

There's a question here that's niggling me at the back of my mind: How 
is this supposed to work with a two box modem and router solution?  I 
guess the modem should ideally be running some sort of outbound AQM and 
dropping packets on its ethernet interface that just won't fit/queue too 
long.

Sorry, too many questions and I've not enough programming experience let 
alone linux kernel experience to be able to help.  I'll try if someone 
can point me in a direction.

Kevin




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

Ideally, one would read the raw sync rate out of the modem (there has to be
a way to do that, since it is able to report it in the web interface), and
use that to set cake's bandwidth parameter. You could update it
periodically using "tc qdisc change ...".

You will need to set the overhead calculation correctly, probably using
"pppoa-vcmux" or similar, depending on precisely what encapsulation your
ISP uses. If you're not confident about that, specify "conservative" to
begin with. Once you have that, you can experiment to see how much you need
to reduce the raw sync rate to achieve full bottleneck control - hopefully
not much, at most 1%.

The same approach would also work for inbound if necessary, except that you
would need to reduce the raw sync rate rather more.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 910 bytes --]

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Kevin,

On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> Hi Chaps,
> 
> Guess who  :-)  Following on from my probably rash assertion that BT here in the UK probably aren't as bad at bufferbloat from them to end user due to rate limiting as I think, it has reminded me of my parents' situation and efforts to help them.
> 
> Scenario is: ADSL very long line (hopefully they've got the copper repaired now) so on a good day the ADSL sync is something like 2Mbit down, 512kbit up.  I bought them a Netgear DGN3500 which is now running OpenWrt CC (+cake) This is not my preferred solution in hardware terms but it has a supported built-in ADSL modem so is a one box solution.
> 
> The problem I have is setting outbound rate limiting.  I was hoping that 'cake' without the 'bandwidth' parameter would work on the 'backpressure' from the ATM(?) driver, sadly this wasn't the case and so setting a bandwidth limit (I'm not in a position to test the new keywords for ATM encapsulation etc yet) was the only way forward.  

	This is rather important to get right, ATM’s arcane 48/53 encapsulation only leaves 100*48/53 = 90.5% of the sync rate for useable bits, and even those need to contain all the headers specific to your line (plus AAL5’s unfortunate choice of fitting each packet into an integer number of ATM cells), mean that without AQM taking the link layer encapsulation into account you need to aim for roughly 80-85% of the sync rates on and ATM link. With a link that disappears often I currently would recommend sqm-scripts as weapon of choice (you should be able to get cake into sqm-scripts) as the IFB needs to be set up again after the “connected” interface reappears, which current sqm-scripts should do for you...


> Unfortunately the ADSL link isn't rock solid stable so the negotiated rates for in & out flap around a bit.  So a few questions:

	That is bad and will need special care; on the positive side we might be able to include your solution for this issue into sqm-scripts so that this only needs solving/working-around once ;)

> 
> 1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)

	Is there actual backpreassure from your ATM diver at all? As rar as I know france’s free had their boxes ATM driver modified to keep buffering low, and I believe David Woodhouse dd some work on another driver/the generic ATM layer, but I am not sure that any ATM driver actually defaults to sane buffering and sane back pressure.

> 2) Do byte queue limits apply to outbound only?

	Don’t know, they certainly affect outbound on drivers that actually implement that feature, as far as I know all ethernet so far.

> 3) Horrid thought - this probably isn't just the ATM driver as IP is provisioned over PPP.  PPP driver needs BQL too?

	Don’t think so, I have cerowrt terminating a PPPoE link and outbound shaping just works as expected. Then again I actually have a shaper set to 95% of the sync rate, but that is caused by my ISP being daft and implementing a throttle at the BRAS level which I need to target for shaping, but that’s why I do not reach 100% on egress ;) YMMV.

> 
> 
> So another approach is to query the ATM interface on every IF up (which should get reflected into the the PPP interface up) for its current negotiated sync rates and use those as input into the SQM scripts.

	That sounds like a decent approach, but why not simply do this every hour instead/in addition?

> 
> There's a question here that's niggling me at the back of my mind: How is this supposed to work with a two box modem and router solution?  I guess the modem should ideally be running some sort of outbound AQM and dropping packets on its ethernet interface that just won't fit/queue too long.

	How this is supposed to work? In an ideal work the CPE and the DSLAM would not over-buffer and www would not have to dedicate grey matter to work around their sort-commings ;) But as far as I can tell DSL sync rates for many lines are stable over weeks to months, so setting the shaper rarely is sufficient. Like when you notice that latency under load got worse…


Best Regards
	Sebastian

> 
> Sorry, too many questions and I've not enough programming experience let alone linux kernel experience to be able to help.  I'll try if someone can point me in a direction.
> 
> Kevin
> 
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi JOnathan, hi Kevin,

On Jun 6, 2015, at 15:53 , Jonathan Morton <chromatix99@gmail.com> wrote:

> Ideally, one would read the raw sync rate out of the modem (there has to be a way to do that, since it is able to report it in the web interface), and use that to set cake's bandwidth parameter. You could update it periodically using "tc qdisc change ...".
> 
> You will need to set the overhead calculation correctly, probably using "pppoa-vcmux" or similar, depending on precisely what encapsulation your ISP uses. If you're not confident about that, specify "conservative" to begin with.

	I can be of help to measure the overhead empirically, if you are willing to dedicate a few hours on an otherwise quiescent link to gather some ICMP data, just let me know.

Best Regards
	Sebastian

> Once you have that, you can experiment to see how much you need to reduce the raw sync rate to achieve full bottleneck control - hopefully not much, at most 1%.
> 
> The same approach would also work for inbound if necessary, except that you would need to reduce the raw sync rate rather more.
> 
> - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Jonathan, hi Kevin, hi list,

On June 6, 2015 3:53:43 PM GMT+02:00, Jonathan Morton <chromatix99@gmail.com> wrote:
>Ideally, one would read the raw sync rate out of the modem (there has
>to be
>a way to do that, since it is able to report it in the web interface),
>and
>use that to set cake's bandwidth parameter.

        Unfortunately ISPs more and more implement a throttle/policed? at the BRAS level which in essence supersedes the link rate, but does not seem to be universally reported. If ISPs would actually use this in a way that keeps utilization high but latency increase low all would be dandy, just alas they might be trying but at least not all of them succeed. So people should start out at the modems link rates but should be prepared to reduce the shaped rates until latency under load seems bounded to acceptable levels...

Best Regards
        Sebastian 

 You could update it
>periodically using "tc qdisc change ...".
>
>You will need to set the overhead calculation correctly, probably using
>"pppoa-vcmux" or similar, depending on precisely what encapsulation
>your
>ISP uses. If you're not confident about that, specify "conservative" to
>begin with. Once you have that, you can experiment to see how much you
>need
>to reduce the raw sync rate to achieve full bottleneck control -
>hopefully
>not much, at most 1%.
>
>The same approach would also work for inbound if necessary, except that
>you
>would need to reduce the raw sync rate rather more.
>
>- Jonathan Morton
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]



On 06/06/15 15:29, Sebastian Moeller wrote:
> 1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)
> 	Is there actual backpreassure from your ATM diver at all? As rar as I know france’s free had their boxes ATM driver modified to keep buffering low, and I believe David Woodhouse dd some work on another driver/the generic ATM layer, but I am not sure that any ATM driver actually defaults to sane buffering and sane back pressure.
That was my sort of point.  On 'planet Kevin' (don't go there) the ATM 
driver would *know* the link is busy, or how many bytes it still had to 
shove over it and could offer some clue back up the stack to not bloat.  
I thought that's what BQL was supposed to do.  Or another way of 
viewing:  If ethernet interfaces ideally implement BQL why shouldn't ATM?

>
>
> 	How this is supposed to work? In an ideal work the CPE and the DSLAM would not over-buffer and www would not have to dedicate grey matter to work around their sort-commings ;) But as far as I can tell DSL sync rates for many lines are stable over weeks to months, so setting the shaper rarely is sufficient. Like when you notice that latency under load got worse…
Well again on 'planet Kevin' the CPE is OpenWrt.  Apparenly it's under 
my control but I'm fighting my own lack of abilities, trying to sprint a 
marathon before I can even crawl.  Looking at kernel sources when I can 
barely get 'hello world' to compile & run is asking for trouble :-)  
About a day ago I didn't know what an SKB was. 
https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ 
has been a revelation.
>
> Best Regards
> 	Sebastian
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Dave Taht]

I have long been on a quest to find a debloatable dsl driver, and a
box we could recomend to end users to use that could use hard, rather
than soft, rate limiting in this case.

I think we could dig up resources to tear something binary-ish apart
at this point.

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Kevin,

On Jun 6, 2015, at 17:46 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> 
> 
> On 06/06/15 15:29, Sebastian Moeller wrote:
>> 1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)
>> 	Is there actual backpreassure from your ATM diver at all? As rar as I know france’s free had their boxes ATM driver modified to keep buffering low, and I believe David Woodhouse dd some work on another driver/the generic ATM layer, but I am not sure that any ATM driver actually defaults to sane buffering and sane back pressure.
> That was my sort of point.  On 'planet Kevin' (don't go there) the ATM driver would *know* the link is busy, or how many bytes it still had to shove over it and could offer some clue back up the stack to not bloat.  I thought that's what BQL was supposed to do.  Or another way of viewing:  If ethernet interfaces ideally implement BQL why shouldn't ATM?

	Ah, I fully agree that is how I would like it to be as well; unfortunately that is not sufficient to make it happen though :(

> 
>> 
>> 
>> 	How this is supposed to work? In an ideal work the CPE and the DSLAM would not over-buffer and www would not have to dedicate grey matter to work around their sort-commings ;) But as far as I can tell DSL sync rates for many lines are stable over weeks to months, so setting the shaper rarely is sufficient. Like when you notice that latency under load got worse…
> Well again on 'planet Kevin' the CPE is OpenWrt.  

	A planet I like to live on from what I learned about it.

> Apparenly it's under my control but I'm fighting my own lack of abilities, trying to sprint a marathon before I can even crawl.  Looking at kernel sources when I can barely get 'hello world' to compile & run is asking for trouble :-)  About a day ago I didn't know what an SKB was. https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ has been a revelation.

	This sounds like you embark on fixing the del driver in your modem; more power to you then.

Best Regards
	Sebastian

>> 
>> Best Regards
>> 	Sebastian
>> 
> 
> 

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]



On 06/06/15 19:14, Sebastian Moeller wrote:
>> Apparenly it's under my control but I'm fighting my own lack of abilities, trying to sprint a marathon before I can even crawl.  Looking at kernel sources when I can barely get 'hello world' to compile & run is asking for trouble :-)  About a day ago I didn't know what an SKB was. https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ has been a revelation.
> 	This sounds like you embark on fixing the del driver in your modem; more power to you then.
I thank you for your wishes.  The reality is that I don't have a clue :-(  I'm looking at package/kernel/lantiq/ltq-atm/src/ltq_atm.c and seeing stuff that looks like allocating buffers, setting 'mailboxes' (I'm guessing a semaphore type mechanism to tell firmware/hardware that there's a buffer waiting and it would be ever so nice if you could put it on the wire please) but I now doubt that the 'simple 7 lines or so' related to "netdev_tx_sent_queue" and friends are really as simple as that.

I suspect ADSL will be a forgotten technology by the time I understand 'C' and Linux kernels well enough to have a chance :-)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Jesper Dangaard Brouer]

On Sat, 6 Jun 2015 16:29:15 +0200 Sebastian Moeller <moeller0@gmx.de> wrote:

> On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> 
[...]
> > The problem I have is setting outbound rate limiting.  I was hoping
> > that 'cake' without the 'bandwidth' parameter would work on the
> > 'backpressure' from the ATM(?) driver, sadly this wasn't the case
> > and so setting a bandwidth limit (I'm not in a position to test the
> > new keywords for ATM encapsulation etc yet) was the only way
> > forward.  
> 
>  This is rather important to get right, ATM’s arcane 48/53
> encapsulation only leaves 100*48/53 = 90.5% of the sync rate for
> useable bits, and even those need to contain all the headers specific
> to your line (plus AAL5’s unfortunate choice of fitting each packet
> into an integer number of ATM cells), mean that without AQM taking
> the link layer encapsulation into account you need to aim for roughly
> 80-85% of the sync rates on and ATM link. With a link that disappears
> often I currently would recommend sqm-scripts as weapon of choice
> (you should be able to get cake into sqm-scripts) as the IFB needs to
> be set up again after the “connected” interface reappears, which
> current sqm-scripts should do for you...

That is true, the ATM overhead on ADSL is very important to get right
for your ratelimiting work as intended (that is you gain control over
the queue).

The iproute2 "tc" have supported option "linklayer atm" and "overhead"
for quite some time now (since 2008).  All the rate_tables based
schedulers (e.g. HTB, TBF) have these options.

There is also the more generic "stab" that allow linklayer adaptation to
work for any qdisc. See man tc-stab [1]

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

[1] http://manpages.ubuntu.com/manpages/precise/man8/tc-stab.8.html

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Jesper Dangaard Brouer]

On Sat, 6 Jun 2015 16:30:51 +0200 Sebastian Moeller <moeller0@gmx.de> wrote:

> On Jun 6, 2015, at 15:53 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> > You will need to set the overhead calculation correctly, probably
> > using "pppoa-vcmux" or similar, depending on precisely what
> > encapsulation your ISP uses. If you're not confident about that,
> > specify "conservative" to begin with.
> 
> 	I can be of help to measure the overhead empirically, if you
> are willing to dedicate a few hours on an otherwise quiescent link to
> gather some ICMP data, just let me know.

It would be really cool if someone developed a (simple) tool that could
probe (a quiescent) ADSL/ATM link, and report the encapsulation
overhead (AFAIKR there are 12 different encap combi-types on ADSL).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Jesper,



On June 11, 2015 1:16:15 PM GMT+02:00, Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
>
>On Sat, 6 Jun 2015 16:29:15 +0200 Sebastian Moeller <moeller0@gmx.de>
>wrote:
>
>> On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant
><kevin@darbyshire-bryant.me.uk> wrote:
>> 
>[...]
>> > The problem I have is setting outbound rate limiting.  I was hoping
>> > that 'cake' without the 'bandwidth' parameter would work on the
>> > 'backpressure' from the ATM(?) driver, sadly this wasn't the case
>> > and so setting a bandwidth limit (I'm not in a position to test the
>> > new keywords for ATM encapsulation etc yet) was the only way
>> > forward.  
>> 
>>  This is rather important to get right, ATM’s arcane 48/53
>> encapsulation only leaves 100*48/53 = 90.5% of the sync rate for
>> useable bits, and even those need to contain all the headers specific
>> to your line (plus AAL5’s unfortunate choice of fitting each packet
>> into an integer number of ATM cells), mean that without AQM taking
>> the link layer encapsulation into account you need to aim for roughly
>> 80-85% of the sync rates on and ATM link. With a link that disappears
>> often I currently would recommend sqm-scripts as weapon of choice
>> (you should be able to get cake into sqm-scripts) as the IFB needs to
>> be set up again after the “connected” interface reappears, which
>> current sqm-scripts should do for you...
>
>That is true, the ATM overhead on ADSL is very important to get right
>for your ratelimiting work as intended (that is you gain control over
>the queue).
>

        I want to add that Jesper was essential in teaching the Linux kernel to properly account for all the quirks in the ATM/aal5 Linklater. So we are standing on his shoulders, so to speak ;) to be able to see as far as we do... His original thesis is still findable under http://www.adsl-optimizer.dk/ and certainly worth reading for ATM "sufferers".

>The iproute2 "tc" have supported option "linklayer atm" and "overhead"
>for quite some time now (since 2008).  All the rate_tables based
>schedulers (e.g. HTB, TBF) have these options.
>
>There is also the more generic "stab" that allow linklayer adaptation
>to
>work for any qdisc. See man tc-stab [1]

        Cake has its own independent implementation of per-packet-overhead and atm-celling accounting, in the spirit of making shaper setup easy for mortals. Sqm-scripts allows to select which of the link layer accounting methods to use and calls them htb_private and tc_stab I believe.

Best Regards
        Sebastian


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Jesper.

On June 11, 2015 1:24:34 PM GMT+02:00, Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>
>On Sat, 6 Jun 2015 16:30:51 +0200 Sebastian Moeller <moeller0@gmx.de>
>wrote:
>
>> On Jun 6, 2015, at 15:53 , Jonathan Morton <chromatix99@gmail.com>
>wrote:
>> 
>> > You will need to set the overhead calculation correctly, probably
>> > using "pppoa-vcmux" or similar, depending on precisely what
>> > encapsulation your ISP uses. If you're not confident about that,
>> > specify "conservative" to begin with.
>> 
>> 	I can be of help to measure the overhead empirically, if you
>> are willing to dedicate a few hours on an otherwise quiescent link to
>> gather some ICMP data, just let me know.
>
>It would be really cool if someone developed a (simple) tool that could
>probe (a quiescent) ADSL/ATM link, and report the encapsulation
>overhead (AFAIKR there are 12 different encap combi-types on ADSL).


I sort of did, but it takes a relative long time to gather data (typically around 3 hours) plus 15 minutes for the analysis.
I am happy to share this with interested parties...


Best Regards
        Sebastian

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Tristan Seligmann]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Thu, 11 Jun 2015 at 13:58 Sebastian Moeller <moeller0@gmx.de> wrote:

> I sort of did, but it takes a relative long time to gather data (typically
> around 3 hours) plus 15 minutes for the analysis.
> I am happy to share this with interested parties...
>

I would definitely be interested in this for myself.

[-- Attachment #2: Type: text/html, Size: 574 bytes --]

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Tristan,

On Jun 11, 2015, at 16:14 , Tristan Seligmann <mithrandi@mithrandi.net> wrote:

> On Thu, 11 Jun 2015 at 13:58 Sebastian Moeller <moeller0@gmx.de> wrote:
> I sort of did, but it takes a relative long time to gather data (typically around 3 hours) plus 15 minutes for the analysis.
> I am happy to share this with interested parties...
> 
> I would definitely be interested in this for myself.

	Sure I will send it your way this weekend (need to do a tiny bit of clean-up and actually want to put it into git and possibly git-hub). It essentially is a shell script that runs ping and a matlab/octave script that does attempts the ATM detection, so far it worked well, but it is by no way automatic (yet)….

Best Regards
	Sebastian

Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Jesper Dangaard Brouer]

On Thu, 11 Jun 2015 23:03:18 +0200 Sebastian Moeller <moeller0@gmx.de> wrote:

> On Jun 11, 2015, at 16:14 , Tristan Seligmann <mithrandi@mithrandi.net> wrote:
> 
> > On Thu, 11 Jun 2015 at 13:58 Sebastian Moeller <moeller0@gmx.de> wrote:
> >
> > I sort of did, but it takes a relative long time to gather data
> > (typically around 3 hours) plus 15 minutes for the analysis. I am
> > happy to share this with interested parties...
> > 
> > I would definitely be interested in this for myself.
> 
> 	Sure I will send it your way this weekend (need to do a tiny
> bit of clean-up and actually want to put it into git and possibly
> git-hub). It essentially is a shell script that runs ping and a
> matlab/octave script that does attempts the ATM detection, so far it
> worked well, but it is by no way automatic (yet)….

Please also send it my way. (But I don't have time to look at it before
*after* netfilter workshop[1])

One hint when detecting this, use the *minimum* observed latency/ping
for a given packet size, as jitter/other-traffic can only increase the
latency, but cannot lower it.  (This is an idea that I picked up from
Van Jacobsson).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer


[1] http://workshop.netfilter.org/2015/