<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 9:06 AM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On 29 Mar, 2015, at 20:36, Pedro Tumusok <<a href="mailto:pedro.tumusok@gmail.com">pedro.tumusok@gmail.com</a>> wrote:<br>
><br>
> Dslreports got a new speedtester up, anybody know Justin or some of the other people over there?<br>
><br>
> <a href="http://www.dslreports.com/speedtest" target="_blank">http://www.dslreports.com/speedtest</a><br>
><br>
> Maybe somebody on here could even lend a hand in getting them to implement features like ping under load etc.<br>
<br>
</span>I gave that test a quick try.  It measured my download speed well enough, but the upload…<br>
<br>
Let’s just say it effectively measured the speed to my local webcache, not to the server itself.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Hi Jonathan,</div><div><br></div><div>I forwarded your observation to the Justin over at dslreports and I got the following answer. I a bit in the middle here, but I'll see if I can get him to join the mailing list, he seemed interested in bufferbloat at least.</div><div>Also would you mind doing another test and share the link for result, so he can check closer?</div><div><br></div><div>""Let’s just say it effectively measured the speed to my local webcache, not to the server itself."</div><div><br></div><div>If he runs an outbound squid, as the upload speed is measured continuously, it will measure the speed to the squid, although why would configure it to cache POSTs when the URL is unique and includes all the no-cache headers? it doesn't make them any faster we still have to wait for the result.. I believe his situation to be rather unique. 190,000 tests nobody else has had that case.</div><div><br></div><div>Either way if he re-runs and sends me a link, I can look at the log and work out how to"patch" the upload speed at the end to the right number because it waits for the real reply from the server, with the amount uploaded, and no web cache can fake that.</div><div><br></div><div>on the other things, yes I'd like to hear about buffer bloat ideas.</div><div>The simultaneous up+down mode would also be interesting.</div><div><br></div><div>Since I control the servers and don't use a CDN, I'm thinking of running ng-capture constantly, then inspecting the tcptraces in real time. If there is stuff that can drop out of that that is revealing it can be rolled into the results.. Even without any buffer bloat issues, being able to see packet loss directly would be a win for people with bad lines. It would also pickup those TCP disasters between client and server when they can't agree on something or things are fragmented etc etc."</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">What do you guys think about his packet capture ideas? There are a lot of users over on dslreports, so if they put up a speedtest with bufferbloat "detectors" it could be another thing to get the snowball to roll.</div><br clear="all"><div>I also removed cerowrt dev list, do not think we need to cross post to that one.</div>-- <br><div class="gmail_signature">Best regards / Mvh<br>Jan Pedro Tumusok<br><br></div>
</div></div>