Stuart
Thanks for the reply
At this point it appears a specific LAN client “PS4” is responsible for a
high number of device interrupts.
Hoping to clarify if interrupts In excess of “3000” can cause PPPOE
timeouts.
#############################################################################
#
Lan Streaming cat5 no switch
procs memory page disk traps cpu
r b w avm fre flt re pi po fr sr sd0 int sys cs us sy
id
1 0 0 18636 3825560 1 0 0 0 0 0 0 6872 7 10 0 9 91
0 0 0 18636 3825560 1 0 0 0 0 0 0 2163 7 9 0 4 96
0 0 0 18636 3825560 1 0 0 0 0 0 0 1921 9 11 0 2 98
0 0 0 18636 3825560 1 0 0 0 0 0 0 1943 6 9 0 3 97
0 0 0 18636 3825560 1 0 0 0 0 0 0 1705 6 9 0 3 97
0 0 0 18636 3825560 1 0 0 0 0 0 0 1849 8 10 0 3 97
0 0 0 18636 3825560 1 0 0 0 0 0 0 2276 6 9 0 4 96
############################################################################
Wlan Streaming
procs memory page disk traps cpu
r b w avm fre flt re pi po fr sr sd0 int sys cs us sy
id
1 0 0 18632 3825732 1 0 0 0 0 0 0 368 7 10 0 1 99
0 0 0 18632 3825732 1 0 0 0 0 0 0 365 8 10 0 2 98
0 0 0 18632 3825732 1 0 0 0 0 0 0 355 10 9 0 1 99
0 0 0 18632 3825732 1 0 0 0 0 0 0 362 9 10 0 2 98
0 0 0 18632 3825732 1 0 0 0 0 0 0 356 8 10 0 1 99
0 0 0 18632 3825732 1 0 0 0 0 0 0 361 10 10 0 1 99
0 0 0 18632 3825732 1 0 0 0 0 0 0 365 9 10 0 2 98
0 0 0 18632 3825732 1 0 0 0 0 0 0 383 8 10 0 1 99
#############################################################################
No Lan or Wlan traffic
procs memory page disk traps cpu
r b w avm fre flt re pi po fr sr sd0 int sys cs us
sy id
1 0 0 18628 3825736 1 0 0 0 0 0 0 24 8 10 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 23 6 9 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 28 6 9 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 24 8 10 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 22 7 9 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 25 8 10 0 0 100
0 0 0 18628 3825736 1 0 0 0 0 0 0 24 6 9 0 0 100
Regards
Patrick
> On Dec 15, 2016, at 5:05 AM, Stuart Henderson <s...@spacehopper.org> wrote:
>
> On 2016-12-15, Patrick Dohman <patrick_doh...@centurylink.net> wrote:
>> Stuart
>>
>> Please see below for more info:
>>
>> Please note the 5.7 dmesg is subsequent to a reboot.
>
> Thanks. I was wondering about a bug with LCP echoes I accidentally
> introduced that made it into 5.9 (fixed for 6.0).
>
> Nothing stands out from what you've sent. Some possibilities:
>
> - connection somewhere between the APU and the ISP really is dropping out
> (are you using the same cable for the different locations you placed the
APU
> in? could a cable be bad? check for errors on the ethernet interface)
>
> - machine too busy to handle traffic - maybe tail -f /var/log/messages in
the
> background while "vmstat -w 10" or something is running (maybe under
"script"),
> look for the timeouts in the output and see what cpu is doing at the time
>
>> pass out quick on egress inet6 proto { tcp, udp } from { (pppoe0:network),
>> (athn0:network), (re2:network) } modulate state
>
> btw using (...) causes an extra address lookup to be done when the rule
> is evaluated (i.e. when a packet doesn't match existing state) - you may
need
> this for pppoe0 but you can save a bit of cpu with
>
> pass out quick on egress inet6 proto { tcp, udp } from { (pppoe0:network),
> athn0:network, re2:network } modulate state
>
> (and same for the v4 rule)
>
>> ### --- Optional Runtime Options --- ###
>> set optimization conservative
>
> not likely to be the problem, but you're pretty unlikely to need that.
