Re: putty go slow
- Date: Wed, 10 Apr 2019 12:00:01 +0200
- From: Peter Wiersig <peter@xxxxxxxxxxxxxxx>
- Subject: Re: putty go slow
mick crane <mick.crane@xxxxxxxxx> writes:
> On 2019-04-09 07:46, Peter Wiersig wrote:
>> Is anything else connected to this hub? If your problems occur, is
>> anything else using the hub concurrently? Can you reduce the
>> connections only to server and client and maybe a internet uplink?
>> Network printers can do unimaginably bad things in regard to hubs, and
>> even switches.
A second time to point you to a possible problem with network printers.
If you can reproduce the problem and then try to reproduce without the
network printer you might have possible solution. I came across a best
practice lately to isolate network printers to their own broadcast
segments (VLAN/bridges) and concur.
>> Can you change the hub to a real switch?
>>> but I think it might be a hub.
>>> Perhaps that is the culprit ?
>> Perhaps. Check the "ifconfig" output on the Linux side, maybe reset the
>> server, connect from windows and if you're having problems check the
>> dmesg output regarding the interface.
> how do I tell if it's a switch or a hub ?
> I thought a switch sends data over the required port but a hub sends
> over all the ports ?
Correct, after a learning phase.
> It's got "8 port switch" printed on it but if there is network activity
> all the lights seem to flash.
Ok, that simple you can't distinguish between hubs and switches:
If you connect a new device to your network, the switch has still to ask
for IP->MAC resolutions on unknown IPs, and broadcast packets need to be
transmitted on all ports. But a file transfer for say a linux
distribution ISO should only be flickering 2 LEDs.
I found that there is a price point below which the device is no true
switch anymore and should be replaced. Over here it's 50 EUR or so,
for your quoted 8 ports. Correction: Probably lower at 35 EUR. Mazbe I
had more ports with that other price point.
> enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 10.0.0.3 netmask 255.255.255.0 broadcast 10.0.0.255
> inet6 fe80::219:d1ff:fe41:c769 prefixlen 64 scopeid 0x20<link>
> ether 00:19:d1:41:c7:69 txqueuelen 1000 (Ethernet)
> RX packets 47732498 bytes 13998322190 (13.0 GiB)
> RX errors 0 dropped 5642 overruns 0 frame 0
Your errors are higher when your received packets are half of mine. But
still, 5k of of 47m is a error rate of 0.01%, so a hint, but not
Does the system have any kernel messages for enp0s25 since the last
boot-up? Alternatively produce new messages by disconnecting the
cable for about 5 seconds and reconnect the network cable.
> I've got a Buster PC with apache2, cups, dovecot, roundcube as mail and
> print server.
> a Buster PC I mess about on, a win 10 PC and a printer all connected to
> the "switch"
> the gateway is a PC with pfsense on it which is connected to "switch"
> and its other network card connected to ISP router thing.
> Maybe the sluggishness I sometimes observed is Windows updating itself ?
Is your network speed near your downlink speed? Do you have more than
one Windows 10 machine connected to your network? I doubt that you can
saturate your windows 10 network interface (probably 1 gbps) with enough
bandwidth so that you could see detoriation in a ssh connection, even
less possible if your devices adhere to QoS packet hints.
>> For reference, here's my output:
>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>> inet 184.108.40.206 netmask 255.255.255.0 broadcast
>> ether 00:19:66:f1:43:9e txqueuelen 1000 (Ethernet)
>> RX packets 81994186 bytes 14753508445 (13.7 GiB)
>> RX errors 14 dropped 0 overruns 14 frame 0
>> TX packets 107524155 bytes 14836289080 (13.8 GiB)
>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>> Take note of the 2nd line of RX and TX status lines, there should be no
>> counters there, in my case 14 overruns in regard to 819 million packets
>> is a very low error rate.
and indeed I misread my number and it's a magnitude lower. 81.9m as
but mick's error-rate is 2-3 magitudes higher.
>> If in doubt verify that both sides are set to auto-negotiate and
>> replace both wires from the machines to the hub with new cables.
Like I said, invest in a new set of cables and see if things get better.
You don't need to buy gold-plated ones, but it shouldn't be factory
dropout quality either.