Ludovic Bellière <belliere.ludovic@???> wrote:

> You could also explore alternatives to zoom, like the FOSS (jitsi)[https://jitsi.org/].

FWIW, of all the options I've used on my (rather old, 2005 model) Mac, Zoom has the lowest load. Jitsi is considerably higher, and I have to manually turn down the video to the lowest setting to get the CPU usage at anything but maxed out.



mett <mett@???> wrote:

> When you are sure your LAN is OK,
> you can just ping with different size and options:
> 1/the pppoe concentrator of your provider,
> which is usually the first hop from your WAN address,
> 2/the next hop
> 3/the next-next hop
> and so on.

Matt's TraceRoute (mtr) is handy for troubleshooting. It's sort of a cross between ping and traceroute - continuously shows round trip times and packet loss to each hop down the route. When you are in a situation where you think you are losing packets, keep it running and watch the stats while you are doing things that stress the network - dropped packets tend to show up fairly quickly.


> That said, DSL is quite old technology,
> according to Wikipedia, the latest protocol
> allows 24Mbit/s upstream and 3.3Mbit/s downstream
> (those are just standards number, so with overhead
> you will certainly get way less).

That sounds like ADSL2, which is only one variant of DSL. DSL is definitely not old tech, it's pretty well the mainstay of all non-cable connections in the UK - whether it be ADSL2 (up to 24M down, earlier ADSL was up to 8M down), VDSL (or in marketing speak, "superfast" or FTTC) which in the UK does up to 80M down, or now they are trying to roll out gFast in some places which does some much higher speed but only over ridiculously short distances (literally from pole to house).


As to the original question ...

MTR is a useful tool for visualising data, either on it's own with your own hand-rolled scripts, or with Cacti. You can pick up interface traffic stats from somewhere in /proc/net - or Cacti will (IIRC) automate that for you (but only does down to 5 minute resolution by default).
At my last place I put in place monitoring using some bash scripts and MTR - before that we had no idea what was using the bandwidth, only that the VoIP didn't work very well at busy times.
The next step was to put in place traffic shaping - which you can do yourself with the native tc tools (I suspect replaced with something in the netfilter tools now), or (as I did) use Shorewall to give a higher level of abstraction (along with routing and firewalling.


Simon