[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: putty go slow



mick crane <mick.crane@gmail.com> 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.

> /sbin/ifconfig
> 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
conclusive.

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 217.172.177.159  netmask 255.255.255.0  broadcast 
>> 217.172.177.255
>>         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
Celejar noted.

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.

Peter


Reply to: