Re: [gentoo-user] Re: Plasma upgrade: Part Deux.

[Alecks Gates]

On 09/21/2016 12:07 AM, J. Roeleveld wrote:
> 
> All those effects depend on your 3D GPU.
> 
> The nouveau drivers don't fully support 3D (please correct me if I am wrong) 
> due to Nvidia not being able (legally) to provide all the necessary specs. 
> (This is Nvidias claim, I am not interested in a discussion if this is really 
> true or not)
> 
> If you want to use nouveau, disable ALL compositing effects and it should 
> then be more stable.
> 
> --
> Joost
> 

For what it's worth, radeon/amdgpu and intel open source drivers have no
such problems.

-- 
Alecks Gates



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Plasma upgrade: Part Deux.

[J. Roeleveld]

On September 21, 2016 6:03:23 AM GMT+02:00, Daniel Frey  
wrote:
>On 09/20/2016 08:26 PM, Kai Krakow wrote:
>>>
>>> I've noticed a couple more things. One is after resume from standby
>>> the plasma taskbar hangs at 100% cpu for 2-3 minutes, during which
>>> time you can't open the K menu, click on open programs in the task
>>> bar or start any apps. The tray icons and clock are also frozen. Has
>>> anyone experienced this? It only does this after resume, it seems to
>>> be fine otherwise.
>> 
>> Any chances you're using calendar access in plasma widgets? I'm using
>> calendars via akonadi-ews, and the clock widget has access to this
>> (also korgac integrates with the plasma bars and accesses the
>> calendar). This leads plasma to blocking for about 1 minute after
>login
>> or resume - but only due to heavy writes of logs about zoneinfo that
>> cannot be found. The problem here is that Outlook uses very strange
>> time zone names (which even seem to change from version to version, I
>> wonder how MS programmers keep track of it). The solution was to
>simply
>> symlink the missing names (which you can extract from the X session
>> logs and/or journal) to /usr/share/zoneinfo/localtime and now it
>works
>> and my calendar events are even at the correct hour (and not shifted
>to
>> another time zone). For me, blocking of plasma is now gone or at
>least
>> reduced to a very short time.
>
>Well, I think I might have solved this one for now. I was using the
>nouveau driver and I was playing a news clip and had no sound and when
>I
>clicked on the volume control in the tray my computer hardlocked.
>
>I was able to ssh in to see that nouveau was crashing constantly trying
>to do what plasma was asking of it; I have installed the recommended
>nvidia-drivers version that was mentioned on nvidia's site and now it
>seems to be okay.
>
>Six or so months ago I tried both nouveau and nvidia's drivers and they
>were both crashing plasma every 10-20 seconds.
>
>> 
>>> Is there a way to speed up alt-tab switching? Often I hit alt-tab
>>> expecting it to switch to another app but nothing happens. I have to
>>> hit it two or sometimes even three (!) times to make it switch. This
>>> is really irritating and slows down my work flow.
>> 
>> I wonder about this annoying bug, too. As a programmer this is
>> absolutely irritating as I do a lot of alt+tab between editors, logs,
>> web browsers, and documentation. :-(
>> 
>> Something similar happens when switching tasks using the mouse:
>> Sometimes the first click on a taskbar icon is simply not fully
>> recognized, it just switches focus to plasma but doesn't switch the
>> application to front.
>> 
>> Sometimes I feel like this may be related to having multiple monitors
>> connected.
>
>I do not have multiple monitors. I haven't seen the mouse issue yet as
>when alt+tab isn't working I have to resort to the dang mouse and it
>always works.
>
>However, on the plus side, I disabled the compositor effects on the
>alt-tab switching and so now it works as expected.
>
>I've attached a small screenshot, make sure what I've circled in red is
>NOT checked. It's under system settings -> window management -> task
>switcher.
>
>Dan

All those effects depend on your 3D GPU.

The nouveau drivers don't fully support 3D (please correct me if I am wrong) 
due to Nvidia not being able (legally) to provide all the necessary specs. 
(This is Nvidias claim, I am not interested in a discussion if this is really 
true or not)

If you want to use nouveau, disable ALL compositing effects and it should then 
be more stable.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Re: Plasma upgrade: Part Deux.

[Kai Krakow]

Am Tue, 20 Sep 2016 21:03:23 -0700
schrieb Daniel Frey :

> On 09/20/2016 08:26 PM, Kai Krakow wrote:
> >>
> >> I've noticed a couple more things. One is after resume from standby
> >> the plasma taskbar hangs at 100% cpu for 2-3 minutes, during which
> >> time you can't open the K menu, click on open programs in the task
> >> bar or start any apps. The tray icons and clock are also frozen.
> >> Has anyone experienced this? It only does this after resume, it
> >> seems to be fine otherwise.  
> > 
> > Any chances you're using calendar access in plasma widgets? I'm
> > using calendars via akonadi-ews, and the clock widget has access to
> > this (also korgac integrates with the plasma bars and accesses the
> > calendar). This leads plasma to blocking for about 1 minute after
> > login or resume - but only due to heavy writes of logs about
> > zoneinfo that cannot be found. The problem here is that Outlook
> > uses very strange time zone names (which even seem to change from
> > version to version, I wonder how MS programmers keep track of it).
> > The solution was to simply symlink the missing names (which you can
> > extract from the X session logs and/or journal)
> > to /usr/share/zoneinfo/localtime and now it works and my calendar
> > events are even at the correct hour (and not shifted to another
> > time zone). For me, blocking of plasma is now gone or at least
> > reduced to a very short time.  
> 
> Well, I think I might have solved this one for now. I was using the
> nouveau driver and I was playing a news clip and had no sound and
> when I clicked on the volume control in the tray my computer
> hardlocked.
> 
> I was able to ssh in to see that nouveau was crashing constantly
> trying to do what plasma was asking of it; I have installed the
> recommended nvidia-drivers version that was mentioned on nvidia's
> site and now it seems to be okay.
> 
> Six or so months ago I tried both nouveau and nvidia's drivers and
> they were both crashing plasma every 10-20 seconds.

Strange, I never had this and use plasma since 5.2 or something...
Always with the proprietary driver (as I also like to play Steam games).

> >> Is there a way to speed up alt-tab switching? Often I hit alt-tab
> >> expecting it to switch to another app but nothing happens. I have
> >> to hit it two or sometimes even three (!) times to make it switch.
> >> This is really irritating and slows down my work flow.  
> > 
> > I wonder about this annoying bug, too. As a programmer this is
> > absolutely irritating as I do a lot of alt+tab between editors,
> > logs, web browsers, and documentation. :-(
> > 
> > Something similar happens when switching tasks using the mouse:
> > Sometimes the first click on a taskbar icon is simply not fully
> > recognized, it just switches focus to plasma but doesn't switch the
> > application to front.
> > 
> > Sometimes I feel like this may be related to having multiple
> > monitors connected.  
> 
> I do not have multiple monitors. I haven't seen the mouse issue yet as
> when alt+tab isn't working I have to resort to the dang mouse and it
> always works.

Well, I use multi monitor on all setups. Here at home, I use TV and
monitor in clone mode. Mouse switching works almost reliably here
(only rarely exposing the bug). At work I use two monitors side by side,
with a desktop across both screens (no clone mode). Only there, I'm
experiencing the mouse problem often, on the other hand my home system
is much more capable. It might well be an issue related to
performance of the system.

On the other hand, when using the activity switcher (not the meta+q one
but the one that works like alt+tab, I've set it to meta+tab), it is
displayed twice - it seems once for each monitor. At work, it is shown
on both monitors. It is shown only once as soon as I disable one
monitor. I've filed a bug report for it. I think multi monitor is not
really tested well.

https://bugs.kde.org/show_bug.cgi?id=368870

> However, on the plus side, I disabled the compositor effects on the
> alt-tab switching and so now it works as expected.
> 
> I've attached a small screenshot, make sure what I've circled in red
> is NOT checked. It's under system settings -> window management ->
> task switcher.

Tried that. Didn't work at all at first, the current window was just
flashing on alt+tab. Only after manually switching with the mouse, the
keyboard shortcut worked reliably. That makes me think the root cause
is to be searched somewhere else and not really related to the
compositor effect.

Anyway, I switched back to the both checkboxes reversed. I prefer that
setup much better. I don't like alt+tab hovering the windows, and
without the compositor effect that setting disabled makes the hole
experience quite useless.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Alt+Fn switch console from within X11 session

[Kai Krakow]

Hello!

I upgraded xorg to 1.18 and during that process also enabled
USE=wayland. However, I don't run a wayland session (this actually
doesn't seem to work with nvidia). I use sddm as the login manager, and
I'm running latest plasma 5.7. The system is booted with systemd.

I just came accross the following phenomenon: Hitting Alt+F2 should
bring up krunner but instead now it switches to console 2. This was
previously only possible with Ctrl+Alt+F2.

Any clues?

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Plasma upgrade: Part Deux.

[Daniel Frey]

On 09/20/2016 08:26 PM, Kai Krakow wrote:
>>
>> I've noticed a couple more things. One is after resume from standby
>> the plasma taskbar hangs at 100% cpu for 2-3 minutes, during which
>> time you can't open the K menu, click on open programs in the task
>> bar or start any apps. The tray icons and clock are also frozen. Has
>> anyone experienced this? It only does this after resume, it seems to
>> be fine otherwise.
> 
> Any chances you're using calendar access in plasma widgets? I'm using
> calendars via akonadi-ews, and the clock widget has access to this
> (also korgac integrates with the plasma bars and accesses the
> calendar). This leads plasma to blocking for about 1 minute after login
> or resume - but only due to heavy writes of logs about zoneinfo that
> cannot be found. The problem here is that Outlook uses very strange
> time zone names (which even seem to change from version to version, I
> wonder how MS programmers keep track of it). The solution was to simply
> symlink the missing names (which you can extract from the X session
> logs and/or journal) to /usr/share/zoneinfo/localtime and now it works
> and my calendar events are even at the correct hour (and not shifted to
> another time zone). For me, blocking of plasma is now gone or at least
> reduced to a very short time.

Well, I think I might have solved this one for now. I was using the
nouveau driver and I was playing a news clip and had no sound and when I
clicked on the volume control in the tray my computer hardlocked.

I was able to ssh in to see that nouveau was crashing constantly trying
to do what plasma was asking of it; I have installed the recommended
nvidia-drivers version that was mentioned on nvidia's site and now it
seems to be okay.

Six or so months ago I tried both nouveau and nvidia's drivers and they
were both crashing plasma every 10-20 seconds.

> 
>> Is there a way to speed up alt-tab switching? Often I hit alt-tab
>> expecting it to switch to another app but nothing happens. I have to
>> hit it two or sometimes even three (!) times to make it switch. This
>> is really irritating and slows down my work flow.
> 
> I wonder about this annoying bug, too. As a programmer this is
> absolutely irritating as I do a lot of alt+tab between editors, logs,
> web browsers, and documentation. :-(
> 
> Something similar happens when switching tasks using the mouse:
> Sometimes the first click on a taskbar icon is simply not fully
> recognized, it just switches focus to plasma but doesn't switch the
> application to front.
> 
> Sometimes I feel like this may be related to having multiple monitors
> connected.

I do not have multiple monitors. I haven't seen the mouse issue yet as
when alt+tab isn't working I have to resort to the dang mouse and it
always works.

However, on the plus side, I disabled the compositor effects on the
alt-tab switching and so now it works as expected.

I've attached a small screenshot, make sure what I've circled in red is
NOT checked. It's under system settings -> window management -> task
switcher.

Dan

[gentoo-user] Re: TCP Queuing problem

[Kai Krakow]

Am Tue, 20 Sep 2016 06:08:31 -0700
schrieb Grant :

>  [...]  
>  [...]  
> >>
> >>
> >> It looks like the TCP Queuing spike itself was due to imapproxy
> >> which I've now disabled.  I'll post more info as I gather it.  
> >
> >
> > imapproxy was clearly affecting the TCP Queuing graph in munin but I
> > still ended up with a massive TCP Queuing spike today and
> > corresponding http response time issues long after I disabled
> > imapproxy.  Graph attached.  I'm puzzled.  
> 
> 
> I just remembered that our AT modem/router does not respond to
> pings.  My solution is to move PPPoE off of that device and onto my
> Gentoo router so that pings pass through the AT device to the Gentoo
> router but I haven't done that yet as I want to be on-site for it.
> Could that behavior somehow be contributing to this problem?  There
> does seem to be a clear correlation between user activity at that
> location and the bad server behavior.

If that device behaves badly in router mode by blocking just all icmp
traffic instead of only icmp-echo-req, this is a good idea. You may
want to bug AT about this problem then. It should really not block
related icmp traffic.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] how to start KDE

[Alon Bar-Lev]

Hi,
You should install plasma-desktop and use startkde in your ~/.xinitrc if
you do not use session manager.
Regards,
Alon

On 21 September 2016 at 06:46, Philip Webb  wrote:

> I've got Gwenview to behave by installing Plasma-meta :
> Systemsettings shows up with adequate options & single-click is back,
> as are the previews of pix on the folder icons.
>
> I've been a happy user of Fluxbox for many years,
> but am willing to see how well KDE 5 works in 2016 .
> From a raw command terminal, I use 'startx' with appropriate  .xinitrc :
> what do I need to have in the latter in order to start KDE 5 ?
> What pkgs am I likely to need to install to make it work ?
> I tried 'emerge -pvt kde-startkde', but that seems to be KDE 4 :
> what do I need for KDE 5 ?
>
> So far, I've installed Konsole (and a few other apps) with requirements
> & Plasma as above.
>
> --
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
>
>
>

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Tue, 20 Sep 2016 05:42:01 -0700
schrieb Grant :

> >> A while back I was having networking issues.  I eventually tried
> >> drastically lowering the MTU of all the systems onsite and the
> >> issues disappeared.  I always thought the issue was due to the MTU
> >> on our modem/router.  Today I read that AT DSL requires a 1492
> >> MTU so I increased the MTU of our systems up to 1492 and haven't
> >> had any issues.  Do certain ISPs require you to change the MTU of
> >> your entire network, or is this likely due to our AT
> >> modem/router itself?  
> >
> > Are you using tunnels or a firewall that blocks related "icmp
> > fragmentation needed" packets?  
> 
> 
> I have this in shorewall/rules:
> 
> ACCEPT  all  all  icmp  -  -  -  10/sec:20
> 
> Which I believe accepts all icmp packets but throttles them to 10/sec
> to avoid being flooded.  Is that OK?

You should probably add a rule before that to let pass all icmp traffic
related to active connections. I think this can be done with conntrack
or "-m related". I didn't use iptables in a long time so I cannot
exactly help you with instructions.

On the other hand, you're probably interested in only limiting icmp
echo-request. So you may want to stick with that and not limit icmp
altogether. ICMP is a very important part of a functional ip stack, you
should not play with it before fully understanding the consequences.

I don't think it makes too much sense to bother about icmp. In case,
icmp is dropped first usually - and limiting it on your interfaces
doesn't help at all against flooding (because your provider still
delivers it to your router through your downstream, it's too late to
do limiting at this stage), it just saves you from maybe replying to all
those packets (and thus saves upstream bandwidth which on standard
asymmetric lines is ridiculous small compared to the massive
downstreams).

But again: You really (!) should not limit icmp traffic with such a
general rule but instead limit only specific types of icmp (like
echo-request), and maybe even block other types completely on the
external interface (redirect, source quench, a few others).

Most others are important for announcing problems on the packet route -
like smaller MTU (path mtu discovery), unreachable destinations etc.
Unselectively blocking or limiting them will result in a lot of
timeouts and intermittent connection freezes which are hard to
understand.

http://www.nthelp.com/icmp.html

> > Please also try to find out if you're experiencing packet loss. If
> > fragmented packets cannot be reassembled due to some packets lost,
> > you will probably find connections freezing or going really slow.  
> 
> I will watch the output of ifconfig today to see if there are any RX
> or TX errors.

I almost expect you won't see any numbers there but instead see the
counter of your limit rule rise during periods where you see the
problems. TX and RX errors only catch layer 1 or layer 2 losses, you
are probably experiencing packet loss at or above layer 3 (and I guess
due to your limit rule).

Maybe run a ping to a destination which you are having problems with,
then reproduce the problem (with the network idle otherwise). You should
see ping packets dropped only then.

You can also ping with increasing packet sizes (see ping --help) and
see when the packet becomes too big for path MTU. But instead lowering
your MTU then, you should allow icmp-fragmentation-needed come through
reliably. Lowering MTU only makes sense to stop overly fragmentation in
the first place and optimize for a specific packet path (like traffic
through one or multiple VPN tunnels) where fragmentation would
otherwise increase latency a lot, or where icmp-frag-needed does not
correctly work.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] how to start KDE

[Philip Webb]

I've got Gwenview to behave by installing Plasma-meta :
Systemsettings shows up with adequate options & single-click is back,
as are the previews of pix on the folder icons.

I've been a happy user of Fluxbox for many years,
but am willing to see how well KDE 5 works in 2016 .
>From a raw command terminal, I use 'startx' with appropriate  .xinitrc :
what do I need to have in the latter in order to start KDE 5 ?
What pkgs am I likely to need to install to make it work ?
I tried 'emerge -pvt kde-startkde', but that seems to be KDE 4 :
what do I need for KDE 5 ?

So far, I've installed Konsole (and a few other apps) with requirements
& Plasma as above.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

[gentoo-user] Re: Plasma upgrade: Part Deux.

[Kai Krakow]

Am Tue, 20 Sep 2016 08:13:49 -0700
schrieb Daniel Frey :

> On 09/19/2016 11:36 PM, Kai Krakow wrote:
> > Am Mon, 19 Sep 2016 20:05:19 -0700
> > schrieb Daniel Frey :
> >   
> >> So, I have a week off and have time to mess around trying to
> >> upgrade to Plasma once again.
> >>
> >> I have got it mostly-somewhat upgraded, but I have two bizarre
> >> problems.
> >>
> >> The first one is I have two volume controls in the tray. I have no
> >> idea why, and both seem to present slightly different controls.
> >> Could this be related to pulseaudio?  
> > 
> > There's kmix and there's the systray integrated mixer. Disable
> > either one of them. With modern versions of plasma I prefer the
> > plasma integrated mixer and uninstalled kmix.
> > 
> > You can disable the other mixer in the systray properties.
> > 
> >   
> 
> Yes, that solved it, thank you.
> 
> I also figured out my Thunderbird problem, for some reason
> "Fullscreen" was set under window properties (right-click Thunderbird
> in the task bar, More Actions.)
> 
> I've noticed a couple more things. One is after resume from standby
> the plasma taskbar hangs at 100% cpu for 2-3 minutes, during which
> time you can't open the K menu, click on open programs in the task
> bar or start any apps. The tray icons and clock are also frozen. Has
> anyone experienced this? It only does this after resume, it seems to
> be fine otherwise.

Any chances you're using calendar access in plasma widgets? I'm using
calendars via akonadi-ews, and the clock widget has access to this
(also korgac integrates with the plasma bars and accesses the
calendar). This leads plasma to blocking for about 1 minute after login
or resume - but only due to heavy writes of logs about zoneinfo that
cannot be found. The problem here is that Outlook uses very strange
time zone names (which even seem to change from version to version, I
wonder how MS programmers keep track of it). The solution was to simply
symlink the missing names (which you can extract from the X session
logs and/or journal) to /usr/share/zoneinfo/localtime and now it works
and my calendar events are even at the correct hour (and not shifted to
another time zone). For me, blocking of plasma is now gone or at least
reduced to a very short time.

> Is there a way to speed up alt-tab switching? Often I hit alt-tab
> expecting it to switch to another app but nothing happens. I have to
> hit it two or sometimes even three (!) times to make it switch. This
> is really irritating and slows down my work flow.

I wonder about this annoying bug, too. As a programmer this is
absolutely irritating as I do a lot of alt+tab between editors, logs,
web browsers, and documentation. :-(

Something similar happens when switching tasks using the mouse:
Sometimes the first click on a taskbar icon is simply not fully
recognized, it just switches focus to plasma but doesn't switch the
application to front.

Sometimes I feel like this may be related to having multiple monitors
connected.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Alarig Le Lay]

On Tue Sep 20 07:52:58 2016, Todd Goodman wrote:
> MTU is per network interface but you really don't want to end up having
> your router fragment every IP packet because systems on your subnet are
> using a larger MTU.
> 
> Todd

You will not fragment every packet, the PMTUd will do his job and will
lower all the next packets.

-- 
alarig


signature.asc
Description: Digital signature

Re: [gentoo-user] Re: TCP Queuing problem

[Alarig Le Lay]

On Tue Sep 20 12:52:57 2016, Grant wrote:
> The spikes are taking place on my remote server but they seem to
> roughly coincide with user activity within my own network.  My
> technical knowledge of networking internals is weak.  Does anyone know
> which tool will tell me more about the connections that are causing
> the TCP Queuing spikes?
> 
> - Grant

As you know when the pick appears, you can tcpdump during this period.

-- 
alarig


signature.asc
Description: Digital signature

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Mick]

