• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Normal Normal
    • None
    • None

      Rika is insanely slow today (as in, lag of several seconds to a minute to respond to key presses through ssh). It's likely due to MB being hammered by stupid headphones requests as usual, but is there a way to ensure rika connections are given priority? We don't use that much bandwidth, I promise

      Ian thinks it has to do with traffic shaping, given we're near our max allowed bandwidth, but isn't sure how to proceed. Dave, any ideas for him to look into? Maybe you can drop some pearl of wisdom and assign this to him.

          [MBH-304] Rika is insanely slow

          Ian McEwen added a comment -

          This seems to be better, at least for now.

          Ian McEwen added a comment - This seems to be better, at least for now.

          Ian McEwen added a comment -

          I've put in traffic shaping similar to the one I described in February. Keeping this open because I don't know one way or the other if it'll help, but here's hoping...

          Ian McEwen added a comment - I've put in traffic shaping similar to the one I described in February. Keeping this open because I don't know one way or the other if it'll help, but here's hoping...

          Ian McEwen added a comment -

          [assigning to dave for feedback again]

          Ian McEwen added a comment - [assigning to dave for feedback again]

          Ian McEwen added a comment -

          Okay, we had trouble again, and I confirmed with bmw-ng that rika wasn't using basically any bandwidth; and, once again, we were at our globally-set limit.

          Dave: I guess the thing to do here might be to, instead of having:

          htb() {
          class ( rate 12Mbps, ceil 12Mbps ) {
          $other = class ()

          { sfq; }
          $rika = class ( rate 500kbps, ceil 500kbps ) { sfq; }

          }
          }

          have something like:

          htb() {
          class ( rate 12Mbps, ceil 12Mbps ) {
          $other = class ( rate 11.99Mbps, ceil 11.99Mbps )

          { sfq; }
          $rika = class ( rate 500kbps, ceil 500kbps ) { sfq; }

          }
          }

          (approximately, of course – point being don't guarantee the full allocation for rika, but leave a small sliver that it can always use to keep SSH (at least) usable).

          How does that seem?

          Ian McEwen added a comment - Okay, we had trouble again, and I confirmed with bmw-ng that rika wasn't using basically any bandwidth; and, once again, we were at our globally-set limit. Dave: I guess the thing to do here might be to, instead of having: htb() { class ( rate 12Mbps, ceil 12Mbps ) { $other = class () { sfq; } $rika = class ( rate 500kbps, ceil 500kbps ) { sfq; } } } have something like: htb() { class ( rate 12Mbps, ceil 12Mbps ) { $other = class ( rate 11.99Mbps, ceil 11.99Mbps ) { sfq; } $rika = class ( rate 500kbps, ceil 500kbps ) { sfq; } } } (approximately, of course – point being don't guarantee the full allocation for rika, but leave a small sliver that it can always use to keep SSH (at least) usable). How does that seem?

          Ian McEwen added a comment -

          Okay; I've got bwm-ng installed, so we can look next time things seem slow.

          Ian McEwen added a comment - Okay; I've got bwm-ng installed, so we can look next time things seem slow.

          Dave Evans added a comment -

          I did notice that, but that might be misleading; the graphs would smooth out spikes, so you might not see high usage even though that's what's happening.

          It would really help if someone were to actually measure rika's network usage at the time that the problem is being experienced, then we'd know if this was what might be causing it.

          Dave Evans added a comment - I did notice that, but that might be misleading; the graphs would smooth out spikes, so you might not see high usage even though that's what's happening. It would really help if someone were to actually measure rika's network usage at the time that the problem is being experienced, then we'd know if this was what might be causing it.

          Ian McEwen added a comment -

          rika is nowhere near its limit, from the network graphs; it's averaging about 6k and hitting 30-50k very occasionally. The traffic shaping rule is 500kbps. So I'm dubious it's rika's shaping that's causing the issue :/

          Ian McEwen added a comment - rika is nowhere near its limit, from the network graphs; it's averaging about 6k and hitting 30-50k very occasionally. The traffic shaping rule is 500kbps. So I'm dubious it's rika's shaping that's causing the issue :/

          Dave Evans added a comment - - edited

          This might be nothing to do with headphones, or other non-rika traffic.

          Rather, it could be simply that we have allocated a limit on the amount of traffic that rika can consume (on the Internet link), and when it maxes this out, packets will be delayed, and latency will suffer.

          The solution is to use less traffic, or to allow a higher limit.

          Dave Evans added a comment - - edited This might be nothing to do with headphones, or other non-rika traffic. Rather, it could be simply that we have allocated a limit on the amount of traffic that rika can consume (on the Internet link), and when it maxes this out, packets will be delayed, and latency will suffer. The solution is to use less traffic, or to allow a higher limit.

          Ian McEwen added a comment -

          I'm stupid, closed the wrong one.

          Ian McEwen added a comment - I'm stupid, closed the wrong one.

            ianmcorvidae Ian McEwen
            reosarevok Nicolás Tamargo
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package