Jump to content
We're Hiring! Full Stack Developer ×

Network keep switching to 100mbps


Go to solution Solved by Frank1940,

Recommended Posts

Hi everyone, I'm trying to figure out what is happening to my server and how to diagnose.

 

I am using CAT6 cables, and new ones too. Also tried different cables including cat 5e cables.

 

When plugging in the server (or unplug/replug) the server works at 1000mbps in full duplex. Works totally fine. At some point in a few days it reverts to 100mbps until I replug with the same cables. It is plugged in directly into my home router.

 

Any ideas on how to diagnose / solve? Any advice would be much appreciated.

Link to comment

Speculation...

 

If sufficient errors were detected, the link might auto re-negotiate the link speed.

That might fail for 1 GbE, then retry and succeed for 100 MbE.

 

Can you disable auto negotiation, and set the link to only 1 GbE at the router?  At the server?

 

-- Tom

 

Link to comment

another speculation...

 

Your router or NIC maybe set to "green mode" which means "drop down to 100Mbps to safe energy when idle".

And if the wakeup does not work for any reason, it will stay at 100 forever.

So check the port settings in the router (most likely the culprit).

 

Link to comment
21 hours ago, dlikhten said:

When plugging in the server (or unplug/replug) the server works at 1000mbps in full duplex. Works totally fine. At some point in a few days it reverts to 100mbps until I replug with the same cables. It is plugged in directly into my home router.

 

 

I would suggest getting a Gb switch.  Each device you plug into router (or switch for that matter) will increase the power used.  It is my opinion that you should have only two things plugged into your cat5 ports on your router--  The WAN cable to the modem and the LAN cable to the switch.  That will prolong your router life, which probably costs about five times the cost of that switch, by reducing its temperature.   8 port switches start at a $20US and 5 port switches start at about $15US.

Link to comment

Okay 3 replies, so gonna address all 3:

 

1) I do already have a small switch right by the router, I needed more plugs, and it is gigabit.

 

2) I did not know about green settings I will check the router HOWEVER

 

3) I will plug everything into the switch. If it does indeed help with power draw AND improve the lifetime of then router. The switch does indeed cost peanuts comparatively.

Link to comment
6 minutes ago, MAM59 said:

if you plug it into the switch, look there (in case it is a managed one and allows looking, the unmanaged cheap ones do not know about green mode at all)

 

I apparently was already plugged into a switch. This was a very cheap unmanaged one so no internal settings are exposed. However I did switch the duplex mode from auto negotiation to 1000mbps full duplex on the router. Don't know if that will be significant enough. Guess I'll know more in about a day.

Edited by dlikhten
Link to comment
7 minutes ago, dlikhten said:

I apparently was already plugged into a switch.

ok, then forget my speculation, it does not apply to you.

 

turn on logging at the server, wait for speed drop to happen and save the logs. maybe there is something that reveals a clue in which direction to search?

A speed change never slips away unnoted.

 

Link to comment
35 minutes ago, dlikhten said:

MAM59. Absolutely!!!! How do I go about this?

Simple.

with the unraid gui select "tools" from the side and "diagnostics" from the main menu

grafik.thumb.png.d042563531cfbd137aadd50963848406.png

There you will find an button to generate and download the diagnostic zip file.

Create and save one whilst you have 1000Mbs, then wait until the line slows down and create another zip. Upload both of them here.

 

Link to comment
  • Solution

I had a quick note at your Diagnostics file and found this in the   ifconfig.txt   file in the   /system   folder:

 

image.png.01bb9194470864580403095f72043793.png

 

 

Notice the number of  'RX' errors.  I check five other Diagnostics files from five other different servers and found zero 'RX' errors.   I would first try another port on the switch.  If your cable is a quality cable and after changing ports, you still have speed drops, I would be looking for a new NIC board.

 

BTW, you can look at the this ifconfig report any time you want by opening up the GUI terminal  (the    >_    icon on the right side of the GUI toolbar) and typing the following on the command line:

ifconfig

 

 

EDIT:  I would start checking and recording the error numbers over the next few days.  Perhaps, there is some type of pattern...

Edited by Frank1940
Link to comment
1 hour ago, dlikhten said:

Just switched ports, and still see RX errors rising. Maybe the NIC is just bad? This is an old old motherboard, so no USB3.0 for a usb-based network adapter.

 

1 hour ago, JonathanM said:

No PCIE slots?

I just looked on Amazon and there are Gb Network cards for both PCI-E and PCI slots.   A quick check also found some for PCI on E-bay.

Link to comment

