FAQ
Testing on some staging systems at bitly we're seeing incredible drops in
context switching/interrupts with our same code built against go1.1rc1:

[image: Inline image 1]

and interestingly an *increase* in # of packets:

[image: Inline image 2]

The latter is peculiar, I'm curious to hear others thoughts (no change to *
bandwidth*).

Will continue to report in as we experiment.

Thanks!

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Eli Janssen at May 3, 2013 at 10:33 pm
    Is the packet size smaller after vs before?
    Do you have nagle disabled (using TCP_NODELAY)?

    If not, then I wonder if the overall lack of interrupt congestion results in tcp sending more often (Go being more efficient and writing more frequently).
    On May 3, 2013, at 12:24 PM, Matt Reiferson wrote:

    Testing on some staging systems at bitly we're seeing incredible drops in context switching/interrupts with our same code built against go1.1rc1:

    <image.png>

    and interestingly an increase in # of packets:

    <image.png>

    The latter is peculiar, I'm curious to hear others thoughts (no change to bandwidth).

    Will continue to report in as we experiment.

    Thanks!

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at May 3, 2013 at 10:40 pm
    What do the pcaps show?



    On 04/05/2013, at 5:24 AM, Matt Reiferson wrote:

    Testing on some staging systems at bitly we're seeing incredible drops in context switching/interrupts with our same code built against go1.1rc1:

    <image.png>

    and interestingly an increase in # of packets:

    <image.png>

    The latter is peculiar, I'm curious to hear others thoughts (no change to bandwidth).

    Will continue to report in as we experiment.

    Thanks!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vova Niki at May 3, 2013 at 10:49 pm
    what version did you used before switching to go1.1rc1?
    I'm not sure about the packet increase but it may be related because you
    are not processing the packets fast enough (
    http://www.codefixes.com/2012/02/ludicrous-speed-sockets/ )
    On Friday, May 3, 2013 10:24:54 PM UTC+3, snakes wrote:

    Testing on some staging systems at bitly we're seeing incredible drops in
    context switching/interrupts with our same code built against go1.1rc1:

    [image: Inline image 1]

    and interestingly an *increase* in # of packets:

    [image: Inline image 2]

    The latter is peculiar, I'm curious to hear others thoughts (no change to
    *bandwidth*).

    Will continue to report in as we experiment.

    Thanks!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Reiferson at May 4, 2013 at 3:44 am
    NODELAY is on by default (http://golang.org/pkg/net/#TCPConn.SetNoDelay).

    Packet size is implicitly smaller since there are more of them with no
    change in bandwidth. I thought the same re: efficiency of the scheduler +
    netpoll means less opportunity to buffer in the application.

    I'll continue to dig around. Thanks.



    On Fri, May 3, 2013 at 6:49 PM, Vova Niki wrote:

    what version did you used before switching to go1.1rc1?
    I'm not sure about the packet increase but it may be related because you
    are not processing the packets fast enough (
    http://www.codefixes.com/2012/02/ludicrous-speed-sockets/ )
    On Friday, May 3, 2013 10:24:54 PM UTC+3, snakes wrote:

    Testing on some staging systems at bitly we're seeing incredible drops in
    context switching/interrupts with our same code built against go1.1rc1:

    [image: Inline image 1]

    and interestingly an *increase* in # of packets:

    [image: Inline image 2]

    The latter is peculiar, I'm curious to hear others thoughts (no change to
    *bandwidth*).

    Will continue to report in as we experiment.

    Thanks!
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrey mirtchovski at May 4, 2013 at 4:14 am
    I thought the same re: efficiency of the scheduler + netpoll means less opportunity to buffer in the application.
    If you look for the thread "Go scheduler update" on this mailing list,
    especially Dmitry Vyukov's message from Feb 19th, you'll see very
    impressive drops in tcp benchmark times and increases in the number of
    items processed per second.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at May 4, 2013 at 7:10 am

    On Fri, May 3, 2013 at 8:43 PM, Matt Reiferson wrote:

    NODELAY is on by default (http://golang.org/pkg/net/#TCPConn.SetNoDelay).

    Packet size is implicitly smaller since there are more of them with no
    change in bandwidth. I thought the same re: efficiency of the scheduler +
    netpoll means less opportunity to buffer in the application.

    Yes, I think this is it.
    What is the CPU load?
    Hopefully, if you increase load, you will be able to get the same
    bufferring opportunities. And higher throughput as a result.



    I'll continue to dig around. Thanks.



    On Fri, May 3, 2013 at 6:49 PM, Vova Niki wrote:

    what version did you used before switching to go1.1rc1?
    I'm not sure about the packet increase but it may be related because you
    are not processing the packets fast enough (
    http://www.codefixes.com/2012/02/ludicrous-speed-sockets/ )
    On Friday, May 3, 2013 10:24:54 PM UTC+3, snakes wrote:

    Testing on some staging systems at bitly we're seeing incredible drops
    in context switching/interrupts with our same code built against go1.1rc1:

    [image: Inline image 1]

    and interestingly an *increase* in # of packets:

    [image: Inline image 2]

    The latter is peculiar, I'm curious to hear others thoughts (no change
    to *bandwidth*).

    Will continue to report in as we experiment.

    Thanks!
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrey mirtchovski at Aug 8, 2013 at 5:59 pm
    old thread revival of the day. this interesting article sheds some light
    on linux tcp queueing:

    http://www.coverfire.com/articles/queueing-in-the-linux-network-stack/

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 3, '13 at 7:25p
activeAug 8, '13 at 5:59p
posts8
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase