Hey Unraiders,

 

i got an issue and i am not sure if it is a bug or misconfiguration/understanding.

my unraid has onboard nics, 1x 1gb intel and 1x 2,5gb realtek

due to networking cable issues onsite i have to use on of these ports for my own computer and the other one for unraid to connect to the the switch some rooms away.

therefore i have setup the networking via bridge mode with eth0/1

my computer is connected to the 2.5gb nic and the switch with the intel 1gb

 

my pc has also a 2.5gb nic and when i copy files, no matter in which direction, and those single file(s) are big enough to take more than ~3sec of transfer at full speed, unraid seems to kill the connection/nic on the intel nic. this means, pinging and any traffic gets aborted for as long as the transfer is taking time between the 2x 2.5gb nics.

 

eth0 e1000e is the intel one

eth1 r8169 is the realtek 2.5gb

if have tried this with and without the plugin for realtek RTL8125 Drivers

 

is there any way to keep the cableing and avoid this timeout/connection drop issue?

 

i would appreciate any help

 

regards

Edited July 26, 20241 yr by astronax

Post the diags after you experience the issue.

oh right, absolutely. just moved a 5gb video file and network was completely unusable on my computer in the meantime, unraid was not available for the rest of the network at the same time

 

any ideas what i am doing wrong ?

casy-diagnostics-20240727-0907.zip

Probably unrelated but you appear to have a container constantly restarting, this is causing log spam, check the uptimes to see if you can find which one, there's also a damaged Basic.key also doing spam, delete that file from the flash drive.

 

I do see still some issues with the Intel NIC:

Jul 27 09:06:39 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:41 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:52 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:54 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:56 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

etc

 

See if you can use a different NIC

47 minutes ago, JorgeB said:

Probably unrelated but you appear to have a container constantly restarting, this is causing log spam, check the uptimes to see if you can find which one, there's also a damaged Basic.key also doing spam, delete that file from the flash drive.

 

I do see still some issues with the Intel NIC:

Jul 27 09:06:39 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:41 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:52 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:54 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jul 27 09:06:56 casy kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

etc

 

See if you can use a different NIC

yes the basic.key makes sense, i have upgrade to plus, i see if i can find the key on the drive and delete it : Update: found and deleted

 

yes i know the container, i have stopped it, this happens from time to time and i was not able to figure out why it keeps restarting, should not be affecting, but it is stopped now

tested again with a large file and issue remains the same, once the transfer starts with fullspeed, nothing else can be done on the network, it appears to be offline for this time

 

ok this is new to me, what does this mean for the intel nic?

i have 2 nics inside unraid, both are in use

 

Edited July 27, 20241 yr by astronax

Looks like a hardware issue, look for a bios update and/or try 7.0.0-beta, since it uses a much newer kernel, if issues persists it may be a bad NIC.

1 hour ago, JorgeB said:

Looks like a hardware issue, look for a bios update and/or try 7.0.0-beta, since it uses a much newer kernel, if issues persists it may be a bad NIC.

grr sounds not good, i am already at the latest bios (beta) from jan 2024, there is nothing new.

thanks for looking into this, i may try the 7 beta once there is time

 

23 hours ago, JorgeB said:

Looks like a hardware issue, look for a bios update and/or try 7.0.0-beta, since it uses a much newer kernel, if issues persists it may be a bad NIC.

okay i have tested beta 7.0.0.2 and it is not solving the issue

but i have now recognized that it is only occurring during writes to unraid

 

so copying files from unraid via 2.5gb nic to my computer everything is working

but if i copy files from my PC to UNRAID there is packet loss while pinging it on both nics, but the file transfer via smb keeps going, and as soon as it ends it restores, and packet loss goes to 0

 

also the speed writing from pc to unraid is limited to 120mb/s, but this should be more with 2,5gb

the used drive is an NVME with ZFS and is capable of speeds above 2,5gb in writing

Spec Sheet for Sequentials, where writing single files >5gb

Sequential Read 4,800 MB/s

Sequential Write 4,100 MB/s

 

using openspeedtest on unraid i get >2gbit down/up and also packet loss for uploading (pc->unraid) so it is not related to smb ? but high writings seems to tricker the issue

 

i think this is an unraid issue, not a hardware issue

may be the writing zfs ram cache? or the bridge?

having a 2,5gb and 1gb nic in same bridge is not working on speeds higher than 1gb?
 

 

 

Edited July 28, 20241 yr by astronax

i remembered that i have changed the zfs memory limit and have now removed this configuration

rebooted unraid, tested again

 

the speed is now below 100mb on the 2.5nic, and the packet loss to the switch behind unraid is starting ~300mb of transfer, unraid has 64gb of ram

there is no packet loss to unraid itself as it seems

1 hour ago, astronax said:

having a 2,5gb and 1gb nic in same bridge is not working on speeds higher than 1gb?

This is normal, it will be limited to the slower one.

ok i have switched the cables on unraid, so my pc is now connected to the 1gb intel nic on unraid while the main cable is connected to the 2.5gb, no more packet loss when transferring

i consider this a solution but not the ideal condition