New answers tagged lan
Despite the advice you were given, it's quite unlikely to be the switch. Most managed switches do have some filtering and routing capabilities, but they all default to being off. Unless you've explicitly enabled them, the switch shouldn't be filtering anything. There are a few things I can think of to check (and I know from your thread that you checked ...
Within windows you have performance tools. This can be run over the lan. Run the test and look at the disk queue length, this will tell you if the hard drive is the bottle neck.
I work this quite often, migrating data between servers and during impossibly-long data transfers... The short answer, of course, is to test with your specific data... This is really easy to do, right? Try a LAN transfer with compression off, then try it with compression on... In my experience with production data sets across a few environments, on a GigE ...
Like Zoredache said, if your link isnt saturated no -z. Also, something else you can consider to help manage long transfers is the bwlimit flag.
During an rsync transfer are you CPU bound, or is your link saturated. If your link is saturated, but your CPU is idle, then compress. If your CPU is maxed, and your link isn't, then do not compress.
Yes, if your provider also provides a separate network for this purpose. Otherwise just use the public IP addresses. Though in this case, if you use SSL you will have to pass it all the way through to your backend servers rather than terminating it at the load balancers, to ensure that other customers' virtual machines cannot sniff your traffic. You'll also ...
I think there's a few misconceptions here. The first is that the reply from text isn't written in the same context as it normally would. The response is coming from your local IP address because the IP you're trying to ping cannot be found. For more in depth information about the error, see here. Now, the reason why you can't ping both computers could be ...
It does not actually resolve it to your own IP. It does try to ping the other host, which just happens to be unreachable. Basically, what it tries to tell you is: "Hey, here's 192.168.1.238. I tried to ping 192.168.1.117, but it's unreachable." Also, you do not need hosts entries for IP Addresses, that's only for names.
A bit old here but i answer anyway : [global] workgroup = smb netbios name = SERVEUR security = share share modes = yes [homes] comment = Home Directories browsable = no read only = no create mode = 0750
You can see that the rj45 plug has the blue wires in the center whereas on the patch panel they are on the side. I know you explained why you have a patch panel on one end and a plug on the other, but it's generally not a good idea to mix both types. On both ends of the cable should be either a female or a male end. The reason for this is that patch ...
Well after trying all of your great suggestions, I called our ISP again to have them look into the problem. It turns out there was an issue within the handoff to another ISP. The cable has been replaced, and all is well now. Thank you for the help! Josh
Top 50 recent answers are included