On Tuesday 20 Sep 2016 12:57:00 Grant wrote:
> > Leaving your MTU at the default ethernet size of 1500 on your PC/server
> > should not cause a problem for most day to day operations, because modern
> > end-point OS and network devices use Path MTU Detection.  Problems will
> > arise when you come across a misconfigured router/firewall/server
> > (internet black hole) which drops  ICMP Fragmentation Needed (Type 3,
> > Code 4) packets and won't adjust its MTU to make sure you can receive
> > packets of the appropriate size.
> 
> And I believe that's exactly what I have as far as my AT
> modem/router which seems to drop all icmp packets.  I think that's why
> it's important for me to set an MTU for my network which is not
> greater than the MTU of the modem/router which appears to be 1492.
> 
> > I have no idea if PMTUD is in any way relevant to the TCP queue spikes you
> > have observed, but they are caused by TCP buffers overflowing.  Some
> > detective work at the time these overflows take place would show what the
> > server is doing at the time.
> 
> Any idea which tool to use?  I could start keeping an eye on output
> when things are good and then again when things are bad so I can
> compare the two states.
> 
> - Grant

On the server you could start by using iftop, iptraf-ng, netstat to get an 
idea of connections and bandwidth consumed.  Use lsof, syslog and webserver 
logs to see what's happening at an application level.

You can also increase the firewall verbosity briefly, to see if anything 
strange 
is happening with packets being processed there.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

> Leaving your MTU at the default ethernet size of 1500 on your PC/server should
> not cause a problem for most day to day operations, because modern end-point
> OS and network devices use Path MTU Detection.  Problems will arise when you
> come across a misconfigured router/firewall/server (internet black hole) which
> drops  ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its
> MTU to make sure you can receive packets of the appropriate size.


And I believe that's exactly what I have as far as my AT
modem/router which seems to drop all icmp packets.  I think that's why
it's important for me to set an MTU for my network which is not
greater than the MTU of the modem/router which appears to be 1492.


> I have no idea if PMTUD is in any way relevant to the TCP queue spikes you
> have observed, but they are caused by TCP buffers overflowing.  Some detective
> work at the time these overflows take place would show what the server is 
> doing
> at the time.


Any idea which tool to use?  I could start keeping an eye on output
when things are good and then again when things are bad so I can
compare the two states.

- Grant

Re: [gentoo-user] Re: TCP Queuing problem

[Grant]

>>> My web server's response time for http requests skyrockets every
>>> weekday between about 9am and 5pm.  I've gone over my munin
>>graphs
and
>>> the only one that really correlates well with the slowdown is
>>"TCP
>>> Queuing".  It looks like I normally have about 400 packets per
second
>>> graphed as "direct copy from queue" in munin throughout the day,
but 2
>>> to 3.5 times that many are periodically graphed during work
>>hours.
I
>>> don't see the same pattern at all from the graph of all traffic
>>on
my
>>> network interface which actually peaks over the weekend.  TCP
Queuing
>>> doesn't rise above 400 packets per second all weekend.  This is
>>> consistent week after week.
>>>
>>> My two employees come into work during the hours in question, and
they
>>> certainly make frequent requests of the web server while at work,
but
>>> if their volume of requests were the cause of the problem then
>>that
>>> would be reflected in the graph of web server requests but it is
not.
>>> I do run a small MTU on the systems at work due to the config of
the
>>> modem/router we have there.
>>>
>>> Is this a recognizable problem to anyone?
>>
>>
>> I'm in the midst of this.  Are there certain attacks I should
>>check
for?
>
>
> It looks like the TCP Queuing spike itself was due to imapproxy
>>which
> I've now disabled.  I'll post more info as I gather it.


imapproxy was clearly affecting the TCP Queuing graph in munin but I
still ended up with a massive TCP Queuing spike today and
corresponding http response time issues long after I disabled
imapproxy.  Graph attached.  I'm puzzled.

- Grant
>>>
>>> Things to check for:
>>> Torrent or other distributed downloads.
>>> Download program with multiple download threads
>>
>>
>>There sure shouldn't be anything like that running either on the
>>server or in the office.  Is there a good way to find out? Maybe
>>something that would clearly indicate it?
>>
>>
>>> Maybe another proxy running? Esp. as you saw this also with
>>imapproxy.
>>
>>
>>nginx acts as a reverse proxy to apache2 but that's a pretty common
>>config.  Nothing else that I know of.
>>
>>- Grant
>
> Any way to find out between which hosts/servers those connections are for?
> That might help in locating the cause.
>
> Eg. which of your desktops/laptops inside your network and where they are 
> trying to connect to.


The spikes are taking place on my remote server but they seem to
roughly coincide with user activity within my own network.  My
technical knowledge of networking internals is weak.  Does anyone know
which tool will tell me more about the connections that are causing
the TCP Queuing spikes?

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Mick]

On Tuesday 20 Sep 2016 19:38:02 David Haller wrote:
> Hello,
> 
> On Tue, 20 Sep 2016, Grant wrote:
> >>>Strangely, I'm able to ping with that command even with a very high -s
> >>>value:
> >>>
> >>>$ ping -c 4 -M dont -s  www.dslreports.com
> >>>PING www.dslreports.com (64.91.255.98) (10027) bytes of data.
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
> >>>time=331 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
> >>>time=329 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
> >>>time=329 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
> >>>time=329 ms
> >>>
> >>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
> >>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
> >>>
> >> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
> >> packets actually going over the interface! You'll need to run
> >> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
> >> there's two IP packets actually going over the interface, due to the
> >> ping-packet being too large and being fragmented.
> >> 
> >> Start the tcpdump in another (x)term before running the "ping" ...
> >> 
> >> If you use '-M do', you should get the
> >> 
> >> "Frag needed and DF set (mtu = )"
> >
> >I switched to '-M do' and found that 1464 is the highest size I can
> >ping without the "Frag needed" error.  This means I should add 28 to
> >that
> 
> The overhead of 28 bytes is just specific to ping.
> 
> It means that your upstream has a MTU of 1492 bytes. And it depends on
> your local needs if setting this MTU network-wide is the best course.
> I think I and others wrote enough for you to decide.
> 
> >and set my MTU to 1492 across the network?
> 
> Probably yes. I'd even say: unless you know otherwise for your local
> needs. It's a very small "pay" (-0.5% max throughput) locally for a
> potentially much bigger gain towards the 'net side, esp. when
> factoring in latency ... And BTW: changing the MTU is easy, why not
> start with one system? Even temporarily just using ifconfig/ip
> commandline (don't forget to set the default-route if you "down" the
> connection: 'route add default gw $GW_IP' ) and running some
> tests/benchmarks.
> 
> HTH,
> -dnh

Leaving your MTU at the default ethernet size of 1500 on your PC/server should 
not cause a problem for most day to day operations, because modern end-point 
OS and network devices use Path MTU Detection.  Problems will arise when you 
come across a misconfigured router/firewall/server (internet black hole) which 
drops  ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its 
MTU to make sure you can receive packets of the appropriate size.

I have no idea if PMTUD is in any way relevant to the TCP queue spikes you 
have observed, but they are caused by TCP buffers overflowing.  Some detective 
work at the time these overflows take place would show what the server is doing 
at the time.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: TCP Queuing problem

[J. Roeleveld]

On September 20, 2016 4:53:41 PM GMT+02:00, Grant  wrote:
>> My web server's response time for http requests skyrockets every
>> weekday between about 9am and 5pm.  I've gone over my munin
>graphs
>>>and
>> the only one that really correlates well with the slowdown is
>"TCP
>> Queuing".  It looks like I normally have about 400 packets per
>>>second
>> graphed as "direct copy from queue" in munin throughout the day,
>>>but 2
>> to 3.5 times that many are periodically graphed during work
>hours.
>>>I
>> don't see the same pattern at all from the graph of all traffic
>on
>>>my
>> network interface which actually peaks over the weekend.  TCP
>>>Queuing
>> doesn't rise above 400 packets per second all weekend.  This is
>> consistent week after week.
>>
>> My two employees come into work during the hours in question, and
>>>they
>> certainly make frequent requests of the web server while at work,
>>>but
>> if their volume of requests were the cause of the problem then
>that
>> would be reflected in the graph of web server requests but it is
>>>not.
>> I do run a small MTU on the systems at work due to the config of
>>>the
>> modem/router we have there.
>>
>> Is this a recognizable problem to anyone?
>
>
> I'm in the midst of this.  Are there certain attacks I should
>check
>>>for?


 It looks like the TCP Queuing spike itself was due to imapproxy
>which
 I've now disabled.  I'll post more info as I gather it.
>>>
>>>
>>>imapproxy was clearly affecting the TCP Queuing graph in munin but I
>>>still ended up with a massive TCP Queuing spike today and
>>>corresponding http response time issues long after I disabled
>>>imapproxy.  Graph attached.  I'm puzzled.
>>>
>>>- Grant
>>
>> Things to check for:
>> Torrent or other distributed downloads.
>> Download program with multiple download threads
>
>
>There sure shouldn't be anything like that running either on the
>server or in the office.  Is there a good way to find out? Maybe
>something that would clearly indicate it?
>
>
>> Maybe another proxy running? Esp. as you saw this also with
>imapproxy.
>
>
>nginx acts as a reverse proxy to apache2 but that's a pretty common
>config.  Nothing else that I know of.
>
>- Grant

Any way to find out between which hosts/servers those connections are for?
That might help in locating the cause.

