On Tue, Feb 14, 2012 at 09:01:47AM -0600, Dan McGee wrote:
> On Tue, Feb 14, 2012 at 2:40 AM, Alon Levy wrote:
> > On Mon, Feb 13, 2012 at 01:48:41PM -0600, Dan McGee wrote:
> >> This prevents compression over things such as VPN links misleading us on
> >> available bandwidth. The page used before
On Tue, Feb 14, 2012 at 2:40 AM, Alon Levy wrote:
> On Mon, Feb 13, 2012 at 01:48:41PM -0600, Dan McGee wrote:
>> This prevents compression over things such as VPN links misleading us on
>> available bandwidth. The page used before was 4K worth of zeroes, which
>> isn't a very realistic test at al
Yaniv Kaul píše v Po 13. 02. 2012 v 23:11 +0200:
> While the best thing would have been to pass the first image already to
> the client using those 256K (and calculate the bandwidth based on the
> first data passed to the client and continue to do so, as the protocol
> continues),
upstream & do
On 02/14/2012 10:40 AM, Alon Levy wrote:
Other then that looks good, and like you say probably better - although
I'm not convinced that by checking several common desktop compression
programs you are checking whatever compression scheme vpn's are using.
VPNs usually use DEFLATE (which is cl
On Mon, Feb 13, 2012 at 01:48:41PM -0600, Dan McGee wrote:
> This prevents compression over things such as VPN links misleading us on
> available bandwidth. The page used before was 4K worth of zeroes, which
> isn't a very realistic test at all.
>
> We now use a generated sequence of bytes that va
On 02/14/2012 01:54 AM, Dan McGee wrote:
On Mon, Feb 13, 2012 at 3:11 PM, Yaniv Kaul wrote:
While the best thing would have been to pass the first image already to the
client using those 256K (and calculate the bandwidth based on the first data
passed to the client and continue to do so, as the
On Mon, Feb 13, 2012 at 3:11 PM, Yaniv Kaul wrote:
> While the best thing would have been to pass the first image already to the
> client using those 256K (and calculate the bandwidth based on the first data
> passed to the client and continue to do so, as the protocol continues), the
> next best
While the best thing would have been to pass the first image already to
the client using those 256K (and calculate the bandwidth based on the
first data passed to the client and continue to do so, as the protocol
continues), the next best thing would probably be pass *some* image to
the client
This prevents compression over things such as VPN links misleading us on
available bandwidth. The page used before was 4K worth of zeroes, which
isn't a very realistic test at all.
We now use a generated sequence of bytes that vary in value and offset
between consecutive values, causing compressio
