QUIC and Uploading to Google Drive

[kevin shattuck]

I have run some tests turning QUIC enabled and off in Chrome v.52.0.2743.116 (64-bit) and uploading 120GB files to google drive.  Here are the results

200Mbps dedicated up/down internet connection (corporate)

~100Mbps max upload speed with QUIC enabled, all traffic is going over UDP (verified using nettop)

~130Mbps max upload speed without QUIC enabled - all traffic is TCP!!!  

I am sure I have missed something here.  I read on some other forums that Google Drive may throttle your connection at 150Mbps, but I am not there on either protocol.  Why would the QUIC traffic be slower than the standard TCP traffic?

It was nice to see it working with Google Drive, though. 

Does anyone have any science on the slower QUIC speed?

[Ian Swett]

Chrome M52 still respects the SRBF param in the handshake that specifies the peer's receive buffer size, which limits the client's CWND to a relatively small value of 200 packets. 

As I mentioned in an email earlier this morning, QUIC is deprecating this field, and defaulting to a 2000 packet max CWND.  This change is already present in Chrome Canary, Dev, and Beta, but not in Stable.

In Stable, I see the same results you do, with QUIC being substantially slower.  In Canary, QUIC uploads are substantially faster for me.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[kevin shattuck]

Incredible!

Using the beta version, the pipe is nearly fully saturated (185Mbits out of possible 200Mbits)

This is a game changer. 

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

[kevin shattuck]

I spoke too soon, the bitrate of UDP transfer is increased using the beta version of Chrome and QUIC enabled, the bitrate is not sustained - it fluctuates from a high of 185mbps to 0 mbps every four or 5 seconds.  This causes uploads to take longer than they should if the bitrate was sustained.  Effectively, it takes almost the same amount of time to upload a single large file with or without QUIC enabled.

Since I tried a 30GB file, and the total upload time was ~75minutes, the effective average bitrate with or without QUIC enabled was

approximately 53Mbps.

Is this an upload buffer problem?  A traffic shaping issue?

[Ryan Hamilton]

That's strange. Can you collect a net-internals trace: 

https://dev.chromium.org/for-testers/providing-network-details

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[kevin shattuck]

Ryan,

I could not successfully get the network details to export without it crashing.  But I did test uploading a large file from two computers on our subnet and found out some interesting results:

that they split the bandwidth, which still combined totals about 53Mbit/s (which would be 50 Mebibits)

both report that each packet is sent out at about 185Mbit/s

both computers have seconds of high transmissions followed by seconds of low transmissions.

I am guessing that Google Drive is limiting bandwidth to around 50Mibit/s for uploads by rate-limiting packets.  Can anyone verify this?

Is there another forum/group for google drive I should be posting this in as well?  What is the appropriate etiquette for a cross-post?

[Ryan Hamilton]

On Tue, Aug 16, 2016 at 11:57 AM, kevin shattuck <kevins...@gmail.com> wrote:

Ryan,

I could not successfully get the network details to export without it crashing.

Doh! Yeah, I think you'll only be able to collect the logs for a brief period of time so as not to consume to much memory. If you're seeing drops in bandwidth ever fews seconds, it would be instructive to see the net-internals from that period.

 

  But I did test uploading a large file from two computers on our subnet and found out some interesting results:

that they split the bandwidth, which still combined totals about 53Mbit/s (which would be 50 Mebibits)

both report that each packet is sent out at about 185Mbit/s

both computers have seconds of high transmissions followed by seconds of low transmissions.

I am guessing that Google Drive is limiting bandwidth to around 50Mibit/s for uploads by rate-limiting packets.  Can anyone verify this?

I don't believe we do any rate limiting (at least not intentionally). I wonder if flow-control is getting in the way. net-internals would tell of course.

 

Is there another forum/group for google drive I should be posting this in as well?  What is the appropriate etiquette for a cross-post?

​As far as I know, this is the best list.​

[Jana Iyengar]

Kevin,

On Tue, Aug 16, 2016 at 11:57 AM, kevin shattuck <kevins...@gmail.com> wrote:

Ryan,

I could not successfully get the network details to export without it crashing.  But I did test uploading a large file from two computers on our subnet and found out some interesting results:

that they split the bandwidth, which still combined totals about 53Mbit/s (which would be 50 Mebibits)

Do I understand correctly that you are seeing a *net* upload bandwidth of 53Mbps from your subnet, with both TCP and QUIC?

both report that each packet is sent out at about 185Mbit/s

What is this number from? I don't think I understand what you mean by "each packet is sent out at about 185Mbit/s".

- jana

[dincer kurnaz]

Hi Guys,

Quic Transfer Simple and easy-to-use no-registration upload and sharing of big files.

UDP Fast File Transfer 

https://quictransfer.com/ https://www.youtube.com/watch?v=6hgctnqE5Sg

15 Ağustos 2016 Pazartesi 10:14:21 UTC+4 tarihinde kevin shattuck yazdı: