Speaking as the primary Chromium developer in charge of this relevant code,
I would like to caution putting too much trust in the numbers generated.
Any statistical claims about the numbers are probably unreasonable to make.
Reasons:
* We don't actively maintain this code. It's behind the command
On Thu, Apr 17, 2014 at 12:01 PM, William Chan (陈智昌)
wrote:
> Speaking as the primary Chromium developer in charge of this relevant code,
> I would like to caution putting too much trust in the numbers generated. Any
> statistical claims about the numbers are probably unreasonable to make.
Sigh.
I understand the desire for this code to work, and if I had more bandwidth,
I would definitely fix it sooner. For now, all I can say is, be aware of
the potential issues with the code and use at your own risk. Sorry that we
don't have more bandwidth now to get this working sooner.
On Thu, Apr 17,
Dave,
We used the 25k object size for a short time back in 2012 until we had
resources to build a more advanced model (appendix A). I did a bunch of
captures of real web pages back in 2011 and compared the object size
statistics to models that I'd seen published. Lognormal didn't seem to be
*ex
Why is the DNS PLR so high? 1% is pretty depressing.
Also, it seems odd to eliminate 19% of the content retrieval because the tail
is fat and long rather than short. Wouldn't it be better to have 1000 servers?
On Friday, April 18, 2014 2:15pm, "Greg White" said:
> Dave,
>
> We used
On Fri, Apr 18, 2014 at 11:15 AM, Greg White wrote:
> Dave,
>
> We used the 25k object size for a short time back in 2012 until we had
> resources to build a more advanced model (appendix A). I did a bunch of
> captures of real web pages back in 2011 and compared the object size
> statistics to m
t-devel@lists.bufferbloat.net>>,
bloat mailto:bl...@lists.bufferbloat.net>>
Subject: Re: [Cerowrt-devel] [aqm] chrome web page benchmarker fixed
Why is the DNS PLR so high? 1% is pretty depressing.
Also, it seems odd to eliminate 19% of the content retrieval because the tail
is
> The specific thing I've been concerned about was not the probability of
> a dns loss, although as you note the consequences are huge -
> but the frequency and cost of a cache miss and the resulting fill.
>
> This is a very simple namebench test against the alexa top 1000:
>
> http://snapon.lab.bu
On 4/18/14, 1:05 PM, "Dave Taht" wrote:
>On Fri, Apr 18, 2014 at 11:15 AM, Greg White
>wrote:
>>
>> The choice of RTTs also came from the web traffic captures. I saw
>> RTTmin=16ms, RTTmean=53.8ms, RTTmax=134ms.
>
>Get a median?
Median value was 62ms.
>
>My own stats are probably quite skewed
On Fri, Apr 18, 2014 at 1:41 PM, Greg White wrote:
> On 4/18/14, 1:05 PM, "Dave Taht" wrote:
>
>>On Fri, Apr 18, 2014 at 11:15 AM, Greg White
>>wrote:
>>>
>>> The choice of RTTs also came from the web traffic captures. I saw
>>> RTTmin=16ms, RTTmean=53.8ms, RTTmax=134ms.
>>
>>Get a median?
>
> M
Doug Orr recommended to us that we give
http://www.chromium.org/developers/telemetry
a shot in generating reproducible web traffic models.
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-
11 matches
Mail list logo
