SiMPLE | Forum

Sure, understandable.  My main concern/response was to the statement "The thing is that windows remote desktop use the nfs protocol if i understand it right".  Since to my knowledge the answer is "No, RDP does not use NFS to perform file system redirection", and therefore doing specifically NFS-related speed-up things with the expectation it would improve RDP file system redirection seemed misguided.

If CIFS/SMB isn't an option (not that Linux is unable to connect to CIFS/SMB shares), the analog to what I was suggesting is that you would change the Windows machine acting as the Remote Desktop host to connect to the shared files host directly on it's own.  Instead of mapping to the shared files host on your Remote Desktop client machine, and then expecting Remote Desktop file system redirection to pass-through that file system access to the Remote Desktop host machine.  (Since I presume that's the meaning of the screen shot you posted of Remote Desktop Connection's drive redirection.)

That specifically CIFS/SMB would be used instead wasn't important; the important part was not "doubly-redirecting" by sending the shared file system access through the extra layer of RDP file system redirection.  It's damn convenient to do it that way, but not fast.

I don't do NFS access from Windows... what is the nature of how NFS access is being performed?  e.g. Just a desktop application doing its own thing over winsock (like Filezilla), or something that integrates with Windows file system APIs by installing a network provider and network redirector that supports NFS?

For the latter, slowness in multiple-redirector environments can come from Windows trying to prove that the UNC to an NFS server you provided is not a Microsoft DFS root and/or is not for one of the other installed network redirectors or providers.  Enabling the Microsoft "DisableDFS" policy can help the first part, and configuring the Windows Network Provider Order to push your NFS network provider higher in the order can mitigate the second part.

Yeah, the Windows 8.0 keys definitely work for the corresponding Windows 8.1 edition.  Successful activation should have also triggered Microsoft sending you a physical letter personally signed by the Windows development team, apologizing for Windows 8.0.

What comes to mind for me with this is that "game.useAutoPingAdjust 1" is probably already the default.  Meaning its something the game is doing for network play, but as a debugging option there was a way to "turn it off" and see what would happen without the prediction / compensation / whatever the hell its doing.  So maybe "0" is the way to "see something different", not that this implies anything about whether the difference will be substantial enough to notice.

For what it's worth, 100% packet loss using the PING command just means the server does not respond to ICMP Echo requests, and/or that one or more routers between you and that server do not forward ICMP Echo requests.  You might very well have 0% packet loss on that server for the actual game traffic; PING can only show what happens when trying to reach that server over ICMP.  So just another valid reason for "I didn't see a difference", because you may very well have 0% packet loss to that server for the actual game traffic this setting is concerned with.

I was previously only familiar with "the bee's knees".  I am not a doctor, but I presume this affliction would be referred to as "a honey heel".

-Trench

Originally for FiOS, Verizon would only install a battery backup on your ONT if you had purchased FiOS-based phone service with them.  Presumably because of their concern for local regulation regarding 9-1-1 service, and being able to make an emergency call even when the power was out.  (As compared to legacy copper service, which was powered over the phone lines themselves.)

FiOS no longer provides a battery backup.  The technicians tell you "it's not needed any more", but I think all it really means is Verizon's lawyers finally figured out they were not compelled to provide one.  While true that "it doesn't need one", without one your phone service IS going to go out when the ONT loses power.

I still have the Verizon UPS on my residential service, and just replace the batteries on it myself when needed.  They installed a business line of service here too without a UPS, and so I had to put my own UPS on that second ONT.  If you have a UPS on your ONT, it will be inside the garage near where ever the ONT is plugged into AC power.  If you don't have one there, maybe that's another place to consider adding one.

-Trench

If you find the BR1500G for a price you'll accept, I would simply do that.  It's going to be double or triple whatever your current load is, probably, but that just means you get more runtime when the power does leave.  You're not trying to "match" your current load; you're making sure the unit does handle at least as much as your current systems draw, and then also buying over-capacity for however much additional runtime you want to achieve.

So once you have it, the UPS is going to tell you what you're drawing & what the projected runtime will be with the load you have.  (i.e. It will "be the meter to measure your load" at that point.)  Best case scenario, you've just bought three times the capacity you need, and have invested in longer runtime by having more capacity than you need.  Worst case, you'll see that to achieve the runtime you really want, you'll need to split the load over two units and will be in the market to purchase a second one.

I just definitely think that regardless of what you might pre-measure the load to be, you'll be better off with multiple 1500 units than trying to go into the market for a 3000 or higher single unit.  Just more flexibility for the future by being able to divide them, and doesn't really change the investment by much when it comes time to replace batteries.  That's my US$0.02 anyway.

-Trench

Like ABAS already indicated, seeing "no response" / timeout from traceroute just means that particular "hop" (router) is either configured not to respond to ICMP Echo requests, or the router has de-prioritized them under significant load in order to keep up with higher-priority traffic.

If you're seeing other routers after the non-responsive one it's usually no big deal, and you're just missing a piece of the picture from within the middle of the route.  But when the non-responsive router(s) also happen to be the last hop(s) in the route, this creates a condition where traceroute cannot determine if or where the route actually ended.  And so the traceroute just blindly continues on for the maximum 30 or however many hops it's configured to try before giving up.

It's the same underlying condition in both cases (no response to the ICMP Echo), and simply "because it occurred on the last hop(s)" that creates the "can't tell where this route ends" condition.  The ICMP Echo sent to the last router(s) don't receive a response because of the configuration on the routers themselves, but then traceroute's attempt to send an ICMP Echo to the next router(s) beyond the non-responsive router also fails (and is also shown as non-responsive) because no further router actually exists.  Traceroute has to continue because he cannot predict whether the router he's trying to reach is non-responsive intentionally, or non-responsive because it simply doesn't exist at all.

