Is checking a network drive too fast? Or is finding it on your computer taking forever?
Is checking a network drive too fast? Or is finding it on your computer taking forever?
This means the interface is ready, but the operating system isn't using it. Just to be sure, are you using static IP addresses? I would also turn off IPv6 and network discovery while fixing this (even if they are needed, just so we can find the problem). Are you guys using 802.1x? If there is any traffic at all right now, it suggests the problem is higher up in the stack. Don't know if you've read this yet: using 10G speeds has some effects on TCP window size: https://learn.microsoft.com/en-us/w...s/...ance-tools
Noted: "IP addresses have always been assigned via MAC address reservations on the DHCP server (the router) " Look for duplicate MAC's. MAC Addresses From the link: "Each MAC address is unique to the network card installed on a device, but the number of device-identifying bits is limited, which means manufacturers do reuse them. Each manufacturer has about 1.68 million available addresses, so when it burns a device with a MAC address ending in FF-FF-FF, it starts again at 00-00-00. " Could be some error of omission or commission with respect to the MAC reservations being made. Compare MAC's and assigned IP addresses. Ensure that there is no overlap between the allowed DHCP IP address range and any Static IP's in use.
Time to take things to another level. Do you know about Powershell? You can use it with the "Get" commands to learn all kinds of stuff about computers, programs, and how they are set up. For instance: https://learn.microsoft.com/en-us/powers...er-2019-ps https://learn.microsoft.com/th-th/window...er-2019-ps&viewFallbackFrom=win10-ps https://stackoverflow.com/questions...rk...in-windows Get commands are safe since they don't make any changes to the system. However, you need to be careful about long scripts or commands that might change things based on what "Get" finds. The third link uses: get-wmiobject win32_networkadapter -filter "PhysicalAdapter = true" | select * to gather all sorts of information. And the command itself can easily be copied and pasted at the Powershell PS> prompt. (Open Powershell as Administrator.) Run those commands in a test area until you feel comfortable doing so and get a sense of what happens. The goal is to take an in-depth look at the network adapter to see if any settings don't match what you expect. On every different computer or how things differ between computers. Note: You can also easily find lots of scripts that collect data from network computers and other devices. Also, about printers: Powershell can get printer info too via Get-Printer and other options. https://stackoverflow.com/questions...-s...powershell Get-CimInstance -ClassName CIM_Printer -ComputerName $arrayOfComputerName
Yes. You read my mind 😉 Sorry I've gone quiet. Been doing a lot of reading about TCP/IP tuning and 10G adapters. Gone into "deep research mode" Have made some changes such as IRPStackSize, receive/transmit buffers, Receive Side Coalescing (RSC) and much more. Also investigating the switches. I read somewhere that there is a low level issue with the MS510TX and MS510TXPP switches. Not firmware - something Netgear would have to tweak. It seems to address my file copies slowing down but they won't disclose what they changed (trade secrets I guess). I've also updated the switches to the latest firmware. They were a tad out of date. Very minimal improvements. I'll keep researching.... My brain hurts... The only setting that wasn't as expected was RSC. This had somehow gotten enabled. I disable it when I install the OS. Everything else is as expected... so far
There might be a small problem, but now I am stepping outside my usual comfort zone. After checking the switches, I found these links: https://www.netgear.com/support/product/MS510TX.aspx and https://www.netgear.com/support/product/...mmonTopics I was wondering if there is a network loop or broadcast storm involved? No harm in asking.
Every idea is a great suggestion! It's worth trying. I tested every situation. No Wi-Fi was turned on. All Wi-Fi NICs are off and router radios are switched off. There are no Ethernet loops anywhere, not even on routers, switches or the devices themselves. I haven't touched any cables around yet, but I double-checked port settings anyway. It looks fine to me. What about broadcast storms? If something were happening like that, it would only affect the 21H2 PC and others. I'd also expect Wireshark to show signs of trouble if this happened. If the 21H2 device caused the storm, I'd see symptoms there too. When I watched the diagnostics on the switches during boot-up and shutdown, nothing strange showed up. I'm going to try "Jumbo frames" next. That sounds like a lot of fun, based on stories from other people who had this experience before.
OMG!! I think I have fixed it.. or 75% of it.. NCSI IPv6 is disabled on all PCs here. Except the 10G nic has a tick in the IPv6 option in the NIC properties. When Windows starts it seems to be using IPv6 for the connect test if the above option is ticked. This causes Windows not to detect the Internet despite it being connected. Unticking this box results in normal connection indicator within 3 seconds. This seems rather bizarre given IPv6 is blocked in the firewall, blocked by policy and blocked at the service level with DisabledComponents:0xff RSC was enabled for both IPv4 and IPv6. My setupcomplete script must have failed. Disabled both settings. DELAY IN NETWORK DISCOVERY I was initially using 2.0.18 of the AQC107 driver, which seems to work. I tried to update to 2.1.21, which failed not compatible with 21H2. I updated to 3.1.6 which is the latest and I thought was working. I found a later AQTion BIOS. I was on 3.1.84 and there was a 3.1.88 BIOS. Went to update that but it said that the firmware 3.1.6 was not compatible with the new bios. Uninstalled the device, rebooted and then updated the NIC BIOS to 3.1.8.8 Started seeing link lost errors in event log at 6seconds after reboot and reconnecting 6 seconds later. Installed v2.2.30 of the firmware and rebooted. Just for the sake of testing, I tried using the 2.0.18 AQC107 driver with the 3.1.8.8 BIOS and the delay returned. So it's a combination of updates that was required. Interesting though that 2.0.18 would install where 2.1.21 would not. I need to test 3.1.6 with the new BIOS. WIll get back to you on that one. OUTCOME Network connected at start up NCSI showing connection witin 3 seconds. Mapped drives showing as connected immediately. No other delays No "Link lost" errors in event log. NIC PROPERTIES Changed receive buffers to 1024 (was 512) Changed transmit buffers to 4096 (was 2048) Added LANManServer parameter IRPStackSize and set to 0x20 (32 decimal) Checked LSO and RSS were enabled - both good. Also tried disabling Interupt Moderation. No difference so re-enabled it. Turned off "Allow Windows to turn off this device to save power" Reboot and test FILE COPIES Copies to client of 55GB file @ 565MB/s for first 10GB then drops down to 235MB/s. This might be my 970 NVMe drive throttling or the ability of the source drive, given it is a spinner. Copies from Client to server of 55GB file 700MB/s dropped to 235MB/s after around 10GB. OTHER TASKS Update MS510TX and MS510TXPP switches to latest firmware - I don't think this was contributing to the issues though. Replaced LAN cables with new cables. Performed several tasks as suggested by replies to this thread. Tested AutoTuning at Experimental setting. Didn't change anything. Using Jumbo frames broke the network connections so put it all back to disabled. I may have missed something. Enable global flow control on all switches. Several forums suggested setting the system to high performance power plan and setting BIOS to high performance and disabling C-States. With the price of electricity though I can't afford to do that. It could add hundreds to electricity bills each month if done across all 10 PCs. I'm going to restore Windows from my backup image to how it was before I started making changes - to see if when I repeat the steps that what I did was the actual solution. oh, btw: I also found a known issue with LWF's.. See link below. I'm using the WinPCap driver, not npcap but I thought that might have been the issue. Red herring. The info about the 90 second delay is interesting though. https://learn.microsoft.com/en-US/troubl...cond-delay
Here are three points: 1) Keep things organized and only change one thing at a time. 2) Wait before making changes, because all those devices talk to each other and need updates. If you fix something too quickly while other devices haven't caught up yet, it might get undone later, like with ARP checks. 3) Eventually, if problems keep happening, maybe it's smart to adjust the power settings carefully. I know this will cost more on electricity, but fixing the real issues has already taken some effort and time. Even if changing power plans turns out to be part of the problem or helps a bit, you'll know what went wrong so you can plan better next time.