Eg. which of your desktops/laptops inside your network and where they are 
trying to connect to.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
>>>Strangely, I'm able to ping with that command even with a very high -s value:
>>>
>>>$ ping -c 4 -M dont -s  www.dslreports.com
>>>PING www.dslreports.com (64.91.255.98) (10027) bytes of data.
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>>>time=331 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>>>time=329 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>>>time=329 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>>>time=329 ms
>>>
>>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
>>
>> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
>> packets actually going over the interface! You'll need to run
>> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
>> there's two IP packets actually going over the interface, due to the
>> ping-packet being too large and being fragmented.
>>
>> Start the tcpdump in another (x)term before running the "ping" ...
>>
>> If you use '-M do', you should get the
>>
>> "Frag needed and DF set (mtu = )"
>
>
>I switched to '-M do' and found that 1464 is the highest size I can
>ping without the "Frag needed" error.  This means I should add 28 to
>that

The overhead of 28 bytes is just specific to ping.

It means that your upstream has a MTU of 1492 bytes. And it depends on
your local needs if setting this MTU network-wide is the best course. 
I think I and others wrote enough for you to decide.

>and set my MTU to 1492 across the network?

Probably yes. I'd even say: unless you know otherwise for your local
needs. It's a very small "pay" (-0.5% max throughput) locally for a
potentially much bigger gain towards the 'net side, esp. when
factoring in latency ... And BTW: changing the MTU is easy, why not
start with one system? Even temporarily just using ifconfig/ip
commandline (don't forget to set the default-route if you "down" the
connection: 'route add default gw $GW_IP' ) and running some
tests/benchmarks.

HTH,
-dnh

-- 
Actually, NT is more like LSD with all the good effects filtered out.
 -- Andrew Maddox

[gentoo-user] Re: Plasma upgrade: Part Deux.

[»Q«]

On Tue, 20 Sep 2016 08:36:24 +0200
Kai Krakow  wrote:

> There's kmix and there's the systray integrated mixer. Disable either
> one of them. With modern versions of plasma I prefer the plasma
> integrated mixer and uninstalled kmix.
> 
> You can disable the other mixer in the systray properties.

I can't find the integrated mixer in my System Tray Settings -- a
Volume Control shows up in Entries if and only if I have KMix running.
Is it possible I'm missing some package or some USE flag(s) to get
the integrated one?  

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>>Strangely, I'm able to ping with that command even with a very high -s value:
>>
>>$ ping -c 4 -M dont -s  www.dslreports.com
>>PING www.dslreports.com (64.91.255.98) (10027) bytes of data.
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>>time=331 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>>time=329 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>>time=329 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>>time=329 ms
>>
>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
>
> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
> packets actually going over the interface! You'll need to run
> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
> there's two IP packets actually going over the interface, due to the
> ping-packet being too large and being fragmented.
>
> Start the tcpdump in another (x)term before running the "ping" ...
>
> If you use '-M do', you should get the
>
> "Frag needed and DF set (mtu = )"


I switched to '-M do' and found that 1464 is the highest size I can
ping without the "Frag needed" error.  This means I should add 28 to
that and set my MTU to 1492 across the network?

- Grant


> error from ping. "-M dont" explicitly allows fragmentation, which you
> can then see with tcpdump. E.g. a with my MTU of 1492, a
>
>  ping -n -c 1 -M dont -s  192.168.178.1 
> PING 192.168.178.1 (192.168.178.1) (10027) bytes of data.
> 10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms
>
> --- 192.168.178.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms
> 
>
> results in
>
>  tcpdump -n -i eth0 icmp 
> 17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 
> 11363, seq 1, length 1472
> 17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, 
> seq 1, length 1480
> 17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp
> 
>
> Yes, that is just the _one_ ping packet.
>
> Read up on the links I gave you about fragmentation and IP(v4) in
> general a bit ;) It's much better described there than I could ATM.
>
> Which does not mean not to ask for stuff that's unclear.
>
> HTH,
> -dnh, who seems to have a knack for translating "techese" to normal
> language ... Actually, I guess fragmentation can be explained
> quite nicely by comparing to real-life packets ;) You'd get an
> basically unlimited supply of courier boys, but you can get just
> so many incoming and outgoing through the doors ;)
>
> *grepping out the appropriate sig for that*

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
[..]
>> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
>> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
>> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>>
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>>
>>  corresponding tcpdump -n -i eth0 icmp 
>> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 
>> 3595, seq 1, length 1472
>> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
>> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, 
>> seq 1, length 1472
>> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
>> 
>>
>>
>> Two packets sent and received for 1493 bytes packet size / 1465 bytes
>> ping-payload.
>>
>> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
>> yourself to see, that you'll send/recv 2 packets for each ping-packet
>> (and 1472 bytes is the ping-payload that just fits into the standard
>> 1500 bytes MTU).
>
>
>Strangely, I'm able to ping with that command even with a very high -s value:
>
>$ ping -c 4 -M dont -s  www.dslreports.com
>PING www.dslreports.com (64.91.255.98) (10027) bytes of data.
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>time=331 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>time=329 ms
>
>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms

Look again! You're just looking at the _PING_ packets, not the ICMP/IP
packets actually going over the interface! You'll need to run 
'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
there's two IP packets actually going over the interface, due to the
ping-packet being too large and being fragmented.

Start the tcpdump in another (x)term before running the "ping" ...

If you use '-M do', you should get the

"Frag needed and DF set (mtu = )"

error from ping. "-M dont" explicitly allows fragmentation, which you
can then see with tcpdump. E.g. a with my MTU of 1492, a

 ping -n -c 1 -M dont -s  192.168.178.1 
PING 192.168.178.1 (192.168.178.1) (10027) bytes of data.
10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms

--- 192.168.178.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms


results in

 tcpdump -n -i eth0 icmp 
17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, 
seq 1, length 1472
17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, 
seq 1, length 1480
17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp


Yes, that is just the _one_ ping packet.

Read up on the links I gave you about fragmentation and IP(v4) in
general a bit ;) It's much better described there than I could ATM.

Which does not mean not to ask for stuff that's unclear.

HTH,
-dnh, who seems to have a knack for translating "techese" to normal
language ... Actually, I guess fragmentation can be explained
quite nicely by comparing to real-life packets ;) You'd get an
basically unlimited supply of courier boys, but you can get just
so many incoming and outgoing through the doors ;)

*grepping out the appropriate sig for that*

-- 
No trees were destroyed in the sending of this message, however, a 
significant number of electrons were terribly inconvenienced.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>>> MTU is per network interface but you really don't want to end up having
>>> your router fragment every IP packet because systems on your subnet are
>>> using a larger MTU.
>>>
>>> Todd
>>
>>That makes sense.  So in my case, I'm thinking 1492 MTU on every
>>interface in the network.
>>
>>So I'm sure I understand, should everyone with a DSL connection set an
>>MTU of 1492 (or potentially lower) on all of their network interfaces
>>to avoid packet fragmentation?
>
> That depends on your traffic flow. But, then again, 8 bytes out of
> 1500 means that you're "losing" just 0.533% of the maximum payload and
> fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
> packet you see locally.
>
>
> I've just tested that (with the MTU set at 1492, so with the ping
> overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
> ("ping -M do" disallows, "-M dont" allows fragmenting).
>
>
> $ ping -n -c 1 -M do -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)
>
> --- www.dslreports.com ping statistics ---
> 0 packets transmitted, 0 received, +1 errors
>
>  corresponding tcpdump -n -i eth0 icmp 
> [nothing]
> 
>
>
> Ok, go down a byte:
>
>
> $ ping -n -c 1 -M do -s 1464 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
> 1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms
>
>  corresponding tcpdump -n -i eth0 icmp 
> 15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656, 
> seq 1, length 1472
> 15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656, 
> seq 1, length 1472
> 
>
>
> One packet sent and received for 1492 bytes packet size / 1464 bytes payload.
>
>
> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>
>  corresponding tcpdump -n -i eth0 icmp 
> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, 
> seq 1, length 1472
> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, 
> seq 1, length 1472
> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
> 
>
>
> Two packets sent and received for 1493 bytes packet size / 1465 bytes
> ping-payload.
>
> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
> yourself to see, that you'll send/recv 2 packets for each ping-packet
> (and 1472 bytes is the ping-payload that just fits into the standard
> 1500 bytes MTU).


