Jonas Dannert Posted September 22, 2011 Report Share Posted September 22, 2011 Yes it will, actually. Automatic MDI/MDI-X is standard on almost all NIC:s and switches nowadays. Also referred to as: Automatic crossover, Auto uplink and trade, Universal Cable Recognition and Auto Sensing "If one of two connected devices has the automatic MDI/MDI-X configuration feature there is no need for crossover cables. Introduced in 1998, this made the distinction between uplink and normal ports and manual selector switches on older hubs and switches obsolete." It will never hurt to use a crossover-cable, although not necessary. 0 Quote Link to comment Share on other sites More sharing options...
Member Lloyd Stewart Posted October 8, 2011 Member Report Share Posted October 8, 2011 Still hoping someone will reply to Neil's question about which network switch (brand and model number) works perfectly right out of the box with WO5, using Windows 7, 32 bit. Anyone? 0 Quote Link to comment Share on other sites More sharing options...
Moderator jfk Posted October 9, 2011 Moderator Report Share Posted October 9, 2011 Still hoping someone will reply to Neil's question about which network switch (brand and model number) works perfectly right out of the box with WO5, using Windows 7, 32 bit. Anyone? Just about any switch meets that requirement. The real question should be ... Still hoping someone will reply to Neil's question about which network switch (brand and model number) works perfectly right out of the box with Windows 7, using Windows 7, 32 bit default NIC settings, with my onboard Anyone? This is NOT a WATCHOUT issue, it is a Windows 7 / hardware interaction issue. Just because a switch works fine for someone else with their hardware and Windows configuration, does not guarantee the same will be true for you. I must be lucky, my seven year old dLink DGS-1005D Gigabit switch has worked fine with Win7 without any adjustments on my part. 0 Quote Link to comment Share on other sites More sharing options...
Luxav Daniel Posted October 17, 2011 Report Share Posted October 17, 2011 Hi I have setup a Win7 64Bit System on our Shuttle X-PC. Everything is working fine, but the Network is slow...>(0.25% shown by the Taskmanager on de Production Notebook) My Solution: Disabling the FlowControl on the Yukon Network Device. Now it is a bit faster than the WinXP Shuttle X-PC. Tommorrow i will check a another Switch Now its over 25%. Greetings from Germany Daniel 0 Quote Link to comment Share on other sites More sharing options...
ViPeRePiV Posted October 18, 2011 Report Share Posted October 18, 2011 Switches that have worked (Windows XP or 7) NETGEAR "unmanaged switches", both rackmount and desktop -- 4 port through 48 port -- 10/100 and 10/100/1000 Various other "dumb" switches and some "smart" swtiches, but not "managed" L2/L2+/L3 switches Swithces that have not worked Specifically had issue with an Alctel Lucent OS6850-P48 (48 port Gigabit PoE switch) -- Tried various settings (multicast and other that I cannot recall) with no luck -- No matter the settings, data rate was always asbysmal Hope this helps to get things started. 0 Quote Link to comment Share on other sites More sharing options...
Dataton Partner Walter Posted May 7, 2012 Dataton Partner Report Share Posted May 7, 2012 He guys, we had the same problem, but we solved it after a thorough search = In the advanced network-adapter setting = look for Jumbo Packets. Default disabled, but at 4088 (on all machines) the issue was solved! Perhaps this could be tested and added to tweaklist 2.2? 0 Quote Link to comment Share on other sites More sharing options...
Jonas Dannert Posted May 7, 2012 Report Share Posted May 7, 2012 Absolutely! /jonas 0 Quote Link to comment Share on other sites More sharing options...
Moderator jfk Posted May 7, 2012 Moderator Report Share Posted May 7, 2012 He guys, we had the same problem, but we solved it after a thorough search = In the advanced network-adapter setting = look for Jumbo Packets. Default disabled, but at 4088 (on all machines) the issue was solved! Perhaps this could be tested and added to tweaklist 2.2? Absolutely! /jonas Not every setup needs that tweak, in fact, very few do. That is an adaptation of Windows 7 to make it work with older network switches that are not truly Windows 7 compliant. So why would you de-tune every WATCHOUT system to accomodate old hardware? A while back, I started to write a post on this, but discovered that different swtiches need different tweaks. Here is what I had so far, but decieded not to post originally. ==================================================================== Periodically we hear reports of very slow online / update times with WATCHOUT under Windows 7. XP machines in the same cluster do not exhibit speed issues. Research has shown this is not unique to WATCHOUT, the general Windows population has many similar reports. Apparently there are some subtle changes in Win7 in the way Windows IP networking is implemented. The change creates slowdowns with some network switches. It seems Win 7 offloads some network duties to the network switch. I see mention of Win7 certified switches. But even switches that were not Win7 certified could be accommodated with changes to adaptor settings in the Advanced tab for the network adapter. reference: Slow Network File Copy issues in Windows 7 caused by Remote Differential Compression reference: Windows 7 Forums -> Windows 7 - Extremely slow file transfers and network access... I posted this issue to Microsoft (after some further research) and they solved it for me! They asked if my router was on the Windows 7 compatibility list, and that seemed really strange since 802.3 (Ethernet) has been around a long time and why would that suddenly change with the O/S? But I unplugged my PC from the Trendnet Gb router and plugged it into the old Linksys 100Mb and BAM - full network speed! On the Gb router, I couldn't get above 2% in the monitor on a file transfer - on this "compatible" one, I get 100% and file transfers are screaming. ===== From a WATCHOUT user in Canada When this occurs, a potential fix is to: go to the Advanced tab for the network adapter, change IPv4 Checksum Offload to Disabled But I see other settings being offered as a fix, so it would appear there are multiple issues that can affect the interaction of Win 7 and the network switch. I found that the thing which fixed it for me was "flow control" =========== reference: Windows 7 Forums -> Windows 7 - Extremely slow file transfers and network access... Start \ Run --> ncpa.cpl right click on adapter ... select properties click on "configure" click on "advanced" highlight the property "Flow Control" and change it to "disabled". This stopped the rate limiting and let my adapter run at full speed. =========== Remote Differential Compression (RDC) reference: http://www.windowsreference.com/windows-7/slow-network-file-copy-issues-in-windows-7-caused-by-remote-differential-compression/]Slow Network File Copy issues in Windows 7 caused by Remote Differential Compression[/url] <p> You may experience poor file copy performance over the network in Windows 7 PCs. This could be caused by the Wndows “Remote Differential Compression” engine. Remote Differential Compression is a Windows feature introduced in Windows Server 2003 and is available on all later versions of Windows. This Windows feature is enabled by default in Windows 7. Remote Differential Compression (RDC) allows data to be synchronized with a remote source using compression techniques to minimize the amount of data sent across the network. RDC is different from patching-oriented differencing mechanisms, such as Binary Delta Compression (BDC), that are designed to operate only on known versions of a single file. BDC requires the server to have copies of all versions of the file, and differences between each pair of versions are precomputed so that they can be distributed efficiently from a server to multiple clients. There seems to be a problem with this Windows 7 and disabling this feature resolves the problem with slow file copy performance. To disable Remote Differential Compression, 1. Click Start – Control Panel – Programs – Trun Windows features on or off 2. Uncheck “Remote Differential Compression” and click OK. 3. Restart the computer and you should see an improved performance with copying files. If there is a similar problem in your Windows Vista PC, you may try this and check if this helps. But I see other references to the above fix with comments like: "This has been completely debunked by MS" The Storage Team at Microsoft - File Cabinet Blog Debunking Myths about Remote Differential Compression and System Performance 0 Quote Link to comment Share on other sites More sharing options...
Dataton Partner Walter Posted May 8, 2012 Dataton Partner Report Share Posted May 8, 2012 Thanks for the update. I did read the other topic, didn't resolve, but was helpful anyway. By the way, switch used IS truly win7 compliant, but still, could you elaborate on what this tweak is contributing to this upload error? And if applied whilst using a 'truly win7 compliant' switch, what would be the drawback on using this unnecessary tweak anyway? Would it hurt? Otherwise adding this to the tweaklist will help, since it still happens that separate WO machines are rented out to other companies using their own network setup... (dry hire situations). 0 Quote Link to comment Share on other sites More sharing options...
Myngus Posted February 14, 2013 Report Share Posted February 14, 2013 Hi all, I am trying to implement Watchout V5 into a Network via 2 CISCO 6509 Core switches. The settings in the switches are all defaulted. I am experiencing issues with the display machine not responding well enough to control commands from the production pc. It's rather erratic. If I bypass these switches and use a domestic "dumb" gigabit switch then all is good in the world. However, I have to use the above switches. To bypass them permanently is not an option. Can anyone help with suggesting settings for these switches to make Watchout respond properly? Thanks 0 Quote Link to comment Share on other sites More sharing options...
Member Hugo Janzen Posted February 14, 2013 Member Report Share Posted February 14, 2013 From a hardware point of view: A network switch with a build in power supply makes your installation more solid. 0 Quote Link to comment Share on other sites More sharing options...
Moderator jfk Posted February 14, 2013 Moderator Report Share Posted February 14, 2013 Hi all, I am trying to implement Watchout V5 into a Network via 2 CISCO 6509 Core switches. The settings in the switches are all defaulted. I am experiencing issues with the display machine not responding well enough to control commands from the production pc. It's rather erratic. If I bypass these switches and use a domestic "dumb" gigabit switch then all is good in the world. However, I have to use the above switches. To bypass them permanently is not an option. Can anyone help with suggesting settings for these switches to make Watchout respond properly? Thanks I can not tell you how to program a CISCO switch, but I can assist in identifying the goals. From there, CISCO support should be able to guide you to a solution. Onyx systems, the integrator who installed a 36 channel WATCHOUT system at Virginia Beach Convention Center many years ago, experienced similar issues integrating into an existing Cisco intranet when they started. They were able to achieve a stable WATCHOUT system with some tuning. Most WATCHOUT communication uses the documented port numbers. However, the file server (used for downloading media files) uses a dynamically allocated port number. The built-in display computer management function uses a dynamically assigned port for its VNC connection. Hence, for all these functions to work in their default (dynamic) configuration, you really need to have (almost) unrestricted access to the computer. Both TCP and UDP traffic must be permitted. Dynamically allocated ports always are greater than 1024, so if you want to, you should be able to lock down all "well known" port numbers (ie, all below 1024 which you know you won't be using). These "well known" ports are often considered most vulnerable, since the kind of service can readily be assumed from the port number, so an attacker would have a better idea on what it might attempt on those ports. In theory, once the system has been installed and all media transferred (assuming there's no need for VNC remote managment), it should be possible to block all ports except the documented ones. This would, of course, disable the production computer from transferring files, so it is practically a WATCHOUT write protect for the display computers. 0 Quote Link to comment Share on other sites More sharing options...
Myngus Posted February 14, 2013 Report Share Posted February 14, 2013 Thanks very much for the info. I'll have a crack at this. BTW, not too sure where to find the documentation for port numbers... Can you tell me where to look ,or tell me the numbers? Cheers. 0 Quote Link to comment Share on other sites More sharing options...
Mike Fahl Posted February 15, 2013 Report Share Posted February 15, 2013 First, about the "slow upoads" some have experienced on and off since Win7 was released. This seems to have become much less of an issue lately. I used to see it myself every now and then earlier, but haven't seen it at all now for almost a year. Nor have I heard about anyone experiencing this problem recently. I've never seen it under XP. Note that we haven't changed anything in WATCHOUT to "fix" this. If the problem has indeed gone away, that must be due to changes in recent OS updates. As to funky switches, we ran into another wierd problem last week. Using one particular laptop and one particular switch (a managed netgear switch), we had serious problems making a connection from the production computer to the cluster. It was often very slow in connecting. Sometimes it resulted in a spew of hundreds of error messages in the message window. I connected an old XP computers to the same switch, and loaded the same show. No problem. We switched the laptop that had previously had the problem over to wireless, and unplugged the Ethernet wire. No problem. We went back to Ethernet, and had the problem again. We then moved the other end of the Ethernet cable form the managed switch to another unmanaged switch on the same network. No problem. So, yes, the kind of switch you use can make a difference. In this case it was that particular switch in conjunction with that particular laptop. Go figure... Mike 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.