ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Windows 10 Tips

<< < (5/6) > >>

Stoic Joker:
The default NetBIOS note type is H (has been for awhile).

In addition, Windows uses Windows Internet Name Service (WINS), b-node broadcasts and the LMHOSTS file for NetBIOS name resolution. If all of these name resolution methods are used, an h-node host computer implements them in the following order:
1.NetBIOS name cache
2.WINS server
3.B-node broadcast
4.LMHOSTS file
5.HOSTS file
6.DNS server-MS TechNet
--- End quote ---

1-4 time out once, the host file lookup gets cached, and things zip along fine then after.

NetBIOS isn't dead by a long shot. NetBEUI - last seen in XP - is dead because it was a -(9x era)- huge security risk. Workgroups rely on NetBIOS by default. And while NetBIOS can be a tad fragile adding an entry to the Host file will get you over "the hump" more often than not.

I frequently deal with SOHO workgroups, and hate them, because inevitably there will be some 3rd party babysitter security software making normal - and yes by that I mean NetBIOS - name resolution impossible. So to save time we now just go with statically addressing the target device and accessing it by IP automatically if it doesn't behave on the first try. Otherwise it just ends up being a total time vampire ... Not because it will perform slowly, but because it wont work period. Workgroup name resolution can't use DNS, because workgroups don't have DNS servers available to register with.

Well, I guessed that if you only heard it from me, you would rightfully put it to anecdotal evidence or hearsay. So I added links to the finding of Fred Langa (a person with much more credibility than I have) and a link to a technet post, assuming those were credible enough.-Shades (February 29, 2016, 09:34 PM)
--- End quote ---
On the contrary - if a thing like this had been reported by you (or some other DC member), it would be something interesting to look into. When a post with that level of lack of quantifiable comes from some relatively well-known source, I get suspicious ("You won't BELIEVE how much homegroups suck" probably gives ad revenue), and I also hold "well-known folks" to higher standards than normal individuals.

Langa's article is extremely weak in quantifiable data, has imprecise language and terms, and doesn't even try to present a likely explanation. IIRC the TechNet post just referred back to the Langa article, so it's not a reliable data point in and of itself. And even the MVPs there post questionable stuff from time to time, anyway :-)

The machines that do not use NetBios are much faster retrieving content from network accessible folders than the other ones.-Shades (February 29, 2016, 09:34 PM)
--- End quote ---
Can you quantify "retrieving content"? Not necessarily a full detailed breakdown with graphs and stuff, but a "first connection to remote machine is slow" versus "file listing is slow" versus "transfer speed of one 10gig file is 6MB/s vs 10MB/s on <other tech>" are extremely different scenarios.

About the other part:
More often than not, 'Less is more'. Software and services/protocols that are not needed, you best get rid of to prevent Windows taking unnecessary actions. By 'getting rid of' I mean disable, not remove as there might be a future task for which you might need it again.-Shades (February 29, 2016, 09:34 PM)
--- End quote ---
I agree with the "less is more" philosophy in general, but I don't really feel it applies to Homegroup. Caking layers upon layers on a protocol is bad, simplifying authentication isn't necessarily bad.

From your "workgroup vs homegroup" list, the only thing that should have any impact on throughput would be IPv4 vs IPv6. But if that's a 10% difference, something is very, very wrong on your LAN - the TCP headers are larger, but not that

Personally, I would not be surprised if the Homegroup requirement of IPv6 could be the cause for slowdowns in an IPv4-only network. The NIC in the computer could wait a millisecond or so, because of the incomplete/wrong IPv6 configuration before reverting back to the working IPv4 configuration, each time a TCP/IP packet needs to be ACKnowledged. This adds up when transferring (big) files. I would also have no problems imagining that the 'spanning over a subnet' introduces extra overhead in some network drivers.-Shades (February 29, 2016, 09:34 PM)
--- End quote ---
Nope. You might have a delay at a broadcast "is there anybody OUT there?" level at IPv6, but it's not per-packet. Once you start communicating between hosts, you're on one protocol level. And if IPv6 is a requirement for Homegroups, you wouldn't have any connectivity on IPv4 anyway. "Spanning over a subnet" would only be relevant if you're actually doing that.

As most people only have access to IPv4-only networks, which I don't see changing any time soon, the unnecessary Homegroup slowdown will remain a problem.-Shades (February 29, 2016, 09:34 PM)
--- End quote ---
Most people won't have IPv6 internet connectivity, but we're talking LAN connectivity here. If Homegroup is IPv6-only, you wouldn't see a a slowdown on IPv4 networks.

Now, if there really are slowdowns related to Homegroup, I'd like to know about it - and especially why. The stuff I've heard so far seems about as reliable as homeopathy, though.

Here's one I just discovered today:

You can click and drag icons in the tray to rearrange them or move them to/from the little ^ icon to easily make it always show or hide:

Here's one I just discovered today:

You can click and drag icons in the tray to rearrange them or move them to/from the little ^ icon to easily make it always show or hide:
-Deozaan (May 27, 2016, 01:48 AM)
--- End quote ---

oohh, that's nice :up:

I started having a process called System and Compressed Memory spiking in RAM and CPU usage (3GB and 90%+ respectively).  I found out that it's caused by Superfetch.  Superfetch is actually useful- when it works correctly.  But one of the recent windows 10 updates (TH2) that they force down your throat made it not work correctly on many installations.  You can safely disable it- but it does remove the caching mechanism, which, as I said, when it works well, is actually useful.

Ok, with that out the way, to disable Superfetch:

* Press Windows Key + R to open the Run Dialog box.
* Type services.msc and press Enter.
* In the list of services find Superfetch
* Right click it and open properties.
* Click on Stop.
* Also set its startup type to "Disabled".
This is provided for information for others that might be affected, as it corrected my RAM usage problems that I've been having since late last year.  It is up to you to do root cause analysis to see if this is better or worse for your case.  As it's completely reversible, you can try this to see if it corrects your problem, and if not, change it back.  Also note that the link I gave above shows some of what it does, and how it can be a false positive for your case- you have to take note of what kind of memory usage you're seeing (process monitor or the built in resource monitor are good for this purpose).


[0] Message Index

[#] Next page

[*] Previous page

Go to full version