Strangely, I'm able to ping with that command even with a very high -s value:

$ ping -c 4 -M dont -s  www.dslreports.com
PING www.dslreports.com (64.91.255.98) (10027) bytes of data.
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
time=331 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
time=329 ms

--- www.dslreports.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms

- Grant

Re: [gentoo-user] Re: Plasma upgrade: Part Deux.

[Daniel Frey]

On 09/19/2016 11:36 PM, Kai Krakow wrote:
> Am Mon, 19 Sep 2016 20:05:19 -0700
> schrieb Daniel Frey :
> 
>> So, I have a week off and have time to mess around trying to upgrade
>> to Plasma once again.
>>
>> I have got it mostly-somewhat upgraded, but I have two bizarre
>> problems.
>>
>> The first one is I have two volume controls in the tray. I have no
>> idea why, and both seem to present slightly different controls. Could
>> this be related to pulseaudio?
> 
> There's kmix and there's the systray integrated mixer. Disable either
> one of them. With modern versions of plasma I prefer the plasma
> integrated mixer and uninstalled kmix.
> 
> You can disable the other mixer in the systray properties.
> 
> 

Yes, that solved it, thank you.

I also figured out my Thunderbird problem, for some reason "Fullscreen"
was set under window properties (right-click Thunderbird in the task
bar, More Actions.)

I've noticed a couple more things. One is after resume from standby the
plasma taskbar hangs at 100% cpu for 2-3 minutes, during which time you
can't open the K menu, click on open programs in the task bar or start
any apps. The tray icons and clock are also frozen. Has anyone
experienced this? It only does this after resume, it seems to be fine
otherwise.

Is there a way to speed up alt-tab switching? Often I hit alt-tab
expecting it to switch to another app but nothing happens. I have to hit
it two or sometimes even three (!) times to make it switch. This is
really irritating and slows down my work flow.

Dan

Re: [gentoo-user] Re: TCP Queuing problem

[Grant]

> My web server's response time for http requests skyrockets every
> weekday between about 9am and 5pm.  I've gone over my munin graphs
>>and
> the only one that really correlates well with the slowdown is "TCP
> Queuing".  It looks like I normally have about 400 packets per
>>second
> graphed as "direct copy from queue" in munin throughout the day,
>>but 2
> to 3.5 times that many are periodically graphed during work hours.
>>I
> don't see the same pattern at all from the graph of all traffic on
>>my
> network interface which actually peaks over the weekend.  TCP
>>Queuing
> doesn't rise above 400 packets per second all weekend.  This is
> consistent week after week.
>
> My two employees come into work during the hours in question, and
>>they
> certainly make frequent requests of the web server while at work,
>>but
> if their volume of requests were the cause of the problem then that
> would be reflected in the graph of web server requests but it is
>>not.
> I do run a small MTU on the systems at work due to the config of
>>the
> modem/router we have there.
>
> Is this a recognizable problem to anyone?


 I'm in the midst of this.  Are there certain attacks I should check
>>for?
>>>
>>>
>>> It looks like the TCP Queuing spike itself was due to imapproxy which
>>> I've now disabled.  I'll post more info as I gather it.
>>
>>
>>imapproxy was clearly affecting the TCP Queuing graph in munin but I
>>still ended up with a massive TCP Queuing spike today and
>>corresponding http response time issues long after I disabled
>>imapproxy.  Graph attached.  I'm puzzled.
>>
>>- Grant
>
> Things to check for:
> Torrent or other distributed downloads.
> Download program with multiple download threads


There sure shouldn't be anything like that running either on the
server or in the office.  Is there a good way to find out? Maybe
something that would clearly indicate it?


> Maybe another proxy running? Esp. as you saw this also with imapproxy.


nginx acts as a reverse proxy to apache2 but that's a pretty common
config.  Nothing else that I know of.

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
>> MTU is per network interface but you really don't want to end up having
>> your router fragment every IP packet because systems on your subnet are
>> using a larger MTU.
>>
>> Todd
>
>That makes sense.  So in my case, I'm thinking 1492 MTU on every
>interface in the network.
>
>So I'm sure I understand, should everyone with a DSL connection set an
>MTU of 1492 (or potentially lower) on all of their network interfaces
>to avoid packet fragmentation?

That depends on your traffic flow. But, then again, 8 bytes out of
1500 means that you're "losing" just 0.533% of the maximum payload and
fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
packet you see locally.


I've just tested that (with the MTU set at 1492, so with the ping
overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
("ping -M do" disallows, "-M dont" allows fragmenting).


$ ping -n -c 1 -M do -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
>From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.dslreports.com ping statistics ---
0 packets transmitted, 0 received, +1 errors

 corresponding tcpdump -n -i eth0 icmp 
[nothing]



Ok, go down a byte:


$ ping -n -c 1 -M do -s 1464 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms

 corresponding tcpdump -n -i eth0 icmp 
15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656, 
seq 1, length 1472
15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656, seq 
1, length 1472



One packet sent and received for 1492 bytes packet size / 1464 bytes payload.


$ ping -n -c 1 -M dont -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms

 corresponding tcpdump -n -i eth0 icmp 
15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, 
seq 1, length 1472
15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 
1, length 1472
15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp



Two packets sent and received for 1493 bytes packet size / 1465 bytes
ping-payload.

Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
yourself to see, that you'll send/recv 2 packets for each ping-packet
(and 1472 bytes is the ping-payload that just fits into the standard
1500 bytes MTU).

So, unless you have Gigs of internal traffic (and then you should have
a look at jumbo frames and might tune those to split nicely) and
little to the 'net, I'd definitely prefer losing those 8 bytes of
payload over sending double the packets (esp. with TCP, if just one of
those two of the fragmented bigger frame gets lost on the way, _both_
have to be retransmitted, as both TCP ends don't know (AFAIK, at least
usually?) about the fragmentation taking place inbetween, so basically
you're doubling the risk for lost TCP-packets for the "end-user" ...

With larger frames used internally (jumbo-frames) it gets complicated,
so I just send you to
https://en.wikipedia.org/wiki/IP_fragmentation
https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly

And there's Path-MTU though. No idea if that works via the last-mile
PPPoE etc.

Disclaimer: I just know the basics of networking (and where to search
for what ;)

-dnh

-- 
I got an expresso maker at orkplace.  Expresso maker is deemed too complex by
all but me & PFY.  All expresso maker are belong to us.  :)  Caffeine is good.
Bz  -- Mike Raeder

Re: [gentoo-user] Re: TCP Queuing problem

[J. Roeleveld]

On September 20, 2016 2:38:03 AM GMT+02:00, Grant  wrote:
 My web server's response time for http requests skyrockets every
 weekday between about 9am and 5pm.  I've gone over my munin graphs
>and
 the only one that really correlates well with the slowdown is "TCP
 Queuing".  It looks like I normally have about 400 packets per
>second
 graphed as "direct copy from queue" in munin throughout the day,
>but 2
 to 3.5 times that many are periodically graphed during work hours. 
>I
 don't see the same pattern at all from the graph of all traffic on
>my
 network interface which actually peaks over the weekend.  TCP
>Queuing
 doesn't rise above 400 packets per second all weekend.  This is
 consistent week after week.

 My two employees come into work during the hours in question, and
>they
 certainly make frequent requests of the web server while at work,
>but
 if their volume of requests were the cause of the problem then that
 would be reflected in the graph of web server requests but it is
>not.
 I do run a small MTU on the systems at work due to the config of
>the
 modem/router we have there.

 Is this a recognizable problem to anyone?
>>>
>>>
>>> I'm in the midst of this.  Are there certain attacks I should check
>for?
>>
>>
>> It looks like the TCP Queuing spike itself was due to imapproxy which
>> I've now disabled.  I'll post more info as I gather it.
>
>
>imapproxy was clearly affecting the TCP Queuing graph in munin but I
>still ended up with a massive TCP Queuing spike today and
>corresponding http response time issues long after I disabled
>imapproxy.  Graph attached.  I'm puzzled.
>
>- Grant

Things to check for:
Torrent or other distributed downloads.
Download program with multiple download threads

Maybe another proxy running? Esp. as you saw this also with imapproxy.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Todd Goodman]

* Grant  [160920 08:53]:
> >> > A while back I was having networking issues.  I eventually tried
> >> > drastically lowering the MTU of all the systems onsite and the issues
> >> > disappeared.  I always thought the issue was due to the MTU on our
> >> > modem/router.  Today I read that AT DSL requires a 1492 MTU so I
> >> > increased the MTU of our systems up to 1492 and haven't had any
> >> > issues.  Do certain ISPs require you to change the MTU of your entire
> >> > network, or is this likely due to our AT modem/router itself?
> >>
> >> AFAIK the MTU is defined for every network interface separately. For an
> >> ADSL connection it is common that a lower MTU is needed because of the
> >> PPPoE header information that is encapsulated in the ethernet frames.
> >> But in that case it is sufficient to lower the MTU just for the WAN
> >> interface that is connected to the DSL modem.
> >> If you don't use protocol encapsulation in your LAN then there should
> >> be IMHO no reason for lowering the MTU of your internal interfaces.
> >>
> >> --
> >> Regards
> >> wabe
> >
> > MTU is per network interface but you really don't want to end up having
> > your router fragment every IP packet because systems on your subnet are
> > using a larger MTU.
> >
> > Todd
> 
> 
> That makes sense.  So in my case, I'm thinking 1492 MTU on every
> interface in the network.
> 
> So I'm sure I understand, should everyone with a DSL connection set an
> MTU of 1492 (or potentially lower) on all of their network interfaces
> to avoid packet fragmentation?
> 
> - Grant

I would probably set the MTU to 1492 on each interface myself.

But it really depends upon the traffic mix and how "smart" ("dumb") the
devices on the network are.

TCP is likely using Path MTU Discovery to determine the TCP Maximum
Segment Size so that TCP traffic doesn't encounter IP fragmentation
end-to-end.  PMTU used to use ICMP packets to determine the end-to-end
MTU, but RFC4281 (I think) uses a method to work around the dropping or
filtering of ICMP packets.

However, there's different quality of implementations as well as
differences in whether the network stack uses the PMTUD for UDP and
other datagram traffic or not as well.

Todd

DISCLAIMER: It's been a number of years since I've been involved in
implementing any IP networking so things may have moved on since then.

[gentoo-user] Re: TCP Queuing problem

[Grant]

 My web server's response time for http requests skyrockets every
 weekday between about 9am and 5pm.  I've gone over my munin graphs and
 the only one that really correlates well with the slowdown is "TCP
 Queuing".  It looks like I normally have about 400 packets per second
 graphed as "direct copy from queue" in munin throughout the day, but 2
 to 3.5 times that many are periodically graphed during work hours.  I
 don't see the same pattern at all from the graph of all traffic on my
 network interface which actually peaks over the weekend.  TCP Queuing
 doesn't rise above 400 packets per second all weekend.  This is
 consistent week after week.

 My two employees come into work during the hours in question, and they
 certainly make frequent requests of the web server while at work, but
 if their volume of requests were the cause of the problem then that
 would be reflected in the graph of web server requests but it is not.
 I do run a small MTU on the systems at work due to the config of the
 modem/router we have there.

 Is this a recognizable problem to anyone?
>>>
>>>
>>> I'm in the midst of this.  Are there certain attacks I should check for?
>>
>>
>> It looks like the TCP Queuing spike itself was due to imapproxy which
>> I've now disabled.  I'll post more info as I gather it.
>
>
> imapproxy was clearly affecting the TCP Queuing graph in munin but I
> still ended up with a massive TCP Queuing spike today and
> corresponding http response time issues long after I disabled
> imapproxy.  Graph attached.  I'm puzzled.


I just remembered that our AT modem/router does not respond to
pings.  My solution is to move PPPoE off of that device and onto my
Gentoo router so that pings pass through the AT device to the Gentoo
router but I haven't done that yet as I want to be on-site for it.
Could that behavior somehow be contributing to this problem?  There
does seem to be a clear correlation between user activity at that
location and the bad server behavior.

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>> > A while back I was having networking issues.  I eventually tried
>> > drastically lowering the MTU of all the systems onsite and the issues
>> > disappeared.  I always thought the issue was due to the MTU on our
>> > modem/router.  Today I read that AT DSL requires a 1492 MTU so I
>> > increased the MTU of our systems up to 1492 and haven't had any
>> > issues.  Do certain ISPs require you to change the MTU of your entire
>> > network, or is this likely due to our AT modem/router itself?
>>
>> AFAIK the MTU is defined for every network interface separately. For an
>> ADSL connection it is common that a lower MTU is needed because of the
>> PPPoE header information that is encapsulated in the ethernet frames.
>> But in that case it is sufficient to lower the MTU just for the WAN
>> interface that is connected to the DSL modem.
>> If you don't use protocol encapsulation in your LAN then there should
>> be IMHO no reason for lowering the MTU of your internal interfaces.
>>
>> --
>> Regards
>> wabe
>
> MTU is per network interface but you really don't want to end up having
> your router fragment every IP packet because systems on your subnet are
> using a larger MTU.
>
> Todd


That makes sense.  So in my case, I'm thinking 1492 MTU on every
interface in the network.

So I'm sure I understand, should everyone with a DSL connection set an
MTU of 1492 (or potentially lower) on all of their network interfaces
to avoid packet fragmentation?

- Grant

Re: [gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Grant]

>> A while back I was having networking issues.  I eventually tried
>> drastically lowering the MTU of all the systems onsite and the issues
>> disappeared.  I always thought the issue was due to the MTU on our
>> modem/router.  Today I read that AT DSL requires a 1492 MTU so I
>> increased the MTU of our systems up to 1492 and haven't had any
>> issues.  Do certain ISPs require you to change the MTU of your entire
>> network, or is this likely due to our AT modem/router itself?
>
> Are you using tunnels or a firewall that blocks related "icmp
> fragmentation needed" packets?


I have this in shorewall/rules:

ACCEPT  all  all  icmp  -  -  -  10/sec:20

Which I believe accepts all icmp packets but throttles them to 10/sec
to avoid being flooded.  Is that OK?


> Please also try to find out if you're experiencing packet loss. If
> fragmented packets cannot be reassembled due to some packets lost, you
> will probably find connections freezing or going really slow.


I will watch the output of ifconfig today to see if there are any RX
or TX errors.

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>> Rather than guess and take random values read on the net - measure it.
>>
>> Google calculate mtu - netgear and others show ways to test upstream to
>> get the ideal size using ping
>>
>> You are looking for the largest MTU value before fragmentation starts to
>> occur.
>
>   See https://www.dslreports.com/faq/695 for detailed instructions on
> getting the maximum MTU for your setup.


