Packet loss on LAN...

[eccerr0r]

Yeah network looks sick...

1065 packets transmitted, 975 received, 8.4507% packet loss, time 1070433ms
rtt min/avg/max/mdev = 0.704/0.839/1.838/0.088 ms

Swapped out the network switch... happy again

179 packets transmitted, 179 received, 0% packet loss, time 179176ms
rtt min/avg/max/mdev = 0.714/0.832/0.980/0.085 ms

Now whether to just pitch this 8-port 10/100 switch or figure out why it's losing packets... Using the 24-port in its place is kind of overkill but it's also only 10/100...

[stj]

probably bad caps in it.

[sam_sam_sam]

Is the device running real warm because if it is it been my experience with them it time for a new one because the newer ones really do not have many or none electric type of capacitors anymore and found a micro controller running very very warm to almost hot

It is not worth my time fool with them

[televizora]

Most likely the IC on the switch is overheating and about to fail.

[eccerr0r]

Well this isn't exactly a new network switch behavior when they fail, seems to be a fairly common way to die. Quick cap check looks good.

Oh well, nothing lost, just time gained (was a trash pick and got a few years of service from it, at least!). I should replace with a Gbit switch but this segment of my network I quarantined all the 10/100 machines and printers and a slow 10/100 was a perfect fit!

10Mbit should not have been as slow as it was, I wonder how many people would have just dismissed the packet loss as typical behavior of 10Mbit when they're used to Gbit or 10Gbit Ethernet!

[televizora]

I think that it is needless to say that you can buy 1Gbps 8 port switch for 20$ or less.
And 100mbps are even cheaper. As cheap as 7$

[eccerr0r]

Or I can keep using the 24 port 10/100 I had as a spare, no additional cost!

[retiredcaps]

Originally Posted by eccerr0r

Now whether to just pitch this 8-port 10/100 switch or figure out why it's losing packets..

It's possible that a power outage, change in the end devices (reboot, software upgrade), etc changed something so that duplex negotiation is not working properly. This was a common problem early on with poor drivers, reboots, etc, etc.

One side thinks it is 10/half and other thinks 10/full. Same for 100.

[eccerr0r]

I think I tried power cycling the switch and it still behaved improperly, but just swapping in that 24-port switch made the lost packets go away. I guess I should try sticking it in cold to see how that afflicted switch behaves.

I think I'm only using like 5 ports on this 8 port switch, using that 24-port is way overkill, at least it's not also a Gbit switch...

---

Plugged in switch cold after it being out of service for 20 hours or so...
448 packets transmitted, 448 received, 0% packet loss, time 89799ms
rtt min/avg/max/mdev = 2.376/2.619/3.316/0.125 ms

Well, not exactly the same target or same rate, but looks OK. This is to my printer instead of the K6-233, but I had been having poor performance to the printer as well.
This switch has a K6-233 (10M), a printer (10M), a DECstation (10M), a test station (100M), and uplink connected(100M).

Hmm...will run this a few days to see if it degrades again, if it degrades again I'll have to figure out how to shoehorn a 24-port switch where an 8-port switch fit... else I'll need to find a smaller switch...

[televizora]

Originally Posted by eccerr0r

10Mbit should not have been as slow as it was, I wonder how many people would have just dismissed the packet loss as typical behavior of 10Mbit when they're used to Gbit or 10Gbit Ethernet!

10Mbps is 1.25MB/sec. It's not fast at all, but I would not dismiss any network problems. Losses in any network are because of some problem, not the nature of the network, unless they are accounted for and the network is meant to function using lossy medium, like WLAN, where losses are imminent and can't be avoided, because of interference.

[retiredcaps]

Originally Posted by eccerr0r

I think I'm only using like 5 ports on this 8 port switch, using that 24-port is way overkill, at least it's not also a Gbit switch...

If you only need 4 ethernet/fast ethernet ports, old wifi routers are usually given away for free. Just turn off the wifi and use the 4 port ethernet switch built in. Lot's of old 802.11b only Linksys/Cisco routers available.

[redwire]

I've had either the 12V wall-wart caps or the switch's internal electrolytic caps go bad. I'd take a look at them.
A new one is cheap but these things run hot they don't last more than a couple years.

[eccerr0r]

Still seems to be working... strange.
Another weirdness is that the 9v wall wart won't power a 12v 1a lamp... completely dark, yet it still powers the switch just fine. Hmm.

