Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #207156 > unrolled thread

putty go slow

Back to article view | Back to linux.debian.user

Contents

  putty go slow mick crane <mick.crane@gmail.com> - 2019-04-08 22:40 +0200
    Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-09 00:00 +0200
    Re: putty go slow lev@levlaz.org - 2019-04-09 00:10 +0200
      Re: putty go slow mick crane <mick.crane@gmail.com> - 2019-04-09 00:40 +0200
        Re: putty go slow lev@levlaz.org - 2019-04-09 06:00 +0200
        Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-09 08:50 +0200
          Re: putty go slow mick crane <mick.crane@gmail.com> - 2019-04-09 13:10 +0200
            Re: putty go slow Dan Ritter <dsr@randomstring.org> - 2019-04-09 13:20 +0200
            Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-10 12:10 +0200
              Re: putty go slow Michael Stone <mstone@debian.org> - 2019-04-10 14:10 +0200
                Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-10 15:10 +0200
                  Re: putty go slow mick crane <mick.crane@gmail.com> - 2019-04-10 15:30 +0200
                    Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-10 16:10 +0200
                  Re: putty go slow Michael Stone <mstone@debian.org> - 2019-04-10 15:40 +0200
                    Re: putty go slow Peter Wiersig <peter@friesenpeter.de> - 2019-04-10 16:40 +0200
              Re: putty go slow rhkramer@gmail.com - 2019-04-10 16:20 +0200
                Re: putty go slow rhkramer@gmail.com - 2019-04-10 16:30 +0200
                  Re: putty go slow rhkramer@gmail.com - 2019-04-12 14:50 +0200
                Re: putty go slow Michael Stone <mstone@debian.org> - 2019-04-10 17:20 +0200
          Re: putty go slow Celejar <celejar@gmail.com> - 2019-04-09 19:50 +0200

#207156 — putty go slow

hello,
It may not be mail list specific but maybe somebody knows ?
If I connect windows 10 to debian Buster with putty and edit a file.
Usually the little cursor beetles across the screen over the characters
but then sometimes it is noticeably sluggish.
This is probably something to do with the network connection.
Any idea to find out what might cause this sluggardly behavior ?
apologies for off topic but I'm unlikely to join a win10 user group.

mick
-- 
Key ID    4BFEBB31

[toc] | [next] | [standalone]

#207158

You'd at least have to explain the type of connection from the putty
client to the server.  But your symptoms don't ring a bell over here
aside from a saturated uplink.

Peter

[toc] | [prev] | [next] | [standalone]

#207160

Hey Mick, 

On Mon, Apr 08, 2019 at 09:38:48PM +0100, mick crane wrote:
>hello,
>It may not be mail list specific but maybe somebody knows ?
>If I connect windows 10 to debian Buster with putty and edit a file.
>Usually the little cursor beetles across the screen over the characters
>but then sometimes it is noticeably sluggish.
>This is probably something to do with the network connection.
>Any idea to find out what might cause this sluggardly behavior ?
>apologies for off topic but I'm unlikely to join a win10 user group.

This very much sounds like a networking problem. Could you share more
about where the sever is located that you are connecting to in relation
to where you are?

>
>mick
>-- 
>Key ID    4BFEBB31
>

-- 
Lev Lazinskiy
lev@levlaz.org
(415) 470 - 2142

[toc] | [prev] | [next] | [standalone]

#207162

On 2019-04-08 23:03, lev@levlaz.org wrote:
> Hey Mick,
> 
> On Mon, Apr 08, 2019 at 09:38:48PM +0100, mick crane wrote:
>> hello,
>> It may not be mail list specific but maybe somebody knows ?
>> If I connect windows 10 to debian Buster with putty and edit a file.
>> Usually the little cursor beetles across the screen over the 
>> characters
>> but then sometimes it is noticeably sluggish.
>> This is probably something to do with the network connection.
>> Any idea to find out what might cause this sluggardly behavior ?
>> apologies for off topic but I'm unlikely to join a win10 user group.
> 
> This very much sounds like a networking problem. Could you share more
> about where the sever is located that you are connecting to in relation
> to where you are?

