How to reduce CPU usage for QUIC？

[曹少琨]

Hi all,

        I've used 4-Layers QUIC for our Video/Audio Live APP.

     

        But from the picture above, we saw that QUIC used 50% Process CPU time and 50% * 50% CPU time was used on QuicConnection::ProcessUdpPacket.

        QuicDecryptPacket & SendInResponse are the CPU usage wasted source.

        How can I close the Encrypt&Decrypt for every famer to reduce the CPU usage?

[Ian Swett]

The QUIC team has spent quite a bit of time reducing QUIC's CPU usage, but there are always more improvements you can do.

Typically, sending and receiving packets is a large portion of the CPU cost, along with crypto.  Sending and receiving packets are very hard to accelerate without OS level changes.  The Crypto is about as optimized as it's likely to get, from what I know.

It looks like you're on iOS.  There were recently some improvements to use a faster Now() method on iOS, so make sure you're using code that's close to tip of tree.

--
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.

[Gregory Ray]

If your CPU doesn't have built-in AES package then you might consider switching over to CHA-CHA crypto which is much less taxing (1/4th maybe). Check your dropped packets count. UDP buffer size. Check to make sure it's not swapping to disk.

[曹少琨]

My code always follow the Chromium lkgr, this is the lasted good version, the latest one is published on May 08.
Is the faster Now() method in this version?

在 2017年6月14日星期三 UTC+8下午10:04:31，Ian Swett写道：

The QUIC team has spent quite a bit of time reducing QUIC's CPU usage, but there are always more improvements you can do.

Typically, sending and receiving packets is a large portion of the CPU cost, along with crypto.  Sending and receiving packets are very hard to accelerate without OS level changes.  The Crypto is about as optimized as it's likely to get, from what I know.

It looks like you're on iOS.  There were recently some improvements to use a faster Now() method on iOS, so make sure you're using code that's close to tip of tree.

On Wed, Jun 14, 2017 at 3:11 AM, 曹少琨 <csha...@gmail.com> wrote:

Hi all,

        I've used 4-Layers QUIC for our Video/Audio Live APP.

     

        But from the picture above, we saw that QUIC used 50% Process CPU time and 50% * 50% CPU time was used on QuicConnection::ProcessUdpPacket.

        QuicDecryptPacket & SendInResponse are the CPU usage wasted source.

        How can I close the Encrypt&Decrypt for every famer to reduce the CPU usage?

--
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+...@chromium.org.

[Ian Swett]

It was landed in https://codereview.chromium.org/2894173002/ on 5/24, so I'd take a look at the code and see if it has those changes.

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

[曹少琨]

Thanks, But I don't know how to check if the current crypto method whether switched to CHA-CHA or not ON iOS 10.3.2.

And How to switch over to CHA-CHA? 

在 2017年6月14日星期三 UTC+8下午10:32:46，Gregory Ray写道：