Hi jb,
On May 7, 2015, at 12:44 , jb <[email protected]> wrote: > There is a web socket based jitter tester now. It is very early stage but > works ok. > > http://www.dslreports.com/speedtest?radar=1 Looks great. > > So the latency displayed is the mean latency from a rolling 60 sample buffer, > Minimum latency is also displayed. > and the +/- PDV value is the mean difference between sequential pings in > that same rolling buffer. It is quite similar to the std.dev actually (not > shown). So it takes RTT(N+1) - RTT(N)? But if due to buffer bloat the latency goes up for several 100s of MS or several seconds would this not register as low PDV? Would it not be better to take the difference withe the minimum? And maybe even remember the minimum for a longer period than 60 seconds? I guess no network path is guaranteed to be stable over time, but if re-routing is rare, maybe even keep the same minimum as long as the tool is running? You could still report some aggregate, like the mean deviation of the sample buffer, but just not taking the difference between consecutive samples (which sort of feels like rater giving the change in PDV than PDV itself, but as always I am a layman in these matters)... > > Anyway because it is talking to 21 servers or whatever it is not doing high > frequency pinging, I think its about 2hz per server (which is about 50 packets > per second and not much bandwidth). > > My thought is one might click on a server and focus in on that, That sounds pretty useful, especially giving the already relative broad global coverage ;) > then it could go to a higher frequency. Since it is still TCP, I've got > lingering > doubts that simulating 20ms stream with tcp bursts is the same as UDP, > definitely in the case of packet loss, it would not be.' > > There is no way to "load" your connection from this tool, you could open > another > page and run a speed test of course. Could this be used to select a server for the bandwidth test? Best Regards Sebastian > > I'm still working on it, but since you guys are talking RTT and Jitter > thought I'd > throw it into the topic. > > On Thu, May 7, 2015 at 7:16 PM, Mikael Abrahamsson <[email protected]> wrote: > On Thu, 7 May 2015, Sebastian Moeller wrote: > > Is this 40ms sort of set in stone? If so we have a new indicator for > bad buffer-bloat if inured latency > 40 ms link is unsuitable for decent voip > (using old equipment). Is the newer voip stuff that telcos roll out currently > any smarter? > > The 40ms is fairly typical for what I encountered 10 years ago. To deploy > them there was a requirement to have QoS (basically low-latency queuing on > Cisco) for DSCP EF traffic, otherwise things didn't work on the 0.5-2 > megabit/s connections that were common back then. > > I'd say anything people are trying to deploy now for use on the Internet > without QoS, 40ms just won't work and has never really worked. You need > adaptive PDV-buffers and they need to be able to handle hundreds of ms of PDV. > > If you look at this old document from Cisco (10 years old): > > http://www.ciscopress.com/articles/article.asp?p=357102 > > "Voice (Bearer Traffic) > > The following list summarizes the key QoS requirements and recommendations > for voice (bearer traffic): > > Voice traffic should be marked to DSCP EF per the QoS Baseline and RFC 3246. > > Loss should be no more than 1 percent. > > One-way latency (mouth to ear) should be no more than 150 ms. > > Average one-way jitter should be targeted at less than 30 ms. > > A range of 21 to 320 kbps of guaranteed priority bandwidth is required per > call (depending on the sampling rate, the VoIP codec, and Layer 2 media > overhead). > > Voice quality directly is affected by all three QoS quality factors: loss, > latency, and jitter." > > This requirement kind of reflects the requirements of the VoIP systems of the > day with 40ms PDV buffer. There is also a section a page down or so about > "Jitter buffers" where there is a recommendation to have adaptive jitter > buffers, which I didn't encounter back then but I really hope is a lot more > common today. > > > -- > Mikael Abrahamsson email: [email protected] > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