the PCs are physically adjacent connected with the RJ45 ( isn't it ) 
cables through what is supposed to be a switch I got in B&Q several 
years ago.
but I think it might be a hub.
Perhaps that is the culprit ?
but then again it might be something to do with windows keyboard 
activity
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#207169

Hey Mick, 

On Mon, Apr 08, 2019 at 11:31:26PM +0100, mick crane wrote:
>On 2019-04-08 23:03, lev@levlaz.org wrote:
>>On Mon, Apr 08, 2019 at 09:38:48PM +0100, mick crane wrote:
>>>This is probably something to do with the network connection.
>>>Any idea to find out what might cause this sluggardly behavior ?
>>>apologies for off topic but I'm unlikely to join a win10 user group.
>>
>>This very much sounds like a networking problem. Could you share more
>>about where the sever is located that you are connecting to in relation
>>to where you are?
>
>the PCs are physically adjacent connected with the RJ45 ( isn't it ) 
>cables through what is supposed to be a switch I got in B&Q several 
>years ago.
>but I think it might be a hub.
>Perhaps that is the culprit ?
>but then again it might be something to do with windows keyboard 
>activity

That is very interesting, I was assuming that you were connecting to a
remote server. In this case you may have a bad cable, or your second
assumption may also be correct. I am not sure how to best debug
something like this. I have no used putty in years, maybe an easy test
to rule out putty would be to use git bash instead?

https://git-scm.com/

There are other ways to get bash and ssh to work in windows, but I find
that installing the git package above is the simplest approach. 

-- 
Lev Lazinskiy
lev@levlaz.org
https://levlaz.org/about-me

[toc] | [prev] | [next] | [standalone]

#207170

mick crane <mick.crane@gmail.com> writes:
>
> the PCs are physically adjacent connected with the RJ45 ( isn't it )
> cables through what is supposed to be a switch I got in B&Q several 
> years ago.

Almost, RJ-45 is the specification for the plug and jacks, what you're
having here is ethernet wiring in twisted pairs between client and
server connected by a hub.  Or switch, please clarify that as that
changes a lot.

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.

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.

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.  I suspect that if there's a network problem
it would manifest in some higher relative values on your side.

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.

Peter

[toc] | [prev] | [next] | [standalone]

#207175

On 2019-04-09 07:46, Peter Wiersig wrote:
> mick crane <mick.crane@gmail.com> writes:
>> 
>> the PCs are physically adjacent connected with the RJ45 ( isn't it )
>> cables through what is supposed to be a switch I got in B&Q several
>> years ago.
> 
> Almost, RJ-45 is the specification for the plug and jacks, what you're
> having here is ethernet wiring in twisted pairs between client and
> server connected by a hub.  Or switch, please clarify that as that
> changes a lot.
> 
> 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.
> 
> 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.
> 
i
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 ?
It's got "8 port switch" printed on it but if there is network activity 
all the lights seem to flash.

/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
         TX packets 73403188  bytes 102853469866 (95.7 GiB)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 21  memory 0xdffe0000-e0000000

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 ?

mick


> 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.  I suspect that if there's a network problem
> it would manifest in some higher relative values on your side.
> 
> 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.
> 
> Peter

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#207176

mick crane wrote: 
> On 2019-04-09 07:46, Peter Wiersig wrote:
> > mick crane <mick.crane@gmail.com> writes:
> > > 
> > > the PCs are physically adjacent connected with the RJ45 ( isn't it )
> > > cables through what is supposed to be a switch I got in B&Q several
> > > years ago.
> > 
> i
> 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 ?

That is correct.


> It's got "8 port switch" printed on it but if there is network activity all
> the lights seem to flash.
> 
> /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
>         TX packets 73403188  bytes 102853469866 (95.7 GiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>         device interrupt 21  memory 0xdffe0000-e0000000

You see the RX dropped 5642? That's bad.

There's a chance that it's a bad ethernet cable; otherwise the
hub/switch is faulty. Given that it's labelled "switch" but all
the ports flash on every packet, it might well be that.

Unmanaged gigabit switches are cheap; I recommend that you
replace it if swapping cables doesn't solve the issue.

-dsr-

[toc] | [prev] | [next] | [standalone]

#207232

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

[toc] | [prev] | [next] | [standalone]

#207235

On Wed, Apr 10, 2019 at 12:00:01PM +0200, Peter Wiersig wrote:
>> /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.

5000 drops is insignificant, and you're having him waste his time 
chasing something that isn't a problem.

Michael Stone

[toc] | [prev] | [next] | [standalone]

#207236

Michael Stone <mstone@debian.org> writes:

> On Wed, Apr 10, 2019 at 12:00:01PM +0200, Peter Wiersig wrote:
>>> /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.
>
> 5000 drops is insignificant, and you're having him waste his time 
> chasing something that isn't a problem.

No, I encouraged him to reboot the linux side of the puzzle, reproduce
his problem and then check the counters.  I doubt that that would entour
13 GiB datatransfers if the problem is reproducible, I got the
impression the problem is intermittend and I suggested he goes and swaps
the cables for about $10 and see if that helps or not.

I also stated that that error-rate is not the solution, and I guess that
I wont be able to help him solve this problem.  Dan thought the 5k
counter value would indicate a more serious problem.

I also asked for kernel messages regarding his network card, because I
think in his case the error might lie in the link negotiation or duplex
settings for the relevant machines.

I strive for local networks that would have single digit drops in 47m
packets and I'm willing to spend the money for the equipment to achieve
that.  My quoted ifconfig output comes from a rented server in some
datacenter where I don't have the power to choose anything HW related
apart from my price point for the server cost, and they almost reach my
goal in error counters.  I have no idea how critical micks hardware is
and what budget choices he makes.

You have a nice day please, Michael.  Thanks for your contribution to
debian btw.

Regards,
Peter

[toc] | [prev] | [next] | [standalone]

#207239

On 2019-04-10 14:01, Peter Wiersig wrote:
> Michael Stone <mstone@debian.org> writes:
> 
>> On Wed, Apr 10, 2019 at 12:00:01PM +0200, Peter Wiersig wrote:
>>>> /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.
>> 
>> 5000 drops is insignificant, and you're having him waste his time
>> chasing something that isn't a problem.
> 
> No, I encouraged him to reboot the linux side of the puzzle, reproduce
> his problem and then check the counters.  I doubt that that would 
> entour
> 13 GiB datatransfers if the problem is reproducible, I got the
> impression the problem is intermittend and I suggested he goes and 
> swaps
> the cables for about $10 and see if that helps or not.
> 
> I also stated that that error-rate is not the solution, and I guess 
> that
> I wont be able to help him solve this problem.  Dan thought the 5k
> counter value would indicate a more serious problem.
> 
> I also asked for kernel messages regarding his network card, because I
> think in his case the error might lie in the link negotiation or duplex
> settings for the relevant machines.
> 
> I strive for local networks that would have single digit drops in 47m
> packets and I'm willing to spend the money for the equipment to achieve
> that.  My quoted ifconfig output comes from a rented server in some
> datacenter where I don't have the power to choose anything HW related
> apart from my price point for the server cost, and they almost reach my
> goal in error counters.  I have no idea how critical micks hardware is
> and what budget choices he makes.
> 
> You have a nice day please, Michael.  Thanks for your contribution to
> debian btw.
> 
> Regards,
> Peter

Just looking I had a misspelled entry in hosts file on windows for the 
PC that is name server which can't have been helping matters.
I'll get some decent cables, a couple of these the plastic clip has 
broken off.

mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#207244

mick crane <mick.crane@gmail.com> writes:
> Just looking I had a misspelled entry in hosts file on windows for the 
> PC that is name server which can't have been helping matters.

No, but problems that arise from that manifest in different ways
contrary to what you posted in the initial mail.


> I'll get some decent cables, a couple of these the plastic clip has 
> broken off.

Here I would put my money, if I was betting where your problems come
from.  There's nothing nicer in the datacenter but to open a transport
bag for a fine new cable and click it in the patch port and the NIC of a
new installed machine, audible (lucky me if I can hear it) and tactile
feedback that send shivers of joy down my spine.

Post to here or a new thread if you need another idea, if that cable
swap doesn't help.  I hope it does.

Mick, have you ever read ESRs and Rick Moens howto on how to ask good questions?
http://www.catb.org/~esr/faqs/smart-questions.html

I ask because I almost skipped your initial post because of the way you
asked your question without giving us the technical background into your
setup, which is always hard to get, and during our exchange you'd always
skip past questions and give almost relevant info but with little to zero
context.

Have fun.

Peter

[toc] | [prev] | [next] | [standalone]

#207240

On Wed, Apr 10, 2019 at 03:01:51PM +0200, Peter Wiersig wrote:
>I strive for local networks that would have single digit drops in 47m
>packets and I'm willing to spend the money for the equipment to achieve
>that.  My quoted ifconfig output comes from a rented server in some
>datacenter where I don't have the power to choose anything HW related
>apart from my price point for the server cost, and they almost reach my
>goal in error counters.  I have no idea how critical micks hardware is
>and what budget choices he makes.

A drop in that output indicates that the packet was lost on the local 
machine. It's not a hardware issue on the network so changing out pieces 
of the network isn't going to change it. If it was a higher percentage 
I'd look at whether a NIC with better offload was warranted, or a CPU 
upgrade, or whether the system was running network-related software that 
could be upgraded to something more efficient, etc. There's more 
debugging that could be done if needed, but for .01% I'd write it off as 
a momentary blip, maybe related to load during startup of a network 
service, and ignore it unless it started growing.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#207248

Michael Stone <mstone@debian.org> writes:
> There's more debugging that could be done if needed, but for .01% I'd
> write it off as a momentary blip, maybe related to load during startup
> of a network service, and ignore it unless it started growing.

Yeah, currently I'm working as a monitoring specialist and after getting
the counters I ran the numbers and put my scale against the result.

I recently watched a conference talk[1] on network monitoring and the
consultant quoted the default settings of .01% for warning and .1% for
critical package errors when averaging the traffic over 15 minutes or
so, coming from the monitoring solution defaults, which we use here in
our datacenter.

Peter

[1] german presenter, english slides https://youtu.be/KiKOaeEaKis?t=377
english dubbed https://youtu.be/E9_S1rDJZIQ?t=371

[toc] | [prev] | [next] | [standalone]

#207245

On Wednesday, April 10, 2019 06:00:01 AM Peter Wiersig wrote:
> mick crane <mick.crane@gmail.com> writes:
> > 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.

Maybe, but I've bought things that I think are (5-port) switches (advertised 
as such) for in the range of $10 in various sales or on ebay, and so far, have 
no reason to doubt them.

I guess I'll have to really test in the near future.

Ok, just did a simple test -- on a 5-port switch, with 5 devices plugged in, 
one powered off:
   * solid green lights on 4 ports (when no traffic) indicate the 4 devices that 
are powered up
   * flashing green lights on 2 ports when data  being transferred 

I believe it is a switch -- will check the other switch in service ...

Ok, same thing.

[toc] | [prev] | [next] | [standalone]

#207247

Oh, I should have mentioned that the switches I use are 10/100 megabit, not 
gigabit.  

(I'm not sure, but the switch built into my Edge Router might be Gigabit, but 
that device was closer to $50 (on sale, I'm fairly sure, although I bought it 
at a time when I was having problems with my LAN, so may have paid closer to 
list price).)

On Wednesday, April 10, 2019 10:18:23 AM rhkramer@gmail.com wrote:
> On Wednesday, April 10, 2019 06:00:01 AM Peter Wiersig wrote:
> > mick crane <mick.crane@gmail.com> writes:
> > > 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.
> 
> Maybe, but I've bought things that I think are (5-port) switches
> (advertised as such) for in the range of $10 in various sales or on ebay,
> and so far, have no reason to doubt them.
> 
> I guess I'll have to really test in the near future.
> 
> Ok, just did a simple test -- on a 5-port switch, with 5 devices plugged
> in, one powered off:
>    * solid green lights on 4 ports (when no traffic) indicate the 4 devices
> that are powered up
>    * flashing green lights on 2 ports when data  being transferred
> 
> I believe it is a switch -- will check the other switch in service ...
> 
> Ok, same thing.

[toc] | [prev] | [next] | [standalone]

#207377

On Wednesday, April 10, 2019 10:25:00 AM rhkramer@gmail.com wrote:
> Oh, I should have mentioned that the switches I use are 10/100 megabit, not
> gigabit.
> 
> (I'm not sure, but the switch built into my Edge Router might be Gigabit,
> but that device was closer to $50 (on sale, I'm fairly sure, although I
> bought it at a time when I was having problems with my LAN, so may have
> paid closer to list price).)

Hmm, I hope this doesn't violate the policies of the debian user list -- I 
guess I'll find out soon enough ;-)

Oh, as a data point, today I see a 5-port Gigabit switch on sale for $9.95 
with free shipping.  (If you go to the URL, you will see the price as $14.95 
-- to get the $9.95 price, you have to subscribe to their mail list and then 
you will get a promo code that gives another $5 off.

The sale ends on Sunday (not sure of the exact time).

If i was going to buy one and not yet a subscriber, I'd subscribe, and then 
call them, explain that you have just subscribed, and ask for the promo code 
for this item (and possibly even placing the order while on the phone -- I 
usually buy "online").

(If you subscribe to their mail list, you will occasionally get advertisements 
with promo codes (for various items).)

Disclaimer, I have no affiliation with Newegg, and get renumeration for any of 
this.

https://www.newegg.com/Product/Product.aspx?Item=N82E16833704042&utm_medium=Email&utm_source=IGNEFL041219&cm_mmc=EMC-
IGNEFL041219-_-EMC-041219-Index-_-Switches-_-33704042-S0G&ignorebbr=1

[toc] | [prev] | [next] | [standalone]

#207249

On Wed, Apr 10, 2019 at 10:18:23AM -0400, rhkramer@gmail.com wrote:
>Maybe, but I've bought things that I think are (5-port) switches (advertised
>as such) for in the range of $10 in various sales or on ebay, and so far, have
>no reason to doubt them.
>
>I guess I'll have to really test in the near future.
>
>Ok, just did a simple test -- on a 5-port switch, with 5 devices plugged in,
>one powered off:
>   * solid green lights on 4 ports (when no traffic) indicate the 4 devices that
>are powered up
>   * flashing green lights on 2 ports when data  being transferred
>
>I believe it is a switch -- will check the other switch in service ...
>
>Ok, same thing.

I haven't seen a true hub easily available anywhere in at least a 
decade. Most of the low end parts are built around the same couple of 
highly integrated chips (which are switches). The last generation of 
cheap "hubs" were actually partial bridges, to handle 10Mbps and 100Mbps 
devices.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#207192

On Tue, 09 Apr 2019 08:46:07 +0200
Peter Wiersig <peter@friesenpeter.de> wrote:

...

> 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.  I suspect that if there's a network problem

I think you mean 81.9 million packets.

Celejar

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web