Found another 10/100 ... hub? switch? Says switching hub, whatever that means. It has a 7.5V wall wart to test...except it's a linear. Would just use it, except it has a ... fan

[eccerr0r]

Hmm Flood Ping testing... From: Gbit Ethernet machine To: 10Mbit Ethernet machine:

25265 packets transmitted, 25060 received, 0.811399% packet loss, time 18423ms
rtt min/avg/max/mdev = 0.545/0.575/0.997/0.022 ms, ipg/ewma 0.729/0.586 ms

I suspect the faster machine could generate another ping faster than the 10Mbit machine to generate a response and the two packets collide causing a lost packet... 1% isn't too bad I guess, better than that 8% earlier.

That 10Mbit machine flood pinging my 10Mbit printer however... 0 packet loss.

So now it seems to be working once more, maybe it did somehow switch into the wrong mode somehow. Still unsure how, power has been fairly stable...

[televizora]

Originally Posted by eccerr0r

I suspect the faster machine could generate another ping faster than the 10Mbit machine to generate a response and the two packets collide causing a lost packet... 1% isn't too bad I guess, better than that 8% earlier.

A standard ICMP packet is 74 bytes or 592 bits. If you send 1 packet per second, this is 592 bits/sec.
How many pings simultaneously do you think you need to bottleneck even a 10Mbps network connection with a speed about 10*485*760bits/sec? I will answer you. You need to send about 17*712,43 pings per second. Ping is not a measure of network losses. And having losses when you send only 592bits/sec means that you have a problem.

[Per Hansson]

Yes, you can set the size with the -l parameter in Windows, like so:
ping -l 60000
Should be around a megabit or so.
There are better ways, like copying a file over the network of course
But when a switch is really bad I find that this test works quite well...

[televizora]

Originally Posted by Per Hansson

There are better ways, like copying a file over the network of course

Better copying a file over the network, while simultaneously pinging the other computer. Losses in a bad network tend to appear, when the consumed bandwidth increases. It is not very sophisticated test, although...

Originally Posted by Per Hansson

Yes, you can set the size with the -l parameter in Windows, like so:ping -l 60000

This is not very reliable. Considering that MTU of Ethernet is 1500, this means that it will be fragmented. If fragmentation is not allowed or the device handles it poorly, this can lead to timeouts, even if there isn't any actual problem with the network.

[stj]

Originally Posted by televizora

A standard ICMP packet is 74 bytes or 592 bits. If you send 1 packet per second, this is 592 bits/sec.

does that figure include start-bit, stop-bit, parity etc.??

[eccerr0r]

Yeah, seems like that poster ignored a lot of stuff when assuming that windows ping is the only ping in town, and would be mindblown with the mere options Un*x ping offers... and even more so with a version that does away with the limits even it offers to prevent people from taking down networks, DoS-like...

[televizora]

Originally Posted by eccerr0r

Yeah, seems like that poster ignored a lot of stuff when assuming that windows ping is the only ping in town, and would be mindblown with the mere options Un*x ping offers... and even more so with a version that does away with the limits even it offers to prevent people from taking down networks, DoS-like...

I ignored nothing.
1. Ping DDOS works by sending ICMP packets using to the broadcast address of a network, using spoofed IP - the IP of the attacked host.
This is amplification attack.
2. Far more useful is TCP SYN DDOS.
Sending SYN, never returning ACK, keeping the server waiting, clogging up all the ports.
3. SYN ACK reflection. Spoofed IP, sending SYN to hosts in the network, pretending to be other host. The hosts send ACK. If the attacked host does not confirm, they continue sending ACK and attempting to establish a 3 way handshake. Because if SYN is received, but SYN-ACK is never received, the nature of the TCP makes the host assume that the the packet is lost, thus retransmits it. This is again amplification attack.
Unless you intentionally target and attack a host, ping consumes insignificant bandwidth and a single computer sending pings will have a hard time clogging up a network.
Unless you:
1. Have a network with low RTT
2. Use ping with -A parameter, so frequency of requests is matched to RTT.
3. You use a packet size way higher than the MTU, which is 1500 bytes for Ethernet.
4. If you do this and receive losses, the network might not be the problem. But fragmentation and poor handling of packets with size higher than Ethernet frame size/1500/
If we suppose that we have a perfect network with low RTT(1ms) and we use the maximum size of IP packet(64K) and use ping with -A parameter, then
(64k x 1000ms(1sec)/1024)x8=~62MB/sec or 500Mbps. RTT even for a local network is rarely 1ms. Only this way you can clog up a network.