The first key hash is what you should see when you don't have the CD key set in the correct location, or if you simply set a blank string as the key in the correct location.  It's the MD5 hash of a blank/empty string.

That's the same hash I expect to see when a player crashed & reconnected, as described earlier.  e.g. When they also had the "_xx" suffix added to their name because their old player was still connected too and hadn't timed out.

Don't know what the second one is, and would have to assume it's the hash of an actual key.  Google says a player with that key hash was on BWT-Badewiese in 2015; if that's you, then maybe that confirms its the hash of one of your actual keys.

I too would suspect that the Battlefield 1942 CD key information just isn't set uniquely across the machines.  If you seem to have the expected key information saved under [HKEY_LOCAL_MACHINE] on these machines, maybe check whether you see different information under a corresponding subkey path in [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node] for 64-bit Windows, or simply under [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE] for 32-bit Windows.

This is where Windows would redirect an application that isn't running as "elevated" (Run as Administrator) and tries to write and subsequently read information from [HKEY_LOCAL_MACHINE].  i.e. If BF1942.EXE isn't running with the "Windows XP SP3" compatibility and "Run as Administrator" turned on for the game (or wasn't always running that way), maybe there is some different or "blank" information stored in here under the [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942\ergc] subkey path which makes the running game read a different key that what you otherwise see under [HKEY_LOCAL_MACHINE].

I'm also unclear how one would be successful at "checking in Battlefield Server Manager that the key hashes shown are unique", if the players become kicked when a duplicate key is detected.  I expect to see BFServerManager / BFRemoteManager log entries confirming why they were kicked when the duplicates WERE present, but what exactly are you seeing to confirm that they're NOT duplicates?  Ostensibly, if you're in a scenario where you can see in Battlefield Server Manager that they're not duplicates, they're also not being kicked as duplicate.

Something about crashing comes to mind too.  Like when someone had crashed and re-joined, the game would reconnect with a blank key hash instead of their original key hash.  Which on its own wasn't an issue, except when we had another player who was intentionally playing with the blank key hash, and then the crashed user reconnecting ("playername_11", etc.) collided with the already-existing blank key hash player.  Maybe two of your family's players both crashed and re-joined?  Do either one have the "_xx" suffix on their player name when the log says they were kicked for duplicate CD keys?

Oh, I just realized maybe what I'm recalling wouldn't apply, because in my case it's actually Punkbuster kicking for "Duplicate GUID/CDKEY".  I'm guessing you're probably not running Punkbuster for this server, and I can't really comment from experience on what the behavior would be from the Battlefield 1942 game itself regarding duplicate CD keys.

EDIT: An English.

Think it's accurately mimicking what the image would actually be like when not only zooming from one building to the next, but then also zooming to double that distance through the reflection in the glasses.  Just a few bare nanometers of vibration in either the camera or even the sunglasses could throw the image by even full meters at that kind of distance.  If you've seen better, it probably had some kind of heavy dampening tripod or image stabilization involved.

Its of course fake in this case, because the double-zoom is contrived for the telling of a visual joke.  But I'm saying they intentionally faked the "shaking" part too, because of what it would actually look like at that distance through that equipment.

-Trench

"Time of day" can indeed be true, if the throughput of the Internet connection between you and YouTube is measurably different during peak-time versus off-time or other times of the day.  Like Netflix, Hulu and probably every other streaming service, they are attempting to stream a resolution that your PC can actually keep up with pausing or delaying the video to buffer more data.

Which is more a function of what your Internet throughput is at that moment, rather than what your computer's speed or screen resolution.  Yes, an overload at YouTube itself would be treated the same way, but is not the only reason why the rate at which data can stream between you and YouTube could become diminished.

https://support.google.com/youtube/answer/91449?hl=en

Probably not the issue, but just in case, make sure whatever method you're using to launch BF1942.EXE includes making the Battlefield 1942 program directory the current directory.  e.g. If using a shortcut, make sure the "Start In" directory in the shortcut is set to the directory where BF1942.EXE is located.  I've definitely seen the game fail to start if BF1942.EXE is executed without the game directory being the current directory.

Screen shots and notes of what you're expecting to see are shown here, if helpful.  Note unless you're doing something very specific, you likely also want the DC_Final mod / "Desert Combat .8" in addition to the Desert Combat .7.

Holy cow, thanks Bud.  Indeed I appear to be wrong about the DNS support.  This is something I felt like we explored to conclusion back when we had to change our server IP late last year, and I had come away with the conclusion that the Battlefield 1942 game itself simply didn't handle DNS names.  ("Stupid 2002 game design!")  Not in the "Add Server" for the in-game browser, nor from the command line either.

So that wasn't "based on some new test I did while creating this installer"; it was just something I had already assumed and "knew" was true.  But repeating your test, as well as testing with "+joinServer dc.ea117.com:14567" and also simply "dc.ea117.com" in the "Add Server" dialog says that DNS names work in BOTH locations.

So that's cool, and I was wrong.  Its crazy to think that I must have had my DNS failing at "just the right time" during the previous tests to allow making the wrong conclusion.  But I certainly never went back and tried to repeat the tests until just now.

At minimum, the current tool can be changed to ignore resolving the DNS name ourselves and simply pass the DNS name on the command line, regardless of whether we continue creating a shortcut or launch the game directly.

That perhaps a nuance I'm not understanding?  For me, the DNS name tuia stated ("play.team-simple.fr") resolves to 163.172.13.221, which is the same IP address {Phantom} had requested.  And so I assumed it was the new IP address.  Actually, tuia's message confirms this is the address of the new server.  So I'm not understanding "Simple doesn't seem to have any domain name pointing to the new server", if you can clarify.

-Trench

EDIT: To finish a sentence.