yeah, reception errors should not happen these days anymore. this is surely a hardware problem. Beside a bad card, another possible source would be a badly shielded cable close to a powerful electrical machine like an elevator or something else with an electrical engine. But this is very rare, so going for a different card surely is the better way to go.

(but if those things are that old already, going for a new computer might be wise too :-))) )

 

Link to comment

No need to wait for a 2nd diagnosis, it already happened:

May  7 05:44:33 PirateTrove kernel: tg3 0000:02:00.0 eth0: Link is down
May  7 05:44:33 PirateTrove kernel: bond0: (slave eth0): link status definitely down, disabling slave
May  7 05:44:33 PirateTrove kernel: device eth0 left promiscuous mode
May  7 05:44:33 PirateTrove kernel: bond0: now running without any active interface!
May  7 05:44:33 PirateTrove kernel: br0: port 1(bond0) entered disabled state
May  7 05:44:34 PirateTrove  dhcpcd[916]: br0: carrier lost
May  7 05:44:34 PirateTrove  avahi-daemon[5938]: Withdrawing address record for 192.168.0.97 on br0.
May  7 05:44:34 PirateTrove  avahi-daemon[5938]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.0.97.
May  7 05:44:34 PirateTrove  avahi-daemon[5938]: Interface br0.IPv4 no longer relevant for mDNS.
May  7 05:44:34 PirateTrove  dhcpcd[916]: br0: deleting route to 192.168.0.0/24
May  7 05:44:34 PirateTrove  dhcpcd[916]: br0: deleting default route via 192.168.0.1
May  7 05:44:34 PirateTrove dnsmasq[6890]: no servers found in /etc/resolv.conf, will retry
May  7 05:44:36 PirateTrove  ntpd[1052]: Deleting interface #8 br0, 192.168.0.97#123, interface stats: received=2052, sent=2068, dropped=0, active_time=539210 secs
May  7 05:44:36 PirateTrove  ntpd[1052]: 216.239.35.0 local addr 192.168.0.97 -> <null>
May  7 05:44:36 PirateTrove  ntpd[1052]: 216.239.35.4 local addr 192.168.0.97 -> <null>
May  7 05:44:36 PirateTrove  ntpd[1052]: 216.239.35.8 local addr 192.168.0.97 -> <null>
May  7 05:44:36 PirateTrove  ntpd[1052]: 216.239.35.12 local addr 192.168.0.97 -> <null>
May  7 05:44:37 PirateTrove  emhttpd: read SMART /dev/sdf
May  7 05:44:58 PirateTrove kernel: tg3 0000:02:00.0 eth0: Link is up at 100 Mbps, full duplex
May  7 05:44:58 PirateTrove kernel: tg3 0000:02:00.0 eth0: Flow control is on for TX and on for RX
May  7 05:44:58 PirateTrove kernel: bond0: (slave eth0): link status definitely up, 100 Mbps full duplex
May  7 05:44:58 PirateTrove kernel: bond0: (slave eth0): making interface the new active one
May  7 05:44:58 PirateTrove kernel: device eth0 entered promiscuous mode
May  7 05:44:58 PirateTrove kernel: bond0: active interface up!
May  7 05:44:58 PirateTrove kernel: br0: port 1(bond0) entered blocking state
May  7 05:44:58 PirateTrove kernel: br0: port 1(bond0) entered forwarding state
May  7 05:44:58 PirateTrove  dhcpcd[916]: br0: carrier acquired
May  7 05:44:59 PirateTrove  dhcpcd[916]: br0: rebinding lease of 192.168.0.97

So you have lost your connection completely, and 20s later it reastablished it with only 100mbs.

That ancient "tg3" seems to have produced lots of troubles during the ages, you will find a lot of reports. The driver and linux never really made friends it seems. In 2006 they managed to produce something working and I assume, this code is still used today. But the linux kernel moved on, there are many chances that today the driver does not work well anymore and nobody will fix him.

 

But scrolling through your logs I saw some other issues you may think about and maybe reconsider:

 

* you are running mover every hour, thats ok. But you also want to spin down drives to safe energy. Thats ok too. But both of them do not work together. Mover will wake up the drives every hour just to shut them off again after the defined timeout. This will stress the drives more instead of saving energy, they will wear out much faster. I would say you you should run mover less frequent, maybe once a day?

 

* you have activated bonding for the NIC, although there is no 2nd NIC to be bonded with. It does not harm, but it is useless and only consumes extra time. So I would say "turn off bonding"

 

Nothing more to complain yet (but, why does somebody in 2023 still uses XVID codec for Startrek Picard ? ? ? 🤣 )

 

  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...