I followed the instructions and got this at first:

# ping -s 1472 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1472(1500) bytes of data.
>From dsldevice (192.168.1.254) icmp_seq=1 Frag needed and DF set (mtu = 1492)
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
time=93.9 ms

After that it wouldn't tell me "Frag needed" no matter how high I set
the MTU for the ping command, but maybe the above indicates that my
max MTU is 1492?

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Todd Goodman]

* wabe  [160919 20:50]:
> Grant  wrote:
> 
> > A while back I was having networking issues.  I eventually tried
> > drastically lowering the MTU of all the systems onsite and the issues
> > disappeared.  I always thought the issue was due to the MTU on our
> > modem/router.  Today I read that AT DSL requires a 1492 MTU so I
> > increased the MTU of our systems up to 1492 and haven't had any
> > issues.  Do certain ISPs require you to change the MTU of your entire
> > network, or is this likely due to our AT modem/router itself?
> 
> AFAIK the MTU is defined for every network interface separately. For an
> ADSL connection it is common that a lower MTU is needed because of the 
> PPPoE header information that is encapsulated in the ethernet frames.
> But in that case it is sufficient to lower the MTU just for the WAN 
> interface that is connected to the DSL modem. 
> If you don't use protocol encapsulation in your LAN then there should
> be IMHO no reason for lowering the MTU of your internal interfaces.
> 
> --
> Regards
> wabe

MTU is per network interface but you really don't want to end up having
your router fragment every IP packet because systems on your subnet are
using a larger MTU.

Todd

Re: [gentoo-user] How to use efibootmgr

[Peter Humphrey]

On Monday 19 Sep 2016 21:28:25 Mick wrote:
> On Monday 19 Sep 2016 13:08:29 Mike Gilbert wrote:

--->8

> > The manpage seems to be incorrect; -B/--delete-bootnum does not take
> > any argument. Instead, you must specify the entry number using the -b
> > option.

Or you could say, with hindsight, that the man page is not strictly 
incorrect, as it doesn't say anything that isn't true. You just have to know 
how to interpret it before you start.   :)

> > Try this:
> > 
> > efibootmgr -b 0001 -B

That worked a treat - many thanks. Except for this little wrinkle, which I 
hope is harmless:

# efibootmgr -b  -B
BootCurrent: 0002
Timeout: 1 seconds
No BootOrder is set; firmware will attempt recovery
Boot0002* Linux Boot Manager
Boot0008  CD/DVD Drive 
Boot0010* UEFI OS

> I recall having a similar problem and this worked last time I tried:
> 
> efibootmgr -b 0002 --delete-bootnum Boot0002
> 
> where:
> 
> -b 002
> 
> is the entry I want to modify.
> 
> --delete-bootnum Boot0002
> 
> is what I want to do to it.  I don't remember if specifying "Boot0002" was
> necessary, but it worked all the same.  I guess you can try first:
> 
> 
> efibootmgr -b 0001 -B
> 
> as already suggested and see if this does it.  Also, before I delete a
> boot stub entry, e.g. 0002, I change the boot order to make sure it is
> not first: --bootorder 0003,0005,0010,0002
> 
> but I don't think it is necessary.

Hah! Watch this:

# efibootmgr --bootorder 0002,0010,0008
Could not set BootOrder: No space left on device

I'll do a bit more poking around.

-- 
Rgds
Peter

Re: [gentoo-user] Re: emerge conflict

[Neil Bothwick]

On Tue, 20 Sep 2016 08:41:56 +0200, Kai Krakow wrote:

> > What makes you think I didn't use -p? I have a cron job that runs
> > emerge -pXXX @world after syncing and mails me the output, and I
> > always use -a when running emerge in a shell.
> 
> You could also try porticron... ;-)

I could but I've been running this script on several machines for many
years and it does just what I want and has evolved along with portage. I
may take a look at porticron to see if there's anything else I want but
didn't know it ;-)


-- 
Neil Bothwick

Physics is like sex: sure, it may give some practical results, but
  that's not why we do it.Richard Feynman


pgpzjJBb4IrBf.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Infrastructure?

[Daniel Campbell]

On 09/19/2016 10:54 AM, Raymond Jennings wrote:
> Just curious, but how are gentoo's infra assets organized?
> 
> Do you guys use VMs on top of hardware machines and whatnot?
> 
> Reasons for asking:
> 
> * general curiosity
> * wondering how a migration to use anongit.gentoo.org
>  instead of github would go, particularly if
> it would help ease pressure on the rsync servers if demand went down
> - I heard something about a social contract where relying on third
> parties was a frowny point.
> 

Popping in to #gentoo-infra and chatting with the folks there may get
you a faster response.

As far as I know, we accept pull requests from the GitHub mirror *or* a
standard `git format-patch` e-mail.

We do have a social contract[1] which indicates that we will not depend
on proprietary software. That said, the GitHub mirror is there for
convenience; I'm betting part of why we use it on the side is because it
already meshes well with Git to begin with and can be a good 'gateway'
for new contributors.

We also accept patches on the gentoo-dev ML or (depending on the
developer) personal e-mails or Bugzilla bugs. You might want to check
out a few pages on the wiki regarding how we handle contributions, or
pop in #gentoo-proxy-maint on Freenode.

[1] https://gentoo.org/get-started/philosophy/social-contract.html
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: emerge conflict

[Kai Krakow]

Am Mon, 19 Sep 2016 21:17:36 +0100
schrieb Neil Bothwick :

> On Mon, 19 Sep 2016 13:01:39 -0400, Philip Webb wrote:
> 
> > > I'm surprised you needed to jump through such hoops.
> > > I updated 2 stable systems to perl 5.22 last week
> > > and emerge @world took care of all blockers,
> > > although I did need to run perl-cleaner afterwards.
> > 
> > I never run 'emerge world' without '-p' :
> > it's the lazy way to manage a Gentoo system & asks for trouble.  
> 
> What makes you think I didn't use -p? I have a cron job that runs
> emerge -pXXX @world after syncing and mails me the output, and I
> always use -a when running emerge in a shell.
> 
> The point is that, whether I used -p, -a or neither, portage handled
> it all for me.

You could also try porticron... ;-)

-- 
Regards,
Kai

Replies to list-only preferred.


pgpxj7jnFAFko.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Mon, 19 Sep 2016 14:56:59 -0700
schrieb Grant :

> A while back I was having networking issues.  I eventually tried
> drastically lowering the MTU of all the systems onsite and the issues
> disappeared.  I always thought the issue was due to the MTU on our
> modem/router.  Today I read that AT DSL requires a 1492 MTU so I
> increased the MTU of our systems up to 1492 and haven't had any
> issues.  Do certain ISPs require you to change the MTU of your entire
> network, or is this likely due to our AT modem/router itself?

Are you using tunnels or a firewall that blocks related "icmp
fragmentation needed" packets?

Please also try to find out if you're experiencing packet loss. If
fragmented packets cannot be reassembled due to some packets lost, you
will probably find connections freezing or going really slow.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Plasma upgrade: Part Deux.

[Kai Krakow]

Am Mon, 19 Sep 2016 20:05:19 -0700
schrieb Daniel Frey :

> So, I have a week off and have time to mess around trying to upgrade
> to Plasma once again.
> 
> I have got it mostly-somewhat upgraded, but I have two bizarre
> problems.
> 
> The first one is I have two volume controls in the tray. I have no
> idea why, and both seem to present slightly different controls. Could
> this be related to pulseaudio?

There's kmix and there's the systray integrated mixer. Disable either
one of them. With modern versions of plasma I prefer the plasma
integrated mixer and uninstalled kmix.

You can disable the other mixer in the systray properties.


-- 
Regards,
Kai

Replies to list-only preferred.